ASPM vs ASOC vs RBVM: wading through categories

Software development changes rapidly. The rise of the cloud, accelerated release cycles, and an explosion of new technologies like containers and microservices have fundamentally changed the industry's approach to the delivery of software across both applications and infrastructure.

The approach to securing software however, has not changed as rapidly. The ability for software security to keep pace with software delivery is constrained by technology and operational silos, and repeated manual tasks. The market is evolving to address these constraints and better enable security teams to address the ever-changing reality of software delivery. With new tools comes new acronyms of course, and it’s easy for new acronyms to get confusing and for messaging to overlap. 

Let’s take a look at four different terms, what they’re all about, and what use they can potentially serve: ASPM, ASOC, RBVM, and AppSecOps.

Application Security Posture Management (ASPM)

ASPM is the acronym for Application Security Posture Management. This relatively new category is a response to the lack of visibility that security teams often struggle with when it comes to applications. The focus of ASPM tools and use cases is on finding and uncovering problems in your application environment. The end goal here is visibility, and application security visibility is where ASPM ends. Different approaches to ASPM include directly scanning code to identify assets, inspecting applications at runtime, or integrating with multiple scanning tools to create a holistic view of applications.

ASPM was created to deliver cloud application security visibility and categorization, and is excellent for this need. Beyond this need is where ASPM ends however. This approach will not help you with visibility into your security posture outside of the cloud application layer or with your workflow and automation needs.

Done well, ASPM will give you great visibility into your cloud application assets. However, ASPM ends at applications. If you’re also looking for visibility into infrastructure, or want to bring in context from places like DAST, pen testing, and other application-related areas, ASPM-only tools won’t be sufficient. 

If you are struggling with too many repetitive manual tasks when it comes to sifting through AppSec issues, then you will need to look beyond ASPM. Correlation and orchestration are beyond the scope of ASPM. The next acronym is very focused on those specific pieces in fact.

Application Security Orchestration and Correlation (ASOC)

ASOC, the acronym for Application Security Orchestration and Correlation, is a rising Gartner term in recognition of the importance of tooling orchestration and issue correlation in AppSec. It’s not enough to just get visibility into your application assets and security posture, you must be able to correlate application findings across the SDLC, orchestrate security testing, and ensure that each tool is working in concert. The key focus for ASOC is the aggregation of data from different sources to provide a centralized place where you can orchestrate scans and correlate findings across these tools.

When ASOC first arrived on the scene, it was not fully fleshed out. First generation ASOC tools tended to not deliver on the promise of the category, and were only able to deliver visibility with limited orchestration and workflow capabilities. Next generation ASOC tools are building upon this foundation to address workflow needs in addition to the visibility component. They provide visibility into AppSec, with some degree of automation and orchestration across the tools. 

What ASOC doesn’t address is broader workflows and human processes within AppSec, as well as the broader picture of software security (i.e. applications and infrastructure together). ASOC tools are missing an important orchestration piece: orchestrating the human side. ASOC tools are built to orchestrate non-human processes (e.g. triggering a scan), but don’t help automate human processes like SLA adherence and ticket escalation.

Next generation ASOC tooling further delivers on the promise of correlating AppSec findings. If you’re looking for a centralized way to aggregate and correlate AppSec findings, ASOC will deliver. However, if you’re interested in the broader picture of software security or the workflow for triaging and remediation, then ASOC-only tools won’t be sufficient.

If you’re struggling with handling vulnerabilities across infrastructure assets in addition to applications, then you may want to look beyond ASOC. The next acronym is built for combining application and infrastructure vulnerabilities.

Risk Based Vulnerability Management (RBVM)

RBVM, or Risk BasedVulnerability Management, is all about vulnerabilities. It recognizes that vulnerabilities show up across many different architectures and technologies, and that attempting to address them in a vacuum is not sufficient. The risk-based approach here is focused on categorizing the risk a vulnerability represents to the business itself, as well as the risk it represents to the industry. If you have a vulnerability with a high CVSS score, that seems important to fix at a glance, but if that vulnerability doesn't have any known exploits, it's not as important as something with a lower CVSS score that does have exploits. Likewise, if the vulnerability is found on a backend data sciences application in your network with no PII, for example, vs an internet-accessible web app that's core to the business with PCI/PII requirements, the risks are quite different for the same vulnerability. This approach is all about prioritizing vulnerabilities by the real risk to the business.

UVM has the elements of aggregation, correlation, and prioritization, but with a focus primarily on infrastructure assets instead of applications. UVM doesn’t bring together the application and the infrastructure it is deployed on, and the corresponding impact that may have on the broader software security picture. 

You may have noticed a pattern here with these acronyms. Operationalizing all of the above acronyms has traditionally been a siloed practice. AppSec tools are owned and run by the developers or AppSec team, and infrastructure tools are often managed by the Vulnerability Management team. However, software security spans across both application and infrastructure layers. That’s where the next term comes in.

ASPM + ASOC + RBVM = AppSecOps

We’ve taken a look at four different categories in this post. Quickly, ASPM is about security visibility for cloud applications. ASOC is about orchestration and correlation for applications. RBVM is about managing vulnerabilities across assets. AppSecOps spans across applications and infrastructure to cover software visibility, orchestration, automation, and vulnerability management. It is essentially the superset of ASPM, ASOC, and RBVM. 

If you have a specific need for application security visibility, correlation and orchestration, or vulnerability management, then you should consider ASPM, ASOC, or RBVM, respectively. If you face silos and friction between AppSec, Infrastructure security, and development teams, or are looking for the ability to understand and secure the broader software security picture across your environment, then you should consider an AppSecOps solution.

Application Security Operations (AppSecOps)

Despite the seeming focus on AppSec in the name, AppSecOps is all about software security: bringing application security and infrastructure vulnerability management together in a unified platform to accelerate software delivery. AppSecOps is born from the thinking that applications and infrastructure are intertwined in modern software delivery, so achieving strong software security means breaking down the silos between applications and infrastructure, and delivering visibility, workflow, and automation across both human and non-human processes. 

True visibility means including the entire environment. No single tool can see everything, so the only way to get this is by aggregating data from a wide variety of security tools across applications, on-premises infrastructure, cloud, containers, and more. With a focus on integrations, AppSecOps solutions aim to be the single platform to ingest findings across all of these areas – usually normalized, de-duped, and correlated – for holistic visibility.

Visibility is important, but just the first step towards software security. Once you have a view of your software security, you need to be able to take action. The other element of AppSecOps is focused on the “Operations” part. The volume of data across applications and infrastructure means that you need automation as part of the prioritization and triaging efforts to keep up. AppSecOps solutions aim to group, correlate, and automate manual tasks related to triaging to enable security teams to keep pace with the speed of software development.

The final key element of software security is remediation. With a unified view of the environment, AppSecOps solutions enable security teams to improve their workflows. They integrate with developer and DevOps ecosystems and enable security teams to better get security issues into developer workflows (e.g. automated ticket creation in developer tools). With SLA tracking and other such features, AppSecOps solutions aim to improve the collaboration between security teams and developers.