What Makes an AppSec Program Successful: A Program Management Perspective
I have spent the entirety of my career in the area of services management and delivery, specifically around compliance, risk and security. I have had the good fortune of seeing over 1,300 program deployments across all size companies spanning every industry. Today, I am the Director of Program Management at Veracode, working to help customers successfully adopt Veracode’s solutions.
I wanted to share my insights on the different types of application security programs deployed and the pitfalls and successes of each. While some may challenge my opinions below, this is what I see for the majority of programs. Some companies do have successful programs using other methodologies, but it has been rare from my point of view.
Starting with the least successful to the most successful:
Manual-Only Program aka “Ancient History”:
With this program, apps are only checked during a production gateway or in production by a team of pen testers, typically so late in the process that a release will occur no matter the outcome of the testing. With the move to Agile, DevOps and CICD, this is no longer a realistic method to use.
|
Program Must Haves |
Scoring |
Comments |
|
Scale |
|
Focus only on top critical apps |
|
Speed |
|
Days to weeks |
|
Risk Reduction |
|
Some on top critical apps |
|
Automation |
|
None |
|
Integration into SDLC |
|
None |
|
Cultural Acceptance |
|
Effect is minimal overall |
|
Developer Involvement and Education |
|
None |
|
Multiple Testing Techniques |
|
None |
|
Central Governance & Reporting |
|
None |
|
Cost Effective |
|
Very expensive with no scale |
Assurance Gateway aka “Too Little Too Late”:
This is a program where testing occurs by a security team right before going to production. This program typically features dynamic and manual testing or both. At this point, with tight deadlines, the release occurs without any fixes. In addition, finding these flaws so late in the development process is very costly to fix (10X more costly then catching them early in the SDLC). With the move to Agile, DevOps and CICD, this is no longer a realistic method to use.
|
Program Must Haves |
Scoring |
Comments |
|
Scale |
|
Focus only on most critical apps but many can bypass this process due to deadlines |
|
Speed |
|
Days |
|
Risk Reduction |
|
Some fixes late to post production |
|
Automation |
|
Some automated tools used |
|
Integration into SDLC |
|
None |
|
Cultural Acceptance |
|
Developers see this as slowing down their process and don’t feel responsible for owning security. |
|
Developer Involvement and Education |
|
Developers are handed flaws to fix with minimal guidance |
|
Multiple Testing Techniques |
|
Dynamic and pen testing |
|
Central Governance & Reporting |
|
Some centralized reporting for security |
|
Cost Effective |
|
The later flaws are found, the more expensive |
Center of Excellence aka “Scan and Scold”:
A program in which security is deep into the SDLC process with developers and requires certain tests at various stages of development. Many companies are at this stage today. For security, this gives them the ability to make sure applications are securely built throughout the development life cycle and provide developers with exactly what they need to fix, and keep building. Some organizations even have experts in the security team to help the developers. While this process worked for a while, it is now being seen as “scan and scold” by developers. With increased pressure to move faster, developers don’t want to have someone governing their every line of code. In addition, security never has enough budget or people to actually scale this operation. With the move to Agile, DevOps and CICD, this is no longer a realistic method to use.
|
Program Must Haves |
Scoring |
Comments |
|
Scale |
|
Security can’t build a team large enough |
|
Speed |
|
Multiple touch points in SDLC that aren’t automated |
|
Risk Reduction |
|
Some fixes on apps that are tested |
|
Automation |
|
Some automated tools used |
|
Integration into SDLC |
|
Some dev teams will allow for tools into their process to appease security, most won’t |
|
Cultural Acceptance |
|
Developers see this as “scan and scold.” Security is intruding on processes they own, and then telling them their code is “ugly.” |
|
Developer Involvement and Education |
|
Developers are handed flaws to fix with minimal guidance. |
|
Multiple Testing Techniques |
|
Static, dynamic, and manual based on app and stage |
|
Central Governance & Reporting |
|
Some centralized reporting for security |
|
Cost Effective |
|
Security team can’t hire enough people to make this work. |
Programmatic Approach aka “Generation 2.0”: (Best described as a race car.)
A program that has centralized governance by security, but testing and fixing are owned by development in an automated fashion throughout the build process using static and dynamic testing. In this approach, security owns setting policies, tracking KPIs and providing security coaching to developers. In addition, security owns providing developers with support in integrating scalable tools like Veracode into their SDLC. Developers own testing applications in their development environment, fixing flaws to pass policy and continuing to build code – no matter the environment: Agile, DevOps, CI/CD. In this process, security-related defects are just another bug during the build process, and developers have the tools and guidance needed to fix them. At the same time, security can govern the program to make sure KPIs and policies are met. Some considerations here: you need a scalable solution that provides centralized reporting and governance, policy management and integration points. In addition, it needs to provide accurate reporting and minimal setup for developers to get involved. Lucky for us, Veracode exists and can do all of this.
|
Program Must Haves |
Scoring |
Comments |
|
Scale |
|
SAAS instant on and unlimited users a must |
|
Speed |
|
Minutes, as testing occurs seamlessly throughout SDLC |
|
Risk Reduction |
|
Policy is set by security so developers have a goal to reach for every test |
|
Automation |
|
Solution must make testing as easy as taking a breath |
|
Integration into SDLC |
|
Developers own testing in their build process |
|
Cultural Acceptance |
|
Security becomes everyone’s job and a team effort |
|
Developer Involvement and Education |
|
Developers discover flaws to fix and have guidance from the security team as needed. |
|
Multiple Testing Techniques |
|
Static, dynamic and manual based on app and stage |
|
Central Governance & Reporting |
|
One tool set that gathers all KPIs including policy compliance |
|
Cost Effective |
|
Developers now own testing and remediation, so a smaller security team can focus on value-add items like governance and coaching |
Hopefully this has been useful; here are five takeaways:
- Security needs to focus on central governance, KPIs, policies and guidance (not testing and fixing)
- Developers need to own scanning and fixing in adherence to policy
- Policy needs to be achievable and become more rigorous over time, but start easy for adoption
- Testing has to happen throughout the SDLC, with multiple testing techniques based on application criticality
- With fast-moving development environments, integration is a must-have so that the entire testing process is embedded into a developer’s workflow
From my view, all of this can only happen with the right solution, which has to scale, provide accurate results and be easy to use. It also needs to provide central reporting, seamless integrations and policy management.
For more AppSec best practices from those who have been there, check out our new eBook, 5 Lessons From an Application Security Pro.
Related Posts
