How to Write Secure New Code and Reduce ‘Security Debt’

For secure app development, earlier, frequent scanning is critical

how to write secure new code

It’s no secret that the volume, sophistication, and consequences of cyber attacks have escalated dramatically in recent years. That trend has organizations scrambling to tighten up the security of the software applications they’re developing and deploying.

Based on the 10th annual edition of Veracode’s State of Software Security (SoSS) report, however, most organizations still have a long way to go in this regard.

Consider some of the SoSS report’s core findings:

  • Of 85,000 applications tested, 83 percent had at least one security flaw and 20 percent had high-severity security flaws on initial scan
  • The average time required to fix flaws is 171 days
  • Two out of three applications initially fail to pass industry standard compliance tests
  • Only 56 percent of flaws eventually get fixed

This last statistic contributes directly to what Veracode has labeled the “security debt.” Essentially, this debt is an overall measure of the security flaws across an organization’s code. All too often – if understandably – developers tend to address the most recently identified flaws first, which can result in a growing security debt as older flaws slip under the radar and accumulate.

As organizations attempt to address these challenges, it’s important for them to understand that security testing must occur repeatedly throughout the entire software lifecycle. This best practice should be a core element of DevSecOps initiatives, which aim to produce better and more-secure software by fostering increased collaboration among an organization’s development, security, and operations teams.

Running security tests early, often, and regularly has proven critical. “It’s important to scan as early in the development cycle as possible,” says Chris Kirsch, who works on product strategy at Veracode. After that, he says, “Companies that reduce flaws evenly and consistently over time do better in flaw reduction than those who do flaw reduction in bursts.”

Security testing can’t stop once code under development goes into production. Even if code is thought to be secure and hasn’t been modified since being deployed, it could still harbor flaws. For example, a new vulnerability is discovered in an open source library on which the code is based. “Good solutions will alert you of a new vulnerability without having to rescan because they remember the open source components you used,” says Kirsch. Another reason to continue scanning is that static analysis solutions continually work to improve their detection capabilities based on the latest research.

Comprehensive security scanning must go beyond static code analysis to include dynamic analysis. Only by testing running code in its production environment can vulnerabilities such as security misconfigurations be identified. In addition, staying in compliance with applicable regulatory requirements often demands that companies conduct penetration tests, which may also expose unidentified code flaws.

Given the large volume of software vulnerabilities they’re likely to encounter, organizations need methods to prioritize their remediation efforts. A number of variables come into play in this regard. Among them: a flaw’s severity, its age, its exploitability, the ease of remediation, and the criticality of the application in which the vulnerability resides.

While weighing these and other factors, there is one simple rule of thumb companies can follow. “Initially, companies should focus on high-security flaws that are easy to fix,” Kirsch advises.

Of course, the best way to eliminate security vulnerabilities in software code – and to reduce an organization’s security debt over time – is to prevent such flaws in the first place. Accomplishing that goal requires that organizations do a good job of training developers in how to write secure code, while also giving them the tools and resources they need to do so.

“Along with training developers, you can reduce the rate of flaw introduction by giving them immediate feedback directly in the IDE (integrated development environment),” Kirsch says. “You want to make sure insecure code doesn’t go into production, especially  if it’s a critical app.”

For further information about how Veracode can help your organization develop secure code and reduce your overall security debt, go to [link to come].


Copyright © 2020 IDG Communications, Inc.