Application security, DevSecOps

What to do when the honeymoon period ends with an application

Share
Reducing code flaws

The relationship between an application and its security has parallels with any other relationship. At first, there are a few issues, which once addressed, can get fixed quickly. Then comes the honeymoon phase, when the relationship stabilizes and all feels well. But as with all relationships, that phase will come to an end and this all-important question arises: “How do we navigate the end of that period and continue to grow together in a safe and sustainable way?”

For any given application, the honeymoon phase typically lasts about one-and-a-half years, during which time there’s no correlation between the rate of application growth and the introduction of flaws. While the code base of applications grows about 40% per year on average, during this initial phase, 80% of applications do not introduce any new flaws, as found in our recent study. Once that state of bliss ends at the one-and-a-half-year mark, flaws creep in and climb steadily through to year five.

Organizations must take a close look at the honeymoon phase and question: what’s different during the first couple of years that lets applications stall the introduction of flaws – and why do flaws creep in after about one-and-a-half years?

A contributing factor may include the personnel changes in the later phases of an application’s life. For instance, when the original development team still works on the product, the components and practices used to build it are generally well understood. However, when people move on to new projects or new jobs, different developers are brought in, and some information inevitably gets lost in the shuffle. The application may end up in the hands of contractors or people who lack context as to how or why elements were originally implemented. Meanwhile, new functionality gets built to satisfy customer needs, and teams have to also manage that code. In a nutshell, as applications grow, they also become more complex. It takes about 18 months in which the dormant flaws of an application begin to  “wake up.”

Navigate the changing relationship

Whether because of increased application complexity or changes in how they are managed, there’s clearly a tendency for flaws to increase steadily over time. But there are steps organizations can take to counter that trend:

  • Remediate early and quickly. Be more intentional about fixing flaws soon after they’re detected so they don’t build up into unsustainable debt. Also, teams need to fix flaws soon after they are detected so they don’t build up into unsustainable debt. It should take only a short time to fix a flaw, and it must happen quickly since applications have accumulated flaws by the time they reach two years old. By the time an application reaches 10-years-old, there’s a 90% chance it has at least one flaw. Plus, the sooner a flaw gets fixed after being introduced, the more likely the developer will retain the knowledge and hopefully avoid similar flaws in the future.
  • Future-proof applications via automation. Automated scanning of applications can significantly improve an organization’s ability to identify and remediate flaws quickly. In fact, when APIs are used to introduce code scanning into an application’s CI pipeline, the probability of new flaws being introduced drops from 27% to 25%. And even when new flaws are introduced, the presence of integrated scanning reduces the volume of new flaws by nearly 18%. Scan frequency and regularity are also important: a scan in any given month reduces the probability of new flaws being introduced by 0.4%. Conversely, when months are skipped between scans, there’s a higher chance of finding flaws during the next scan. Setting up automated scans from day one, removing worry about manual patching or updating down the road, can provide peace of mind now and for the future. 
  • Prioritize developer training. We also need developer training to effectively build and manage the security of applications – and organizations that emphasize hands-on training measurably reduce the chance of flaws being introduced in the first place. Application teams whose developers have completed a total of 10 Security Labs – a hands-on training program that teaches developers how to exploit and patch vulnerabilities in real-world code – reduce the probability of introducing new flaws by 1.8%. And that’s in addition to reductions realized via other activities such as CI automation. And in a previous report, Veracode found that organizations taking at least one course in Security Labs reduce the time to remediate 50% of flaws by two months. Automation might be a work in progress for some teams, but training is within reach and should get priority given its benefits.
  • Establish application lifecycle management. Trying to determine who owns an application—business leaders, developers, or the chief information officer—presents a confounding question, especially if an organization tries to inventory all its applications and owners. Personnel and priorities can change before a complete inventory is finished. So, it’s better to start with the required information for a few applications and then build your pipeline from there.

    We also may need to take a closer look at the length of the application’s lifecycle. And we need to acknowledge the upward trend of flaws as an application. Organizations may need to decide between action and inaction. It's helpful to clearly understand the supportability and quality control phases in the organization. Then, businesses can more confidently introduce discussions about change management, resource allocation, or organizational controls. Risk appetite or tolerance might also come into play if everyone remains aware of the elements accumulating.

    Those initial discussions could lead to planned obsolescence for some applications, while also enabling a review of the quality control measures involved in continuous product engineering for applications that won’t get retired anytime soon.

    Application lifecycles include a predictable pattern of flaw introduction, but no matter how predictable, like all relationships, they take work. Improving application security means taking the necessary steps—including automation and developer training—to ensure a safe and sustainable lifecycle. There’s no easy fix, but making some of these small adjustments now and implementing a purposeful application lifecycle management program could get teams in the right place in the coming years. It’s the necessary investment in the software security relationship that will let an application savor the honeymoon phase and go the distance.

Chris Eng, chief research officer, Veracode

What to do when the honeymoon period ends with an application

Here are four steps security teams can take to reduce inevitable code flaws.

Chris Eng

Chris Eng is Chief Research Officer at Veracode. A founding member of the Veracode team, he is responsible for all research initiatives including applied research and product security. Chris is a frequent speaker at industry conferences and serves on review boards for Black Hat USA and the Kaspersky Security Analyst Summit. He is also a charter member of MITRE’s CWE/CAPEC Board. Bloomberg, Fox Business, CBS, and other prominent media outlets have featured Chris in their coverage. Previously, Chris was technical director at Symantec (formerly @stake) and an engineer at the National Security Agency.

Get daily email updates

SC Media's daily must-read of the most current and pressing daily news

By clicking the Subscribe button below, you agree to SC Media Terms of Use and Privacy Policy.