Your Next Steps if Your AppSec Program Is in the Expanded Stage
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.
Integration and automation
- To keep up with the speed of development in a DevOps world, AppSec solutions have to be able to:
- Scan code quickly, without significant configuration
- Integrate security assessments into the same APIs that are used for development
In addition, emerging solutions allow developers to assess smaller sections of code in progress, rather than waiting to assess only completed applications. For instance, Veracode Developer Sandbox lets development teams test and fix code between releases without triggering a failed policy compliance report to the security team, and Veracode Static Analysis IDE Scan gives developers secure coding feedback in seconds, privately in their IDE, so they can fix issues before they even commit the code.
Third-party applications and 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:
- Works directly with your software supply chain — on your behalf — to assess and remediate suppliers’ code
- Ensures third-party code adheres to your security policies before you implement it
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.
Making the case with metrics
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.
Related Posts
