Program Levels 1 to 2 – from Ad-Hoc to Blueprint
This is post two in a series on the Application Program Maturity Curve, you can read the first post of this series here. As we’ve discussed, the program maturity model for Application Security has six levels. You should be able to recognize at which stage of the curve your particular organization is. The easiest one to recognize is an approach to appsec called “Do Nothing”. Let’s assume if you are reading this, that’s not you. If your organization is already pursuing an ad-hoc testing approach to manage the security of your software, you are not alone. Most enterprises with in-house application development teams do some kind of ad hoc appsec testing, usually during the software QA process. Most organizations who understand the fundamental importance of appsec start here. Understanding some simple ways to move forward, in incremental steps of maturity, is so important. To start, let’s outline a concrete path to get yourselves from an Ad-hoc Program to the next level, a Blueprint Program. 
Ad-hoc Program (Level 1)
Level 1: Ad-hoc Program Objective: What are we doing? Program: Inconsistent testing of applications with poor visibility and no development support. Time Period: Doomed to repeat or mercifully short… you decide. There are some serious limitations to an Ad-hoc Program, in fact let’s agree to use the term “program” here very loosely. The simple truth is that “ad hoc” is no way to approach software security. It’s appsec 101. They comprise inconsistent testing practices with poor visibility and no support. Here are the four tell-tale signs of an ad hoc addiction at your organization:
- We don’t know what we have.
- Application portfolio inventories are incomplete.
- Application ownership is not well defined or usage tracked.
- We don’t know what’s wrong.
- Some applications have been tested; others have not.
- Profiles of application risk to the business are unclear.
- We can’t get things fixed.
- Business units own application development and have not budgeted for fixes.
- Testing done just prior to release creates costly rework for developers.
- We can’t scale to support development teams.
- Unclear test results produce deluge of developer questions.
- No resources available to speak to development staff about remediation.
Ad-hoc approaches lead to a “scan & scold” mentality which breeds resentment among business units and their development teams. Maybe an attempt has been made to test earlier in the software development lifecycle (SDLC) and it failed? Not surprising. Without process controls in place, such a request requires too much effort to be effective. With limited appsec knowledge among development teams, vulnerability remediation efforts become fragmented and the results inconsistently applied. Simply put, the ad-hoc operational model is severely flawed, wastes money and fails to drive adoption internally. Lacking a formal appsec program, what are we really asking our colleagues to adopt, after all? A dedicated and rigorous Application Security Program is best pursued as a sustained, policy-driven program that employs proactive, preventative methods to manage software risk. It will deliver an effective software security strategy that addresses both immediate and systemic risks with a rigorous plan and continued investment. The key to positive return on investment over time is to start small and scale up with each milestone. It’s time to level up.
Blueprint Program (Level 2)
Level 2: Blueprint Program Objective: We know what we need to do. Program: The foundation of a real program, including an app inventory and governing policy. Time Period: As quick as 30 days. What isn’t known can’t be fixed. The Blueprint Program stage focuses on defining the “application perimeter” at your organization. Begin with an application discovery process to surface all internally developed software (hold off on vendor applications for now, as tackling that challenge is on a different curve altogether). Identify the business usage of each application and the development team key to maintaining it. The goal is to return increased visibility into your entire web application inventory as a preliminary step, before determining vulnerability intelligence about these apps and actionable guidance on flaw remediation. This discovery process should not be a one-time occurrence, but instead monitor for new vulnerabilities as the application perimeter grows and changes. This evolving blueprint of software risk then becomes reflected in organizational policy. Ideally, appsec policy definition should be completed as part of your organization’s larger business risk management practices. Veracode’s web application security monitoring solution is called APM, read more. The forthcoming posts in this series will examine the rest of the trajectory of the Application Program Maturity Curve. Post 1: About the Appsec Program Maturity Curve Post 3: Program Levels 3 to 4 – from Baseline to Integrated Post 4: Program Levels 5 to 6 – from Improved to Optimized
