Over the past couple of years, DevSecOps has become one of the newest catchphrases in organizations who are striving to enhance their secure software initiatives. But what exactly is DevSecOps, and how do you turn it into reality? Unfortunately, just adding a few letters to DevOps does not necessarily lead to nirvana. In most software security circles, DevSecOps is the foundational belief that security and development teams must be jointly responsible for strengthening security – realistically tying development, security, and operational processes together. This concept seeks to introduce security into the equation as early as possible, covering the entire software development life cycle, with the aim to find, fix, and prevent security vulnerabilities and associated risks without slowing development and impacting time-to-market. In theory, it’s easy to understand what DevSecOps means and why it’s becoming the goal of organizations worldwide. But speaking in terms of reality, how do you actually achieve it? The truth is that many organizations trying to adopt DevSecOps principles discover their traditional code analysis approach can no longer keep pace with the speed and frequency of releases. But before we discuss the New Code Analysis Approach, in the context of secure software initiatives, we need to highlight the SAST + DAST analysis approach and the underlying difficulties that often surface within modern software development initiatives.

The Traditional Duo in the Pre-DevOps Era

In the past, organizations implemented AppSec programs that were primarily designed around static code analysis (e.g., SAST) which was used to test an entire code base near the end of the development process, where coding errors that could lead to vulnerabilities were detected. Developers went back and fixed the lines of code that were an issue and the delays caused by this approach were not much of a problem since time to market wasn’t the gold standard for software development like it is today. Once SAST was completed, operators would then turn to dynamic code analysis (e.g., DAST) to perform simulated attacks to see how an application might react in the real world. If further issues were discovered and needed to be fixed, developers would once again go back and tidy up the code to address runtime vulnerabilities. Although SAST and DAST were typically managed by a team of security experts who operated primarily in isolation, the end result was better security. But delayed releases, friction between security and development, and opposition to security testing was an inherent byproduct. Fast forward to today and the multi-day, SAST + DAST analysis approach being run by a small group of security experts is not what DevSecOps is all about, especially when the business demands multiple software releases monthly, weekly, or even daily. Although there was nothing fundamentally wrong with this approach, and the end result was usually more-secure software, the SAST + DAST  analysis approach simply does not fit well within the underlying goals of DevSecOps.

The New Code Analysis Approach in the Modern DevSecOps Era

From a simple functional perspective, yes, organizations will always need to perform static code analysis. But the whole key to this analysis approach is to ingrain the functionality into the tooling developers use when writing, pushing, pulling, merging, and integrating lines of code. If this functionality sits outside of those parameters, it will rarely be able to effectively fit into DevSecOps initiatives. The reason is that static code analysis cannot slow down delivery and deployment of software. Secondly, and again from a purely functional perspective, organizations will also need to perform software composition analysis (SCA). Why? That’s simple. In modern application development, organizations should encourage their developers to use open source instead of trying to reinvent the wheel just to marginally create something that’s already been well established. The use of open source components and 3^rd-party libraries is becoming a way of life within modern software development practices. If this composition analysis approach can be performed in unison with static code analysis, that’s obviously the methodology that will work best in DevSecOps, since it too will not slow down delivery and deployment. Finally, and from a merely functional perspective, organizations will also need to perform interactive security analysis while builds are running. If this analysis approach is applied during functional testing, without adding any additional unexpected delays, all the better. When this analysis is being performed by QA testers who must already spend time to determine if an application will work in production, they can also quickly identify security vulnerabilities without delay as an added benefit, without extensive application security knowledge and experience. The real key to successfully adopting and implementing new code analysis approaches that match DevSecOps objectives is to understand the functionality each solution brings, then apply that functionality when and where it makes the most sense. And today, these needed functionalities are being delivered via:

• SAST that incrementally scans your source code for vulnerabilities,
• SCA that detects open source security, license, and operation risks, and
• IAST that secures your runtime applications in real-time.

The real DevSecOps benefit comes from bringing the functionality of all three of these together into one seamless code analysis approach, ideally all from a single pane of glass. When this approach is successfully achieved, in the most integrated and automated fashion possible, and within the tooling developers use, the notion of DevSecOps can actually come to fruition.