Application Security Posture Management (ASPM) aggregates data from all the AppSec tools in your organization in order to provide all stakeholders with a single-pane-of-glass view into all your applications’ current security stance. By centralizing security data in a single source of truth, the goal is to allow you to more easily identify, evaluate and prioritize issues across the entire software lifecycle.
ASPM largely emerged out of the Application Security Orchestration and Correlation (ASOC) market as an “uber” security tool – a tool that rolls up information from all the other tools across your organization. For those that have been cobbling together multiple security tools for years, ASPM provides a much better integrated solution. It can also act as a check to ensure Security teams are aware of issues raised by Developer/DevOp tools, which tend to be siloed.
Key ASPM features include:
- Centralized Integration Point: pulls in data dynamically and/or manually from common AppSec tools, test results and issue trackers, and aggregates the results. Some solutions will eliminate duplicate data and provide ways to suppress noise like false positives, while providing a holistic view across both development and deployment environments.
- Centralized Policy: while you can usually define and enforce security policies on a per AppSec tool basis, ASPM tools provide a centralized way to define, enforce and monitor security policy in a consistent manner. Some solutions allow the security policy to be defined in code, enabling teams to incorporate and enforce it as part of their workflow.
- Issue Prioritization: the ability to define risk criteria and apply them against the aggregated issues in order to surface those that should be tackled first. Typical risk criteria may include CVE severity, mission criticality, remediation SLAs and even KEV (Known Exploited Vulnerabilities) and VEX (Vulnerability Exchange) data.
- Reporting: identifies which vulnerable components are found in which applications; their current remediation status, and any existing policy violations. In this way, ASPM allows organizations to centrally measure and audit AppSec KPIs.
ASPM solutions intersect with Risk Management Platforms (like Synopsys Software Risk Manager), as well as Cloud Native Application Protection Platforms (CNAPPs, like Palo Alto Networks Prisma Cloud), which can be confusing when it comes to evaluating the market space. That said, some representative vendors might include:
- ArmorCode – aggregates data from application, infrastructure, cloud and container security scanners. By breaking down silos and amalgamating an organization’s AppSec posture, it allows users to quickly triage and identify critical risks. And as a centralized platform, it offers collaboration among all stakeholders who can take advantage of its adaptive risk scoring to help prioritize urgent issues. As such, ArmorCode can be a good choice for those that want to standardize security practices and vulnerability management across applications, infrastructure and software supply chains.
- Kondukto – integrates vulnerability data from common AppSec tools as well as security tests, aggregating insights and prioritizing critical vulnerabilities, while reducing noise by automating deduping and suppression rules. It also integrates with tools like Jira and Slack to facilitate the remediation process.
- Phoenix – integrates data from numerous security tools in a central, cloud-based platform that enables teams to quickly identify and prioritize vulnerabilities through its auto-prioritization feature. It also provides remediation steps and even estimates potential damages. Phoenix uses SMART tags to correlate application security and Cloud security, allowing you to take deployment environment into consideration when it comes to risk profile.
ASPM solutions can ensure that all stakeholders are aware of the results of AppSec tools whose results are traditionally siloed in different stages of the software development process, or else in production. This kind of visibility can raise awareness of critical issues, and help ensure that the greatest threats are fixed first.
More Secure Software; Not More Security Software
Knowing what’s at issue is half the battle, so for those that can’t see the forest for the trees, deploying an ASPM solution can make a lot of sense. But at the same time, ASPM is like implementing yet another security tool as the answer to the problem of having too many security tools.
What the industry really needs is secure software as opposed to more tools that promise security, because the unfortunate reality is that even with all the security tools we have today with which to identify vulnerabilities:
- 79% of codebases are never updated
- 81% of developers admit to shipping applications with known vulnerabilities
The gap isn’t an awareness gap, it’s a time and resources gap. That, and the fact that organizations continue to prioritize feature-complete over security-complete, despite the US government’s “Secure by Design” initiative that encourages prioritizing security over features.
One of the key drivers of the time-and-resource gap is the way in which organizations seem to be eternally in a reactive mode when it comes to open source vulnerability remediation. This stems from the fact that organizations start projects by importing prebuilt open source binaries, which means:
- Binary scanners immediately start throwing alerts (due to their limitations), which then need to be investigated.
- Investigations are either done by cybersecurity professionals, which can result in burnout and replacement by developers, who may not have the required expertise to deal with them in an efficient manner.
The result is less developer time and resources to deal with those issues that really need to be fixed, including vulnerabilities.
Rather than importing prebuilt packages whose security status is unknown – essentially allowing the fox into the henhouse and then trying to get rid of him – we recommend starting with a set of packages whose security status is known. Unfortunately, that guidance is all too often interpreted as “use an older version of a package previously approved by Security,” despite the fact that there is almost always a newer, less vulnerable version available. The result?
- In both 2022 and 2023, developers downloaded 2.1B open source dependencies with known vulnerabilities despite the fact that a fixed version was available.
But to ensure the security of an imported package means more than just checking for vulnerabilities. Other vectors include:
- Typosquatting, brandjacking, combosquatting, etc
- Malware, ransomware, trojans, backdoors, etc
- Dependency confusion, DNS cache poisoning, repository redirects, etc
- And many more
In fact, the only way to know the security status of an open source package is to build it securely from vetted source code. This means checking into your code repository all of the source code required to build your dependencies (including transitive dependencies), and then building them all from scratch for all the operating systems on which they’ll be deployed, from developer desktops through to production.
Most organizations build a few key dependencies from scratch (such as OpenSSL), but only the very largest enterprises would even consider vendoring all their dependencies in this way. Especially since you would then be responsible for patching that third party code going forward.
Instead, the simplest way to get out of the reactive vulnerability remediation trap is to make it somebody else’s problem: a trusted vendor that will not only ensure your set of starting dependencies are secure, but that can also automate the process of updating your codebase without breaking the build.
This is what ActiveState provides for our customers, including the ability to:
- Automatically build dependencies securely from vetted source code
- Start projects with a “known good” set of secure dependencies
- Update dependencies without breaking the build
In this way, you can become proactive about your application security posture, rather than being forever in reactive mode.
Conclusions: Proactive vs Reactive Vulnerability Management
The vast majority of vulnerabilities are found in open source software, which form 80%+ of the codebase for modern applications. There is no shortage of reactive solutions that can help you identify where your vulnerabilities are, including ASPM, but none of them can help relieve the bottleneck of solving the issues they find.
The unfortunate reality of modern application development speed is that the more alerts security tools generate, the more human fatigue results. And the more fatigue, the more likely a security issue will slip by into production, which is the exact opposite of the outcome desired.
In other words, the software industry continues to grow their security budget every year, but remains unable to achieve the security and productivity outcomes they expect.
It’s time to break the cycle by becoming proactive about application security, rather than reactive. ActiveState is here to help.
Next Steps
Watch our webinar on Achieving the Impossible: 3 Steps to Minimize Risk & Reap the Benefits of Secure Open Source to understand how you can centrally visualize not only all the open source in use across all the projects in your organization, but also correlate all the vulnerabilities present, as well.
