Pushing Left, Like a Boss – Part 9: An AppSec Program

In my talk that this blog series is based on, “Pushing Left, Like a Boss”, I detailed what I felt an AppSec program should and could be. Since then, I’ve learned a lot and now see that there are quite a few activities that you can do, but it’s the goals and the outcomes that actually matter. Our industry has also changed quite a bit since I wrote that talk (written in 2016, first seen in public 2017, this article first published in 2019 and republished here in 2021).

My first international talk, at AppSec EU, 2017. It feels so long ago.

My previous thoughts on what a basic AppSec Program should be:

• Vulnerability/Security Assessments and VA scans
• Threat modelling
• Secure Code Review
• Penetration Testing
• And that these activities should cover both COTS (configurable off the shelf products, like SharePoint or SAP) and custom apps (homemade software)

For bonus items I had listed:

• Developer education
• Secure coding standards
• Secure Coding Libraries
• Reference materials

And for “extra special situations” I recommended the following (which will be explained in the next blog post):

• Bug Bounty Programs
• Capture the Flag Contests (CTFs)
• Red Team exercises

Anne Gauthier of OWASP Montreal, myself (pre-WeHackPurple) and Nancy Gariché of Secure That Cert and OWASP DevSlop. In the background is Christian Folini of the OWASP CRS project. I had no idea how important these people would become to me at the time.

I’m going to preface this next part with two thoughts.

You can’t do security “right” if you aren’t doing IT “right”. If you can’t publish fixes for a year+ because your processes are broken, if you are underwater in technical debt, if you have dysfunction within your IT shop already, this is going to be very hard. I suggest starting with modernizing your systems and entire IT team as you modernize your security approaches, hand-in-hand. Don’t give up, you can do this! Take one item, aim for it, and continue on until you’re doing well.

If you have poor communications between the security team and the rest of IT this will be another hurdle that you have to work on. Culture plays a big part in ensuring your efforts are successful. I’ve released a bunch of videos on my YouTube channel on this topic, start with this one.

My new vision for an AppSec program:

• A complete picture of all of your apps. Bonus: alerting, monitoring and logging of those apps.
• Capability to find vulnerabilities in written code, running code, and 3rd party code. Bonus: the ability to quickly release fixes for said issues
• The knowledge to fix the vulnerabilities that you have found. Bonus: eliminating entire bug classes.
• Education and reference materials for developers about security. Bonus: an advocacy program, creating a security champion program, and repetitive re-enforcement of positive security culture.
• Providing developers with security tools to help them do better. Bonus: writing your own tools or libraries.
• Having one or more security activities during each phase of your SDLC. Bonus: having security sprints and/or using the partnership model (assigned and/or embedding a security person to/within a project team).
• Implementing useful and effective application security tooling. Bonus: automating as much as possible to avoid errors and toil.
• Having a trained incident response team that understands AppSec. Bonus: implementing tools to prevent and/or detect application security incidents (can be homemade), providing job-specific security training to all of IT, including what to do during an incident.
• Continuously improve your program based on metrics, experimentation and feedback from any and all stakeholders. All feedback is important.

I’d love to hear your thoughts on my new application security ‘prescription’. Please comment below.

Up next in this series we will discuss the AppSec “extras” and special AppSec programs; I will discuss all the things in this article that I have not previously defined for you.