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.

 

Pejman Pourmousa is Vice President, Program Management at Veracode, where he is responsible for the successful adoption of Veracode’s solutions by its customers. This includes a global team of 65+ Security Program Managers and Customer Success Managers that ensure the success of customers, by providing expertise, guidance and care in the area of application security. Pejman has spent the entirety of his career in the area of services management and delivery specifically around Compliance, Risk and Security. Prior to Veracode, he was a Manager of Client Services at SAI Global where he led the team responsible for the delivery of Compliance and Risk solutions across SAI Global’s client base. Pejman holds a Bachelors in Business, History and Secondary Education from Brandeis University in Waltham, Mass. 

Love to learn about Application Security?

Get all the latest news, tips and articles delivered right to your inbox.

 

 

 

contact menu