For years, the warnings from advocates of software security improvements fell on deaf ears. The focus has historically been on measuring development teams based on delivered features, functionality, and time-to-market, versus security. As a result, application-level security continued to be a lower priority, while high-profile security incidents have mounted, and the cost of overlooking security in DevOps has become undeniably apparent. US Federal Departments and Agencies have started to tabulate the cost, and are learning the cost of a single security incident can be far greater than the cost of investing in an entire software security program, before the damage is done. As a result, we are now seeing a commitment to the adoption of secure coding practices within federal agencies and organizations. In short, deliberate implementations of DevSecOps are becoming much more common.
Lessons Learned From Success
Anyone working in software development for the defense industry is likely to be familiar with the story of Kessel Run. The experimental project was established to determine if the modern software development practices of Agile and DevOps could replace or augment legacy Software Development Life Cycle (SDLC) practices already in use across the Department of Defense. The project is seen throughout the defense sector as an example of how “DevSecOps” frameworks not only produce more secure software but also deliver operational applications in a fraction of the time usually needed for similar projects.
Increasing concerns around cybersecurity within our government institutions have also given DevSecOps new importance and meaning. In 2017, the Trump administration announced an initiative to strengthen cybersecurity throughout the federal government, and the result has been an increased focus on secure software development that is impacting priorities throughout federal agencies that are working diligently to meet the demand.
Obstacles on the Path to DevSecOps
When discussions around the implementation of DevSecOps into federal SDLCs first began to escalate, they were met with hesitation and resistance. Developer teams had become understandably set in their ways; developing software along with processes they created over the course of time. Developers were viewing secure code with a “security gate” mentality, wherein an application would be developed in its entirety, and then passed to security professionals to evaluate it for vulnerabilities after it was completed. Even after adopting scanning tools to help with security testing, security teams found that they needed to re-compile and scan entire applications after adding relatively small sections of code, in order for the scans to function properly. The time and costs associated with a significant shift in approach, from training programs to the restructuring of teams across federal agencies, left decision-makers wary of the undertaking.
Another common challenge that has presented itself as federal organizations have attempted to implement DevSecOps practices is the simple problem of data overload. For years, security teams have had access to powerful scanning tools that are able to examine an application and highlight vulnerable strings of code that require remediation. But developers often found themselves inundated with a daunting list of issues to address, that would require too much time and too much security know-how to remediate. The result has been skepticism towards software security scanning tools, as the discovery of large and virtually un-addressable volumes of vulnerabilities can threaten an application’s “Authorization to Operate,” a key step in the approval process for the deployment of applications in the federal space.
Developers are keenly aware of the risks associated with increased speed in software development. Faster code delivery means there are more opportunities for error, and teams often cite concerns that the increased pressure placed on developers can become too much to bear, stretching workers to their limits and placing the overall integrity of an application at risk.
While these challenges have added resistance to the adoption of DevSecOps across the federal government, recent advances in technologies and tools have taken significant strides towards overcoming that resistance. Advanced scanning tools no longer simply find and list vulnerabilities, but can prioritize them by their importance or urgency, based upon an Agency’s policies. Additionally, new developments in scanning technology can pinpoint the best place in the code to fix the vulnerabilities, resulting in an increasingly streamlined approach to remediation. Furthermore, rather than having to rescan an entire application each time new code is added, developers with the latest application security testing are now able to scan specific portions of code for weaknesses and remediate them on the fly – resulting in a considerable time-savings. With these new capabilities, development teams are now able to detect and eliminate vulnerabilities much more effectively, and in a fraction of the time previously associated with such efforts.
In response to the risks associated with DevSecOps frameworks, today’s software security solutions offer improved accuracy and automation. Teams using these solutions can now be confident that vulnerabilities are detected as they arise. They can also be confident that automated scanning processes will detect critical vulnerabilities requiring remediation when previously they were often missed.
Despite recent advances in DevSecOps adoption by Federal Departments and Agencies, it’s still in an early stage. Agencies continue to encounter internal resistance by development stakeholders, time and budget are always in short supply, and shortages of proficient security personnel (who are up to the task of managing software security programs) are endemic.
Technology continues to evolve, and it challenges Federal Departments and Agencies to build new proficiencies, such as the widespread interest and current increase in the implementation of container technology as the platform of choice for DevSecOps. While Federal Departments and Agencies experience short-term challenges in the adoption of DevSecOps, they are no longer doubting the effectiveness of it. We expect to see these practices become the norm rather than the exception. Improvements in integration, automation, turnaround, and remediation have become important influences — supporting the development of secure code, and giving it a greater priority across the board.