This is the third entry in a blog series that looks at each stage of an application security program’s maturity and outlines your next steps as you move toward an advanced program.
We typically see organizations fall within one of these four stages of application security:
If you are in the expanded application security stage, you’ve made significant progress embedding security into the software development lifecycle (SDLC). You probably use several assessment techniques, and have multiple touch points in the SDLC where security assessments are conducted. This is certainly a solid application security program that significantly reduces your organization’s risk at the application layer. However, with the shift to DevOps, developers are looking for more autonomy and shunning any processes that slow them down. These trends are requiring some tweaks to the expanded program to move it to the advanced stage.
How do you move to an advanced application security program that gels with a DevOps model? It’s time to start fully integrating automated testing into the SDLC, measuring and refining your program, and making sure you’re covering third-party applications and code.
In addition, emerging solutions allow developers to assess smaller sections of code in progress, rather than waiting to assess only completed applications. For instance, CA Veracode Developer Sandbox lets development teams test and fix code between releases without triggering a failed policy compliance report to the security team, and CA Veracode Greenlight gives developers secure coding feedback in seconds, privately in their IDE, so they can fix issues before they even commit the code.
Another consequence of the increased development speed: the reliance on third-party apps and code.
And this externally sourced code is increasingly becoming the target of choice for cyberattackers because it’s typically insufficiently secure, and it gives them more bang for their buck — they can target hundreds to thousands of companies with a single exploit.
To address third-party application vulnerabilities, consider an application security solution that:
To manage vulnerabilities in open source components, make sure you have an inventory of all components in use and their locations. Often, when major vulnerabilities in open source components are disclosed, companies struggle to respond because they don’t know which of their applications contain components, or even which components they are using.
Application security solutions are increasingly enabling complete visibility into all of the components development teams are using, as well as the versions being used.
The reality is that time to market often trumps security, and apps are deployed with vulnerabilities. Prepare for this scenario by adding runtime protection to your application security mix.
Runtime protection technology identifies and blocks application security threats in real time. This technology enables applications to “self-protect” by reconfiguring automatically, without human intervention, in response to certain conditions.
To take your program to the next level, it’s time to start measuring it against KPIs, and reporting on the results. Based on the results, you can tweak your existing goals or policies. In addition, your KPI reporting will prove that your program is making a positive impact, and ease the process of getting additional buy-in and support.
Get details on these steps, and all the steps involved in building an application security program – including tips and advice from someone’s who’s been there – in our new guide, From Ad Hoc to Advanced Application Security: Your Path to a Mature AppSec Program.