With the pressure to release fast, how in the world can developers ensure they’re releasing secure code with no known vulnerabilities???

With today’s modern apps, developers cannot be expected to keep abreast of all findings in the security space and go over source code of all dependencies to see if there are any vulnerable usages. There’s just not enough time in the day…

I began my career writing C code for embedded devices and video conferencing units. Terms like gcc, assembler, external symbols, linker, static library, dynamic library, ioctl, mmap, free, etc. were like daily bread and butter. But 2 years into my career, I got pulled into picking up Web UI and what started as a one week gig became a 3.5 year stint. I grew to become the lead of the UI team. The older terms were now replaced with DOM, javascript, service worker, Angular, react, etc. Then I delved into the backend and started building entire applications from scratch. New terms like service discovery, db normalization, Docker, container orchestration, multi-region redundancy, and configuration management were added to my vocabulary.

As I moved up the tech stack, I lost touch with what was happening underneath: system calls, interrupts, scheduler, threads, stack, heap, etc. I suspect this is the case with most application developers—they don’t need to know the internal functioning to get their job done. While this may seem ok if your only goal is building functionality that works, when you want to ensure you are releasing secure code with no known vulnerabilities, things change. Quite a few of the high risk security issues are found in the lower layers of the system.

Quick examples of this:

1. Did you know that strcpy is unsafe and it can be used to copy malicious code into the memory?
2. Did you know that using MMAP with both write and execute permissions can leave you vulnerable to an attacker potentially uploading malicious code and executing it?
3. Did you know that rand might generate low quality random numbers that can be exploited?
4. Did you know a simple missing length validation check (heartbleed vulnerability) in OpenSSL rendered 17% of all SSL servers to be vulnerable?

When we write our application code, we pull in a bunch of libraries to build features but we do not know if any of those libraries have such vulnerabilities in them. So how do developers provide secure code? How do we detect that such vulnerabilities exist in the codebase?

We obviously cannot expect developers to keep abreast of all findings in the security space and go over source code of all dependencies to see if there are any vulnerable usages of system calls or other vulnerabilities. We also cannot rely on slow manual processes where every library / commit is approved by the AppSec team.

We have to rely on automation to keep up with today’s demanding pace of software development. We need a tool that looks for usage of such vulnerable system calls in our applications. There are several tools in the security space which cater to different segments of security like SAST, SCA, DAST, IAST etc, but none of them are purpose-built for developers and purpose-built to observe the running application.

The need of the hour is to give developers full security visibility during their development phase so they can observe their apps for security issues during automated testing, run DAST scans themselves, and, find and fix security issues much earlier in the cycle. They should be presented with a relatively small set of actionable alerts without the need for deep knowledge of each vulnerability. The goal is to help developers find issues early, help them understand the issue without bogging them down with details and also help them fix the issue. The fix could be upgrading a certain library, making the application code more secure or changing the way the application is deployed. All of these tasks are in the developer’s realm and comfort zone.

This is exactly what we are building at DeepFactor. We are on the road to become the complete observability platform for Security and Compliance for developers. If you are a developer who has to contend with security issues and feel you don’t have the right tools to help, drop us a line at hello@deepfactor.io. We would love to show you what we have been up to!

DeepFactor observes ACTUAL application behavior at RUNTIME to detect anomalies and prioritize alerts. But why emphasize RUNTIME observability? Think of it this way… Looking at a parked car is different from test-driving it. And you certainly don’t want to accidentally buy a lemon! Similarly, static code analysis is different from observing a RUNNING application. Avoid the lemons with observability—find security & compliance risks in your running application. Click here to start using DeepFactor for FREE!