I remember the first time I had to listen to a legacy vendor sales team pitch their “ASPM product” to me as a customer. For this vendor, the ASPM solution was just mapping the coverage of their own scanning across the pipelines in your organization. This version of ASPM was far short of a real product offering – it was just something to help you deploy what you already had, with some light reporting features. I ended up apologizing to the sales team that they were being forced to sell this as a separate product, as the entire value of ASPM lay in its ability to also make sense of third party data.
In the last two articles (Component #1 and Component #2 of a Complete ASPM), we defined the critical detection capabilities for total application testing coverage, starting with your source code management and pipelines, and moving to complete application testing. This last article is the piece that ties it all together: posture management.
Unfortunately, Gartner started ASPM by transitioning it out of ASOC, which was a category solely for enterprises to manage their existing application security tools. A lot of ASPM confusion has been separating this posture management aspect out as a separate product, but to me, there’s tremendous value in its inclusion in the larger platform.
While your ASPM provider should provide all the scanners you need, the reality of the existing scanner landscape in the enterprise is challenging. Most companies have various multi-year contracts in place with different vendors that they’ve had to accumulate, and have invested training into their existing tools. These legacy vendors also typically have difficult deployments that might make them time consuming to phase out, whether for compliance or technical reasons. In these cases, it’s essential that an ASPM integrates with other providers, and enables the creation of sane workflows to actually get things remediated. In this article, we’ll talk about why you might have other scanners, what kind of context they can give, and why this overall capability is so important.
Third Party Vulnerability Data
For better or for worse, a lot of the application security industry is driven by the needs of massive enterprises. These enterprises will likely never have a single tool covering 100% of their application security program. For them, there are edge cases everywhere – whether it be obscure languages, large existing deployments for global teams, or legacy applications that are no longer easy to access.
Even if a single company supports every language and architecture, it’s not uncommon to see disjointed development teams who have implemented their own favorite scanner of the month and put up a fight to remove or change it. In these cases, it’s important that the security team gets the visibility provided from their tools, without needing to force a change if it’s not the right time.
This is the first benefit of having an ASPM with strong third party integrations – using your ASPM provider as a driving force for your application security program. With your other scanners, what you actually want is the niche data they may be able to provide. For example, you may use a DAST scanner with specific framework support, an API Security solution with tracing, or a legacy SAST with support for an obscure language.
For all of these different tools, the key outcome is that a developer is going to get a ticket to fix or triage an issue. That’s why an ASPM matters – it can drive the workflows between all of your different scanners. No longer do you need python scripts shoveling vulnerability data between bespoke services, instead, the ASPM can ingest all of the findings from a realistic combination of open and closed source tooling.
When you hear about the average number of cybersecurity tools per organization (usually up past 20), it’s part of a pitch towards general consolidation; however, this misses the reality that many of these tools exist because they’re covering edge cases that can’t get supported anywhere else. Some kinds of visibility is just hard to get, or costly to replace – for these cases, you need an ASPM that can ingest findings instead of tell you it doesn’t matter.
Runtime Context
While many ASPM’s scan code, they typically also rely on data from third parties to create rich runtime context for findings. For example, many organizations have separate teams for managing infrastructure, as well as development pipelines. In these situations, an ASPM can ingest third party data either from cloud providers directly, or from CNAPPs to create a complete picture of where your application is running.
I also include creating the code to cloud picture as part of third party data integrations, as well as an important facet of ASPMs. Findings from scanning production only make sense when they’re tied back to the code that created them! ASPM’s are uniquely situated to ingest runtime data, and use it to tell developers the exact lines of code that need to change in order to correct the vulnerability.
This is another area where a lack of third party support just doesn’t cut it – even if your ASPM offers its own agent, it’s highly unlikely it will get deployed over your CNAPP or CDR for runtime capabilities. Instead of requiring additional agent deployments, it’s much more convenient (and better security) if you can maximize the telemetry from an existing agent.
It’s All About the Workflows
Putting all this data together into one place is one piece of the puzzle – CISOs crave nothing more than a nice dashboard telling them which teams are doing a good job, and which teams the CTO should go rough up a bit. Indeed, these dashboards only work for flexible data platforms. Anyone who’s tried to satiate a CISO’s lust for reports with a “single pane of glass” that’s not a BA tool knows the pain. ASPM’s ability to get all this data into a single place gives leadership the answers they’re looking for.
Beyond metrics, the real promise of ASPM is having a single place to tell developers where to go and do security work. As fun as PR comments are, the security experience for developers in DevOps oriented organizations can be very confusing. They might have multiple security testing dashboards, pipeline checks, and then even tickets for vulnerabilities discovered in production. Pivoting between all of these different scanners proves to be a nightmare, and consolidating onto a single platform is unrealistic given the number of use cases.
What I love most about ASPMs is how they simplify developer life – instead of trying to explain 15 types of security testing and different tools with different remediation timelines, developers can instead get told to “just check Cycode.” This simplicity brings a lot of power to trying to operationalize an AppSec program, as developers have a single place they can check for what they’re supposed to be doing, and to manage false positives and their workflows.
Workflows are the final important piece of building meaningful integrations. While shift left was supposed to mean that we just pipeline blocked our way to success, more and more teams are realizing that integrating into developer workflows means more than just blocking pull requests. The challenge is that different developer teams have different preferences and workflows for their teams. Some teams run Kanban, some run sprints, others run out of Github issues – it’s essential that an ASPM be flexible with regards to workflows. Different teams need to be comfortable configuring their own workflows that work best for them. I find the search into the dashboard or workflow to be a particularly elegant way to set this up – if a result matches these conditions, do this with it.
Conclusion
As fun as all the scanning is, an ASPM just isn’t quite complete until it also works with third parties. As we covered in the article, this is for a myriad of reasons, but most importantly:
- There will always be additional data needed
- Context is always helpful
- ASPM should drive your AppSec program
Some providers view this feature as “just a dashboard;” however, the truth lies at the heart of what it means to be an ASPM – everything you need to protect your application. There’s a recognition that no application protection will be complete from a single place, and that putting the whole story together is more important than only selling your own scanners.
