Open source security management: A question of when, not whether

As a “nontech” attendee at Black Duck’s FLIGHT 2016 user conference, I had my work cut out for me keeping track of all the buzzwords and acronyms. However, after attending Mike Pittenger’s session, “Filling Your AppSec Toolbox,” I learned a lot about some of the most important application security testing tools in the world of application security—SAST, DAST, and open source security management (OSSM).

As the threat of cybercrime continues to rise, so does the importance of application security. Practices such as penetration testing, threat modeling, and other security methodologies have become go-to activities for protecting organizations against external cyber threats. In order to head off potential risks, developing code with security in mind has become a priority for companies large and small.

There are a wide variety of testing tools used to strengthen security throughout the software development life cycle (SDLC). The most widely implemented tools are static application security testing (SAST) and dynamic application security testing (DAST). Open source security management is less well known—but critically important. More on that in a bit.

When it comes to DAST, SAST, and OSSM, it can be hard to know which testing methodology works best. The truth is there is no clear winner, as each methodology works better on different classes of vulnerabilities. The more important question to ask is, When should I use these methodologies?

Here are the primary differences and uses for DAST, SAST, and OSSM I learned from attending the technical track at FLIGHT 2016.

SAST: Static analysis security testing (white box testing)

Simply put, SAST tools allow you to test applications from the inside. Commonly referred to as “white box testing,” SAST tools work by parsing and analyzing source or binary code. These tools, used early in the software development process, look at the way developers have written the code to identify weaknesses in software pre-deployment. By identifying code flaws early in the SDLC, organizations can fix issues before hackers have the chance to exploit them.

Static application security testing is best done during the code phase and build verification. However, in order to get the most out of SAST testing, it may require the use of several SAST tools. A study by the National Security Agency (NSA) Center for Assured Software found that the standard SAST tool only identifies 8 of the 13 total weakness classes, and can only identify about 22% of the flaws in each class. Furthermore, each SAST tool has the tendency to find different weakness classes based on the vendor’s approach and specific algorithms used. In order to find the largest percentage of weaknesses, one would need to run several SAST tools. For most organizations, this simply isn’t practical.

While SAST solutions provide valuable insight into the development process, they aren’t perfect. As the use of open source increases, a critical weakness is exposed: SAST tools generally do not identify vulnerabilities found in third-party or open source components.

DAST: Dynamic application security testing (black box testing)

In contrast to SAST, dynamic application security testing, often referred to as “black box testing,” is performed from outside of an application while it is running. Simulating a malicious user, a DAST tool will attempt to penetrate an application using HTTP requests in order to expose potential vulnerabilities, including those outside of the codebase and third-party interfaces.

While DAST tools are often easier to use than SAST, they are also unable to pinpoint specific weaknesses in application code, leaving the task of finding and fixing the vulnerable code as an exercise for the user. And unlike SAST tools, DAST requires a complete, running application, which limits its use to late SDLC phases: testing, staging, and (with caution) production.

OSSM: Open source security management

With open source constituting over 50% of most modern applications, open source security management has become the critical third leg of the application security testing stool. It provides coverage in an area where DAST and SAST fall short: identification of open source components and known vulnerabilities. While standard DAST and SAST methodologies can provide valuable insight into an application’s risk, neither are effective at identifying vulnerable open source code. One example is the Heartbleed vulnerability, which went undetected for years under traditional DAST and SAST practices.

With OSSM, developers are able to identify open source in an application, down to the version level. OSSM provides insight into open source security risks as well as license compliance and code quality risks at every stage in the SDLC: from the design stage all the way to production deployment. Perhaps more importantly, OSSM provides protection for production applications by continuously monitoring for new vulnerability disclosures on an ongoing basis.