There is no haystack, only needles

ASPM in the security of an application

Ever look over all the vulnerabilities in your backlog and wonder how you got there? Or is that just me? Wouldn’t it be great if you could just find that proverbial needle in a haystack. The one vulnerability that really matters to the organization, and the one you need to focus on?

We have no issues implementing a new AST (application security tool) tool and then putting those results through the firehose straight into the lake of existing vulnerabilities. This ends up piling up in the massive backlog, with little context and little ability to identify what is an actual risk to the organization. Often teams are so overwhelmed with the expanding backlog of vulnerabilities that they are prone to ignore them in the face of an insurmountable problem. This leaves organizations further exposed to risk with potentially significant vulnerabilities being buried in the pile.

While there are a lot of tools that promise a low rate of false positives (sometimes, an oversell) and therefore allow the development teams to focus on just the true positives that have been found, most organizations run multiple tools of varying quality. Others may look to use a platform that has several AST tools in built in, leveraging integration or built-in AST. Regardless of the direction, most Application Security programs find themselves balancing several AST tools. This balancing act can often leave the organization trying to aggregate the data on their own, filter out the false positives, add context, and match that to the organizations risk.

Enter, ASPM.

ASPM vs ASOC

Before the onset of ASPM roughly a decade ago, the industry used the term ASOC (application security orchestration and correlation). This refers to a set of tools and practices designed to streamline and enhance the security processes within the software development lifecycle (SDLC). ASOC platforms aimed to orchestrate and integrate various ASTs—like Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), Interactive Application Security Testing (IAST), and Software Composition Analysis (SCA)—and manage the data they generate.

AST is not the same as ASPM. Where ASTs are focused on scanning and finding vulnerabilities, ASPMs are there to manage and assess the overall application security posture through context and reachability.

ASPM enhances and extends ASOC to include operational, cloud, container, and physical infrastructure while retaining much of the integrations that you would expect from a modern security tool.

Gartner defines ASPM as:

“Application security posture management analyzes security signals across software development, deployment and operation to improve visibility, better manage vulnerabilities and enforce controls. Security leaders can use ASPM to improve application security efficacy and better manage risk.”

That can seem like marketing fluff, and to an extent it kind of is. So, what are the primary goals of ASPM, and how can it help in an organization?

What’s in an acronym

Firstly a good ASPM will enhance the visibility that an organization has by providing a clear and comprehensive view of the security posture of individual applications and their components. By integrating AST tooling throughout the SDLC, ASPM helps identify vulnerabilities at every stage of development through to production. However, as mentioned, ASPMs should extend beyond the AST tools and include the capabilities to monitor applications in production environments allowing the ASPM to provide security scope beyond the development and testing phases. This reach helps reveal new vulnerabilities that may emerge after deployment, ensuring protection against ongoing threats.

Next, the ASPM should offer a platform for risk management by consolidating and correlating security data from all the various sources. The unified approach facilitates improved identification, prioritization, and management of risks across various applications.

ASPM is crafted not only to identify security issues but also to deliver significant insights into their characteristics and consequences often in the form of enhanced vulnerability data.

This deeper insight supports informed decision-making regarding security strategies and allows the organization to address the overall risk concern in a measured way.

ASPM products can and should facilitate the enforcement of security policies such as ensuring that necessary security tests are integrated and have been completed in order to provide assurance that the code is at an acceptable level of risk. This policy enforcement should be tailored to the development teams CI/CD (continuous integration and continuous deployment) pipeline. Enforcement at the CI/CD level means that each product, application, feature branch, etc. should have a set of policies that are relevant to that pipeline. This helps ensure that applications adhere to both internal security policies and external regulatory requirements.

Lastly, who doesn’t love a good process for issue resolution? By prioritizing actions in response to detected security issues or policy violations, ASPM tools should enable the organization to view and manage these vulnerabilities. This can’t be overstated, since the selling point of most ASPM tools is the ability to visualize, contextualize, and properly manage the inputs from the various data points. See my initial comments….we don’t need more unmanaged vulnerabilities, we need better visibility into what matters.

Visualize the ASPM world

ASPM systems should be able to analyze the wealth of data points to automatically apply triage logic, streamlining the process of identifying and categorizing security issues. More importantly, this filtering should help inform the organization’s overall risk level which should be visible at a glance in the ASPM allowing security teams to focus first on the most severe threats that could impact the organization's risk posture the most.

ASPM, with its data-driven approach, provides guidance into gaps on what the next steps should be to lower the risk profile, all in a real-time, automated fashion. It’s no surprise that Gartner predicts ASPM adoption to grow from 5% to 40% market adoption in only two-and-a-half years. - Forbes

Within the ASPM, you should also be able to see all the vulnerabilities from the various tools by risk level, category, application, and/or environment. In other words, you should be able to visualize all of your application security vulnerabilities in a single dashboard irrespective of the tool it came from, or the environment it is running in.

Yes, that means a lot of integration for most organizations. But with that integration comes a comprehensive application security strategy, enabling improved security and overall business resilience.

Sharing across the Organization

In an organization, using ASPM means that the development and operations teams work closely together to enhance the security of applications through a collaborative and integrated approach.

Starting with tool Integration the development teams use AST tools to identify potential vulnerabilities during early stages of software development. Preferably in the development environment or early in the testing environments. As the code migrates closer to production the operations teams employ various monitoring tools to detect active security threats, drift, and misconfigurations in those running applications independent of the environment it is running in (i.e. cloud, on-prem, prod, pre-prod).

