Key Takeaways From SANS Report: Secure DevOps 2018: Fact or Fiction?

DevOps, with its focus on speed and incremental development, is changing the application security landscape. We’ve talked about this change a lot in the past couple years, and how security should fit into this picture. Now SANS is taking a look at how security actually is fitting into this DevOps picture in practice. In a recent survey, the sixth in a series of annual studies by SANS on security practices in software development, SANS for the first time explicitly focuses on DevOps.

They looked at how security fits into DevOps, where security risks are and how they are being managed, and the top success factors in implementing a Secure DevOps program.

The survey responses reveal both best practices and challenges of integrating security into DevOps. We include a few noteworthy points here.

Rate of security assessments is increasing

Organizations are increasing the rate of security assessments to keep pace with the new rate of software delivery.

Almost half (47 percent) of survey respondents report that their organizations are continuously deploying at least some apps directly to production. At the same time, the number of organizations assessing or testing the security of business-critical applications more than once per month has increased from 13 percent in 2017 to 24 percent in 2018, and those testing daily and continuously have almost doubled over the same period.

This is good news considering what our own recent research revealed about the security implications of frequently scanning code for security. Data collected for our most recent State of Software Security report found that there is a very strong correlation between how many times a year an organization scans and how quickly they address their vulnerabilities. Our data found that when apps are tested fewer than three times a year, flaws persist more than 3.5x longer than when organization can bump that up to seven to 12 scans annually. Once organizations are scanning more than 300 times per year, they’re able to shorten flaw persistence 11.5x across the intervals compared to applications that are only scanned one to three times per year.

Training on secure coding is key in DevOps

The survey asked respondents which application security tools, practices, or techniques they find most useful, and security training for engineers came out on top. Considering that, in a DevOps model, developers take ownership for security assessments with the security team taking on more of an oversight role, this response makes a lot of sense. As DevOps takes hold and security shifts further left in the development cycle, developers will need a solid understanding of both how to avoid introducing security vulnerabilities, but also how to efficiently remediate found vulnerabilities. We’ve seen this idea play out among our customer base; those that take advantage of eLearning on secure coding for development teams see a 19 percent improvement in fix rate over those that do not.

Fix rate is a management problem

According to 65 percent of the SANS survey respondents, corrective actions for found vulnerabilities are solely in the hands of developers. According to SANS, “This helps explain why vulnerabilities don’t always get fixed: Developers are forced into a difficult situation, under conflicting pressures to deliver changes quickly and cheaply, while also being held responsible for fixing vulnerabilities and other bugs.”

We’ve seen evidence of this trend in our own research. Our latest State of Software Security report found that vulnerabilities remain unaddressed for significant amounts of time. More than 70 percent of all flaws remain one month after discovery, and nearly 55 percent remain three months after discovery. One in four high and very high severity flaws are not addressed within 290 days of discovery.

What’s the solution to this “fixing” problem? Our VP of program management, Pejman Pourmousa, discussed this issue in a recent blog post. He emphasizes that although developers need to own security testing in a DevOps model, the security team can’t completely opt-out of the process; they play an important role in providing the guidance and support the development team needs in order to fix what they find. Part of that guidance stems from constructing smart policies. He stresses that application security policies should detail not only how often teams need to scan, and what scanning techniques to use, but also how long they have to fix certain flaws based on severity/criticality. In addition, security teams should build in remediation time between scans. Just scanning multiple times a day and pulling results into a tracking system is not useful if no one has the bandwidth to fix anything. You are better off setting a realistic scanning schedule (once a day) so developers have time to fix what they find. You can increase scan frequency as you become more secure and are passing policy on a regular basis.

Barriers, and enablers, of secure DevOps are not just technology

We’ve found that application security success lies just as much, if not more, with people than with technology, and this survey found the same.

The survey respondents reported that their biggest barriers to secure DevOps include shortage of skills, inadequate budgets, poor prioritization, lack of management buy-in—and the crushing weight of technical debt and security debt built up.

The top three factors that they reported contributing to secure DevOps success included:

• Integrating automated security testing into build/delivery tools/workflows
• Developing security champions in DevOps teams
• Training engineers on secure development/operations

Get survey report

Get the full survey results and analysis in the SANS report, Secure DevOps: Fact or Fiction?