We are seeing a significant surge in attacks against applications such as cross-site scripting, brute-force attacks, and SQL injections, which is raising significant concerns. So much so that application security has been labeled “nonnegotiable” and has appropriately become a priority for many, while Jen Easterly, director of the Cybersecurity and Infrastructure Security Agency (CISA), is campaigning for the tech industry to take responsibility for secure products.
Technology solutions like penetration testing and code scanning are undeniably valuable for mitigating insecure software, but in themselves they are not enough. As many as 70% of organizations are missing critical security steps in their software development life cycle (SDLC) and vulnerabilities are rising exponentially. To solve this dilemma, enterprises need to shift their focus from finding, patching, and fixing vulnerabilities to proactively ensuring they don’t deliver insecure code in the first place. This requires human foresight, and as a result, greater investment in education for all those responsible for developing software to ensure they can not only recognize key security principles and vulnerabilities, but also apply their knowledge to novel situations to better secure applications.
Going Beyond Code Scanning
An overdependence on code-scanning tools, or source code analysis tools, is an example of security being left too late in the SDLC. Code scanning to identify vulnerabilities before an application goes live is a key cog in the secure software development machine, yet prevention is always better than cure (as we know from Boehm’s law that flaws become more costly to fix over time).
The main issue is that code-scanning tools run the risk of large numbers of false positives, eventually leading to “alert fatigue,” where developers ignore any flaws flagged, eventually creating a false sense of security. What’s more, when critical issues are highlighted, it likely becomes the developer’s responsibility to identify and fix this insecure code, and they need the knowledge to actually apply these fixes.
This is where greater investment in secure coding training and continuous education for the developer and everyone that supports them across the SDLC comes in. Code scanning still has a significant role to play, yet it would be far more valuable if supported by programmatic training on security principles and best practices. This is not simply to raise “awareness” of key vulnerabilities but to empower teams with the knowledge to code securely and prevent critical issues before they reach scanning tools or even production. It can also reduce the burden on developers by avoiding added pressure to patch at the last stage. Instead, the approach should be to “start left” and ensure security is baked in from the beginning (as advocated by Easterly).
Research backs this up; an EMA survey of software development professionals found only 10% of organizations utilizing code scanning tools prevented more vulnerabilities than those that don’t, however, continuous training greatly improved code security for over 60% of organizations that adopted it. But it is not necessarily the case of one or the other: EMA argues that a combination of code scanning, code reviews, and continuous, third-party training is the best approach to more secure software development.
Embracing More Secure Habits
Coding securely essentially needs to become a more lasting and ingrained habit. Yet behavioral change is challenging without the knowledge and education to support it. Truly enacting change to ensure application security becomes nonnegotiable means investing in developer and SDLC team training that encourages and enables more secure habits. And it’s important to recognize that these secure habits will change depending on the role of each professional.
For example, development leaders will not be personally responsible for developing code, so instead will need to look at how they become accountable for developing applications with fewer vulnerabilities. Ensuring security features are considered “lifeboat” features — an essential before releasing code — may require a shift in habits but will be invaluable for boosting application security. For software developers themselves, their secure habits may be embracing those all-important code scans or reviews earlier along in the development process, but this will only be relevant if they can recognize the value of secure coding and have the knowledge to reduce as many vulnerabilities as they can in the first place.
If you haven’t done so already, it’s time to take the first step toward solving this application security dilemma. Yet the SDLC needs to go far beyond reactive patching and code scanning, and instead look at how to empower teams, reduce late-stage burdens, and invest in continuous education if we’re really to turn the tide on rising application vulnerabilities.