Given this situation where findings are stretch across different environments, and across different disciplines, the ASPM should provide views for each specific team.

Development would likely want views relevant to coding and the testing phases, such as details from SAST or IAST findings. While operations teams concentrate on operational data like runtime anomalies or configuration issues.

The ASPM would then integrate the data from these diverse tools generated across both development and operations allowing all related data to be accessible from a unified platform. This integration ensures that vulnerabilities identified during development are visible to operations teams, and any threats detected in production are relayed back to development. There should be a really catchy term for this….maybe something like DevSecOps!

Welcome to the jungle!

If you think that having all this data dumped into one dashboard sounds like a big circus and only slightly better than what we have today, you’d be right. This data needs to be de-duped, correlated, and contextualized. ASPM systems correlate findings from different tools to provide a comprehensive view of each application’s security posture. For instance, a vulnerability flagged during SAST might also be detected in a different context during DAST. ASPM should link these observations to present a unified threat perspective. However, there can be challenges with the ASPM providing a refined list depending on the integration with the organizations ASTs vs utilizing native ASTs within the ASPM.

Lastly, for security and business leaders, ASPM provides an aggregated view of security risks and operational status across the entire application portfolio allowing for informed decisions about risk management, resource allocation, and compliance strategies. Data from the ASPM should be utilized to help build or shape a security maturity model allowing the organization to praise bright spots in the organization while highlighting room for improvement elsewhere.

Proactive and Reactive Security Measures

We love to tout the concept of being proactive in security. Reactive usually means that our security program lacks maturity. Yes, zero days can be a surprise, but a mature security program is often ready to spring into action. Where ASPM can help is by transforming reactive security measures into proactive safeguards by providing better visibility across the organization’s ecosystem and integration between the development and operations team as mentioned above. This integration fosters a continuous feedback loop between the two disciplines informing immediate remedial actions and triggering a review of similar potential vulnerabilities across all applications in development.

Consider a case where a new vulnerability presents itself through threat intelligence for an organization that runs applications in the financial sector. Using ASPM, the organization’s security team can quickly identify the presence of the vulnerability within their environment based on either the CVE or the profile of the vulnerability (i.e. impacted tech stack, product, platform, etc.).

Hint: A good ASPM will have this intelligence fed into the platform.

Since the ASPM is integrated with the CI/CD pipelines and development platforms, the organization can identify the vulnerability across all integrated environments allowing the ASPM to evaluate and assess the risk posed by the vulnerability. Given the application's role in handling financial transactions, the vulnerability is flagged as high-risk due to the potential for financial fraud, significant data breaches, and potential regulatory impacts. The ASPM tool prioritizes this vulnerability over less critical issues allowing the organization to recognize the impact.

Since the organization has configured its ASPM to enforce security policies automatically, the integration with the CI/CD halts further deployments of the affected application to prevent potential exploits. The operations team can coordinate its patching effort with the development team, facilitating a swift incident response.

While this case sounds more reactive, the organization can approach a novel vulnerability with calm while leveraging the visibility their ASPM provides. That’s a win!

What to look for in an ASPM

While there are several ASPM vendors out there, a few capabilities should be present to make the product worth pursuing.

Customized Policy Enforcement

The ASPM should support the creation of customized security policies tailored to the unique risk profiles of individual applications. These policies should consider the sensitivity of data, compliance needs, and the specific attack surfaces of applications, ensuring that security measures are appropriately stringent for high-risk applications while remaining proportionate for lower-risk ones. Furthermore, the ASPM should integrate deeply with development infrastructure, such as code repositories and build servers. This integration facilitates the automated enforcement of security policies at crucial stages of the application lifecycle, including during code commits and build processes.

Automated and Proactive Controls

The ASPM should employ automated guardrails that enforce predefined security actions during critical development stages, such as automated code analyses during builds. These guardrails dictate whether a build should proceed or be halted for further review, enhancing consistency in security measures and reducing human error.

ASPMs also need to provide attribution, traceability, and relevant remediation to the teams.

Additionally, ASPM integration with development infrastructure allows for the early detection of security issues, providing immediate feedback to developers and security teams. This enables quick remediation and reduces the risk of vulnerabilities progressing to the production environment, ensuring that security issues are addressed early in the development cycle.

Risk-Based Triage and Prioritization

The ASPM should aid in the effective prioritization and triage of security findings by assessing the risks they present to an organization. This process allows teams to focus on remediating the most critical vulnerabilities first, aligning their efforts with the organization's overall risk tolerance. Additionally, ASPM has the capability to automatically block the deployment of applications where identified vulnerabilities exceed acceptable risk levels. This proactive measure ensures that only applications that meet rigorous security and compliance standards are deployed, minimizing the likelihood of security breaches.

Streamlined Compliance and Reduced Delays

Lastly, the ASPM should ensure that all applications, especially those processing sensitive data or governed by strict regulations, comply with necessary security standards, mitigating the legal and financial risks of non-compliance. The ASPM should automate policy enforcement and feedback processes, significantly reducing delays that manual security checks can introduce. This efficiency is vital for maintaining the pace of software development while ensuring robust security measures are in place.

Where do we go from here?

ASPM should not be treated as another dashboard, or another AST tool. It’s neither. It’s intended to add value to the overburdened security teams by providing context, automation, visualization, and a bit of relief from the deluge of vulnerabilities. It does this by advancing the secure SDLC across development and operations by integrating ASTs and operational data, aggregating the findings, and giving the organization the visibility it needs to manage risk.

Without this there is an endless quest for efficiently sorting an endless pile of needles in a non-existent haystack.