Not Every Security Flaw Is Created Equal

Just as middle-distance runners have long thought the limits of human endurance would prevent anyone from running a four-minute mile, many enterprises today believe there is a similar barrier to achieving both speed and quality with software delivery.

With applications evolving so quickly, the question is whether application security can keep pace. At most enterprises, software is rife with vulnerabilities, and security and development teams can face a mountain of identified but open vulnerabilities. More than 85% of all applications have at least one vulnerability in them, and more than 13% have at least one critical severity flaw, according to new research from CA Veracode.

Drawn from scans of more than 2 trillion lines of code, the data from the report provides a deeper understanding of the most common vulnerabilities, enterprises' ability to fix flaws after they're identified, and best practices to close flaws and reduce software risk more quickly. Greater agility is essential for delivering the competitive advantages that come with bringing quality software to market first.

It shouldn't surprise anyone in the security or development community that fixing flaws takes time. This is due in part to the sheer volume of software in production and the fact that app scans routinely identify new flaws. The most important function of an application security program is how effectively flaws are fixed once they are discovered. The most prevalent flaw types — such as information leakage, cryptographic issues, SQL injection, and cross-site scripting — appear year after year. That means organizations have made very little headway in creating awareness within their development organizations about serious vulnerabilities. This is most likely the result of organizations struggling to embed security best practices into their software development life cycle, regardless of standards in use.

CA Veracode's 2018 State of Software Security Report found that more than 70% of all flaws remain one month after discovery, and nearly 55% remain three months after discovery. Data also showed one in four high and very high severity flaws are not addressed within 290 days of discovery. In some of the worst-case scenarios, flaws lingered unaddressed for more than three years.

On average, one week after first discovery, organizations close out only about 15% of vulnerabilities. Within one month, closure rates reach just under 30%, and by the three-month mark, organizations haven't even made it halfway, closing only a little more than 45% of all flaws.

Flaw Persistence and Application Risk
Looking at the data another way, about one-quarter of all flaws will persist after 472 days. Viewing flaw persistence and fix velocity in this way is important because fixing flaws isn't just a mile marker for appsec programs; it's also a benchmark for measuring application risk. Detecting flaws doesn't reduce risk; fixing them does.

Consequently, organizations need to find effective ways to prioritize which flaws they fix first. Logically, you'd expect security teams to make a big push to fix the highest-impact vulnerabilities first — those that are less complicated to attack, offer more opportunity for full application compromise, and are more likely to be remotely exploitable. While some organizations are doing a good job prioritizing by flaw severity, our findings indicate that they're not considering other risk factors such as the criticality of the application or exploitability of flaws.

Contrary to what some security staffers might believe, developers simply can't wave a magic wand over the portfolio to fix the majority of flaws in an instant, or even a week. On top of that, teams must contend with other factors such as quality assessment, product release cycles, and other exigencies of delivering software to the real world. The sheer volume of vulnerabilities present in most organizations' application portfolios makes it necessary for them to make daily trade-offs between security, practicality, and speed. There are just too many vulnerabilities for organizations to tackle all at once, which means it requires smart prioritization to close the riskiest vulnerabilities first. Not every flaw type is created equal.

Why DevSecOps Works
Embedding security design and testing directly into the continuous software delivery cycle of DevOps is necessary for enterprises. This is the genesis of DevSecOps principles, which offer organizations a balance of speed, flexibility, and risk management. The difficulty is that, until now, it has been tough to find concrete evidence of DevSecOps' security benefits. Our analysis shows a very strong correlation between high rates of security scanning and lower long-term application risks, which we believe presents a significant piece of evidence for the efficacy of DevSecOps. The most active DevSecOps programs fix flaws more than 11.5 times faster than the typical organization.

The faster organizations close vulnerabilities, the less risk software poses over time. This holds true across industries and geographic regions; the more frequent the security scans, the faster fixes are made. By staying on top of new flaws as they are discovered, effective DevSecOps teams minimize the creation of new security debt.

Organizations that embed security checks into ongoing software builds, folding in continuous improvement of the application's security posture alongside feature improvement, will become both more agile and more secure. The earlier in the software development life cycle a security flaw is discovered the faster, easier, and cheaper it is to fix; therefore, organizations need to find ways to move the focus on security earlier in the development process.

One of the easiest and most effective ways to communicate that security is a priority for an organization is to begin offering training on how to write secure code. By educating developers on basic techniques, they can take ownership that is a little more personal because no developer wants to write insecure code. The next step is to bring security and development teams into closer contact, so each understands the others' processes and pain points. In addition, organizations must reduce friction with automated testing tools that can keep pace with accelerated development timelines. Solutions that check for flaws during the coding process enable developers to address vulnerabilities early on when fixes are more cost efficient. And because DevSecOps is equally concerned with security when software is in production, development teams need tools for testing applications after release.

Related Content:

Black Hat Europe returns to London Dec. 3-6, 2018, with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier security solutions, and service providers in the Business Hall. Click for information on the conference and to register.