3 Strategies for Bringing Rigor to Software Security

We're in the midst of a transformational shift in software security. Companies will soon bear responsibility for insecure software and can no longer play the victim card.

Recently, President Biden's administration released its long-awaited National Cybersecurity Strategy, created with the hope to "secure the full benefits of a safe and secure digital ecosystem." As expected, it focuses to a large extent on software security and who should be liable for its vulnerabilities. Stating that "markets impose inadequate costs on — and often reward — entities that introduce vulnerable products or services," the strategy calls for making organizations more liable for shipping insecure software.

Putting aside the debate about regulation versus market forces, it's hard to argue with the strategy's implicit assertion that insecure software code is endemic. As security professionals, it's our job to examine why insecure software is so prevalent and understand how to address it. Furthermore, with this plan, software security would no longer be a nice-to-have: Companies will be liable for the security of their products. Therefore, now is the time to bring rigor to software security.

The Root of Vulnerabilities

Insecure software often starts at the beginning, where flaws are introduced. But before diving in, it's important to be clear about the terminology.

A "flaw" is an implementation defect introduced when code is written that can lead to a "vulnerability" — an exploitable condition within software code that opens the door to an attack. Flaws accumulate over time resulting in "security debt" — the flaws you don't fix over the lifetime of an application. Security debt has been an important driver in the rise of DevSecOps, which integrates security throughout the software development life cycle.

Veracode's most recent "State of Software Security" research report took a fine-grained look at the factors contributing to flaw introduction, using data drawn from static analysis of more than 750,000 applications.

It found that no matter the size, applications grow steadily at about 40% a year through the first five years. But the rate of new flaw introduction follows a different pattern. When a new application is onboarded, the number of flaws undergoes a precipitous drop, most likely as an initial scan discovers accumulated flaws. The app then enters the "honeymoon phase" through the first year and a half, during which nearly 80% of applications introduce no new flaws. When the honeymoon ends, however, the introduction of flaws grows steadily until plateauing around year five.

The most common flaws discovered vary widely depending on the type of scan conducted, as static, dynamic, and software composition analyses involve different techniques and can detect different issues. There was some overlap among the top flaws found — information leakage showed up in all three — but there were enough differences to underscore the importance of using multiple scan types.

Scan frequency also has an impact. We found a marked reduction in both the probability of new flaws and the actual number of them when scans were performed the previous month. Using application programming interfaces (APIs) to automate the scanning process was also beneficial in reducing the probability and number of flaws.

Stepping Toward More Secure Applications

Preventing all flaws from being introduced in the first place would be ideal, but it's just not practical. Our research uncovered three recommendations for making applications more secure.

Our first piece of guidance is to remediate security flaws as early and quickly as possible. By the time an application is two years old, we see applications increasingly accumulating flaws. It's clear that something happens to the application or to the groups developing them. Whether increasing application complexity from years of steady growth or diminishing focus on production applications over time, this familiar pattern of an upwards slant, shown in our research, is clear.

Our next piece of guidance is to prioritize automation and developer training. Awareness of the most common flaws and how they are introduced makes a notable difference in reducing their numbers. We saw this in results from organizations whose developers had completed 10 hands-on security training courses. Our research found that completion of 10 training courses correlates to a 12% reduction in the number of flaws introduced.

Lastly, companies need to establish application life-cycle management. Establishing who owns an application will help keep it secure, but don't try to make a comprehensive list upfront, because you'll never finish it. It would be better to start with the necessary information for a few applications and build the list iteratively from there.

Maintaining an application isn't just a matter of deciding whether it's needed, but also how long it should be in production. This is important given the growth of flaws that occur over time and the amount of attention that will be paid to it in later years.

Rigor Is a Requirement

In today's security climate, software security is paramount. With the National Cybersecurity Strategy planning to add real teeth into enforcement actions, software vendors have extra incentive to reduce the security debt of their applications.

Understanding how flaws are created and how best to remediate them can help ensure both the security and viability of software products.

Rigor in software security means being thorough at every stage of the modern software development life cycle as the shift of responsibility turns to you.