It was a pleasure to return to the Gartner Security & Risk Management summit this year. Like the other attendees, I enjoyed the chance to not just reconnect with the community, but take a deep dive into the top of mind security initiatives and trends.  It was also the first time that as a community we got to discuss Application Security Posture Management following the release of Gartner’s latest report explaining its evolution from of one of last year’s 4 transformative technologies in Application Security – Application Security Orchestration & Correlation (ASOC).

Gartner’s definition of the technology is that “ASPM continuously manages application security risks through collection, analysis, and prioritization of security issues across software development, deployment and operation to improve visibility, vulnerability management and controls enforcement.”

However, with adoption of ASPM rapidly scaling moving from ~5% at present to 40% by 2026, and a crowded market, my biggest takeaway from this year’s conference was that enterprises need a clear understanding of not just what is ASPM, but what is not ASPM to avoid perpetuating the ongoing cycle of death by 1,000 DevSecOps tools.

So here’s how to identify if you’re looking at an ASPM-wannabe:

1. Your tool lacks SDLC awareness

How can you integrate Security into DevOps if you don’t know what’s going on in the software development lifecycle. A true ASPM platform will not just provide an integration point between the two teams, but actually bridge the gap by understanding the processes of each and translating one into the other so security teams can get the accountability they need (even when something isn’t done), and development teams can get the autonomy to make educated decisions without waiting for security feedback. Especially with 87% of engineering leaders being directly responsible or sharing responsibility for ensuring security of applications, this is critical to being able to develop more secure code without sacrificing velocity or agility – and actually eliminating the AppSec silos.

2. You can’t get application-specific risk-management

You can’t fix everything. In fact, your team only has time to fix about 5% of vulnerabilities – not to mention the fact that there’s only fixes even available for about 15% of criticals and highs – so you better know which vulnerabilities and other security issues are the ones that aren’t just important to your business, but to the specific application.

This manifests itself in several areas:

• Policy Deployment: A specific set of secure coding practices, policies, approvals, and controls should be able to be assigned to the application and orchestrated throughout the SDLC
• Risk Scoring : Each vulnerability should be prioritized based on the risk profile of that application
• SLAs: Enforce remediation SLAs across criticality both at an individual level or in the aggregate
• Workflows: There are no one-size fits all rules – they should be easily configurable for each application without coding to prevent ad hoc management 

3. You can’t create inflection points in the SDLC

How can you manage your application security posture if you can’t implement controls? A true ASPM platform should be your singular point of control for orchestrating and analyzing security requirements in the SDLC. This provides both visibility and predictability in the security gatekeeping function, as well as scalability. And it shouldn’t have to wait until release to be able to stop the pipeline – you should be able to stop the pipeline whenever works for your business.

4. You can’t respond to changes

Both security and software are living, breathing things and therefore the management of security requirements in the SDLC must be dynamic in response to changes either at the application or requirements level. This could be as simple as the roll-out of a new policy, or responding to a change at the application level. For example, when the data sensitivity classification changes in one of our customers’ APM solution, new policy sets & gates are rolled out to the application to either reduce or increase friction in the pipeline.   

And most of all, you can’t say you have application security posture management if you don’t work with Wabbi. Wabbi was founded to simplify the complexity of deploying security in the software development lifecycle – in other words, we were founded to manage enterprises’ application security posture (before there was an acronym). And therefore, we are committed to helping enterprises navigate the journey of how to bridge the gap between security and development. So here are some no pressure ways to get started:

• ASPM 101: Webinar on June 29
• What is ASPM?
• Sign up for a 1:1 conversation with me (we can even do it over coffee or a cocktail)