What is Application Security Posture Management (ASPM)? [eBook]

Preface

Watts S. Humphrey was the first to say “Every business is a software business.” Today, organizations release software faster than ever using continuous delivery and cloud-native technologies. These trends bring unprecedented levels of change that introduce new challenges and risks for the business, all of which must be mitigated.

The heightened risk is the result of many factors – the most significant being the slower evolution of security when compared to their engineering peers. Today, most security strategies and tools focus on securing the posture of platforms (cloud infra & network) on which software runs, but not the software itself.

The increased risk is also attributable to the rapid pace of change, increased complexity of distributed applications, and the lack of visibility and context into how new threats impact the business. Specifically:

• The impact of Continuous Delivery (aka CI/CD): Developers now deploy code on-demand multiple times a day to production through automated pipelines like Jenkins, GitLab, and Azure DevOps.
• Hybrid cloud, containers, orchestrators, microservices, APIs, and serverless architectures are chaotic and difficult to discover, secure, govern, and manage.
• The exponential number of vulnerabilities from application security testing and cloud security tools that prioritize risk purely on the severity of a vulnerability, versus its exploitability and impact to business applications or data. As a result security and engineering teams are inundated with tickets for “must-fix” critical vulnerabilities.

As a result of these modern software delivery trends, there are daily or even hourly changes to an organization’s application’s security posture – meaning the security status of an application based on available resources (people, processes, and tools) to defend and react to change. A constantly shifting application security posture increases the likelihood that a critical business risk will lead to exploitation if left unmanaged.

At the same time, regulations around data privacy (e.g. GDPR, CCPA) have dramatically increased the business impact of risk introduced by faster software delivery. For example, code changes that impact the integrity and security of sensitive data flows have a material impact on the business, something that developers have never needed to think about — until now. According to a recent IBM report, the average cost of a data breach is now up to $4.35 million, which makes security everyone’s problem.

Research shows that the average enterprise security team has about 76 security tools. But even with the best tools and a modern security strategy, it’s hard to answer the following three questions:

• What are the top business-critical risks in production right now?
• How many microservices and APIs could be exploited in production?
• What sensitive data is exposed by applications in production?

Answering these questions today requires time, a village of people, and a great deal of patience. Why? Because the answers to these questions change daily, and by the time people find answers, they’re already out of date.

Security, like engineering, needs to automate and scale their manual processes so they can secure applications faster for the business as the speed of innovation increases.

Introduction

The link between software and business is crystal clear in 2023. Developers design, model, and implement applications using business requirements, use cases, and context.

However, the link between threats and the business today is bridged and calculated by security experts and manual processes. Today, most security processes and tools operate in silos. That is, they operate from different perspectives and postures (e.g. source code, operating system, cloud infrastructure, workloads, and network).

Teams also prioritize threats like vulnerabilities on a perceived severity score (e.g. CVSS score) without understanding the true exploitability or business impact of a threat. This results in hundreds or thousands of critical vulnerabilities being ticketed for resolution by security, cloud, or engineering teams.

For example, a team might detect a new threat with a critical 9.5 CVSS score in an OS library relating to several cloud infrastructure compute instances. The natural response would be to treat this as critical, create one or more tickets, and get it patched within the next 15 days.

A better response would be to understand:

• Is this vulnerability actually exploitable (e.g. internet-facing, in production)?
• Which business applications are impacted by this vulnerability?
• What data would be leaked if this vulnerability were to be exploited?
• Is this a top business-critical risk that needs to be fixed immediately over others?

By answering the above questions, teams can rapidly prioritize threats by the actual business risk, significantly improve their security posture, and dramatically reduce the number of tickets, noise, and engineering toil that go into their current manual processes.

But What Exactly is a Business-Critical Risk?

In this context, a business-critical risk is defined as a threat that is highly exploitable and poses a material impact on the business or customer; in the long term, it can threaten an organization’s brand, customer confidence, and/or shareholder value.

Based on this definition, a critical business risk is made up of three key attributes:

• A threat with high severity (e.g. vulnerability, architecture flaw)
• A threat attack surface with a high probability of exploit (e.g. internet-facing)
• A threat that poses material business impact (e.g. PII exposure)

Threats shouldn’t be exclusively tied to security. Threats should also cover the availability and resiliency of an application’s architecture and its ability to tolerate failure from good or bad actors. For example, when an application is unable to overcome a DoS attack, the true risk is the lack of resilience within the application’s architecture.

This ebook summarizes why current cybersecurity strategies in 2022 need a new approach called Application Security Posture Management (ASPM) to better manage the business risk of cloud-native applications running in production.

Read on to learn what ASPM is and how it can help you answer these three vital questions:

• What are the top business-critical risks in production right now?
• How many microservices and APIs could be exploited in production?
• What sensitive data is exposed by applications in production?

The Current Cybersecurity Solution Landscape

Despite rapid growth and significant investment, cybersecurity is still a moving target as new technologies, threats, and attack surfaces originate.

One area of security that remains a significant blindspot is how continuous application code and configuration changes (aka CI/CD) affect the security posture of applications running in production – specifically, the new attack surfaces relating to microservices, functions, APIs, dependencies, and their sensitive data flows.

Let’s first take a look at the types of security approaches and solutions available, with a summary of their benefits and limitations.

“Shift Left” – Application Security Testing (AST)

The shift left movement has helped many organizations create secure code by including security earlier in the Continuous Integration (CI) pipeline – while developers are writing code in their IDEs and while they are compiling and integrating code during the build phase. This allows teams to test and fix code for security vulnerabilities prior to delivery into production via a Continuous Delivery (CD) pipeline.

Application security testing tools, specifically SCA, SAST, DAST, IAST, test and evaluate application code for vulnerabilities in pre-production environments.

Here’s a brief rundown of the AST tools:

Software Composition Analysis (SCA)

Software Composition Analysis (SCA) inventories an application’s open source code libraries. SCA tools then compare the items in the inventory to a database of CVEs to determine whether vulnerabilities or licensing issues are present. According to the Linux Foundation, approximately 70-90% of any given application is open source.

While SCA is incredibly useful in evaluating vulnerabilities in open source components, its use is limited to development and testing, offering no insight into what’s actually deployed in production.

Static Application Security Testing (SAST)

Static Application Security Testing (SAST) is a way to find security issues very early in the software development lifecycle — literally as a developer writes code within their IDE. SAST identifies flaws and insecure coding practices and typically correlates the code and dependencies with known CVEs.

While SAST is incredibly useful in early application development – even before an app is functional – it offers no environmental, architecture, or runtime context. Essentially, what makes it great also limits its use. Other drawbacks include:

Limited test coverage. It’s impossible to achieve 100% test coverage. As a point of reference, Google uses the following benchmarks for testing coverage:

• 60% = Acceptable
• 75% = Commendable
• 90% = Exemplary

False positives/negatives. Some rules incorporated into SAST can produce ambiguous results, which can generate false positives/negatives. Resolving these possible vulnerabilities falls on engineers to understand, prioritize, and fix.

Slow to run. Depending on the size of an application and codebase SAST can be slow to run with a scan taking anywhere from a few seconds to several hours.

Dynamic Application Security Testing (DAST)

Dynamic Application Security Testing (DAST) tests running applications from the outside inward, looking for known exploits of interfaces, typically for web applications. DAST is used later than SAST in the software development lifecycle, once an application can function.

The downside to DAST is that, like SAST, there’s no way to achieve 100% test coverage. In addition, DAST can’t specify the location of the vulnerability within the code itself. And finally, DAST can be notoriously expensive and time-consuming.

Interactive Application Security Testing (IAST)

Interactive Application Security Testing (IAST) is an evolution of SAST and DAST combining both static and dynamic testing functionalities. Some IAST tools integrate with IDEs to provide immediate feedback to developers. IAST is powerful because it discovers vulnerabilities with code locations, which leads to quicker remediation.

The drawbacks of IAST echo those of the other *ASTs – limited application language support, and incomplete test coverage. In addition, these tools require agents which limit their scope, deployment, and value across complex hybrid cloud applications.

“Extend Right” – Application Runtime & API Security

In addition to SCA and *AST, application security extends to runtime in the form of Runtime Application Self Protection (RASP) and Web Application and API Protection (WAAP). The key difference is that these solutions actively monitor application end-user requests or API calls to detect and prevent attacks from bad actors.

Runtime Application Self-Protection (RASP)

Runtime Application Self-Protection (RASP) is an agent-based solution capable of controlling application run-time execution to detect and prevent real-time attacks. It’s different from other application security tools because it covers runtime. The most significant benefit of RASP is that it prevents applications from being exploited, even if vulnerabilities or hackers find their way in.

RASP has deployment limitations and coverage issues because it relies on agents and firewall rules, both of which need to be maintained as applications evolve over time. Additionally, RASP sits inside the application runtime, which can impact system performance and reliability due to its overall deployment complexity.

Web Application and API Protection (WAAP)

Web Application and API Protection (WAAP) is essentially an evolved Web Application Firewall (WAF). WAAP refers to tools that are specifically designed to protect public-facing web applications and APIs by mitigating a broad range of runtime attacks.

The main shortcoming of these solutions is that they are reactive and only detect threat attack surfaces that are actually exploited by bad actors (at run-time) versus what could be exploited by bad actors. For example, if a microservice exposes three APIs but only one of those APIs is invoked by a bad actor then these solutions wouldn’t know about the other two APIs because no events or telemetry would exist.

Key Takeaways

“Shift Left” and “Extend Right” tools and techniques offer specific benefits and can be part of an overall security strategy. However, even when incorporated as early and stringently as possible, there are limitations to what they can do and blindspots to what they can see.

Focusing on individual components of an application and relying on reactive measures isn’t enough to surface all potential threats and attack surfaces. Without full visibility and application architecture context, it’s impossible to understand each individual threat in relation to the complete application (and business), which precludes us from answering the three basic, yet incredibly hard-to-answer questions that we started with:

• What are the top business-critical risks in production right now?
• How many microservices and APIs could be exploited in production?
• What sensitive data is exposed by applications in production?

Cloud-Native Application Protection Platforms

The rise of the CNAPP, which integrates functions of Cloud Security Posture Management (CSPM), Cloud Workload Protection [Platforms] (CWPP), and Cloud Infrastructure Entitlement Management (CIEM) into a single unified platform, has helped consolidate security tools, reduce cloud and container misconfigurations, and protect platform processes and workloads.

CNAPPs traditionally focus on cloud configuration (CSPM) by interrogating cloud provider APIs and analyzing the accounts and permissions (CIEM) of cloud services. Many vendors have extended this visibility into VM and container orchestration services (CWPP) like Kubernetes and AWS ECS, specifically to observe the infrastructure and network interactions of container workloads. Finally, these capabilities have evolved recently to scan the contents of Infrastructure as Code (IaC) and containers pre-production.

Limitations

Visibility: CNAPPs offer limited visibility into an application because they typically only see and secure the cloud compute, processes, container orchestration, and workload layers. They protect the platforms that applications run on but not the applications themselves. The following diagram illustrates the partial visibility of CNAPPs:

CNAPPs can create excessive noise and alerts, making it challenging for operations teams to determine which alerts are actually critical, impact applications or the business, and should be prioritized first. For example, the same OS vulnerability might exist across hundreds or thousands of nodes, but there is no rapid way of knowing which applications are impacted, so a ‘fix all’ motion begins.

Data Privacy and Compliance: CNAPPs don’t provide visibility into how sensitive data flows through applications and dependencies. This absence of data flow visibility makes it impossible for CNAPPs to understand an organization’s compliance with regard to data privacy regulations like GDPR and CCPA.

Resilience: CNAPPs can provide system maps relating to the communication of cloud infrastructure, network, and workload/container dependencies. However, they are unable to map an application architecture end-to-end in terms of its services, functions, APIs, data flows, and third-party dependencies.

Key Takeaways

CNAPPs have helped teams securely provision cloud infrastructure and services with less risk of misconfiguration and fewer platform vulnerabilities. But no matter how well they secure clouds, containers, and workloads, their capabilities don’t operate at the application level, which is critical to gaining continuous, real-time insight into the security posture and resiliency of your applications in production.

What is ASPM?

Application Security Posture Management (ASPM) is the practice of making applications secure and resilient to significantly reduce business risk.

The goal of ASPM is to maintain a continuous and comprehensive risk posture of an application architecture running in production, including all its services, libraries, APIs, dependencies, attack surfaces, and sensitive data flows.

ASPM should allow teams to rapidly identify and prioritize the top business-critical risks that exist in applications at any point in time. ASPM should automate the process of determining business risk to understand whether threats are exploitable and pose material business impact.

While analyst firms have not yet established ASPM as a category, there is a growing and urgent need to fill this gap in coverage, particularly as enterprises embrace continuous delivery, cloud, and software APIs to innovate and deliver new experiences to their customers. Furthermore, legacy security solutions have struggled to adapt and scale to the constant change and diversity that modern cloud-native applications have created.

In short, ASPM should answer questions like this:

• What are the top business-critical risks in production right now?
• How many microservices and APIs could be exploited in production?
• What sensitive data is exposed by applications in production?

Where Does ASPM Fit in Cybersecurity?

ASPM is a security solution focused on applications in production. It complements the application testing tools that you use throughout your CI/CD pipelines, and it builds upon the secure foundations that cloud infrastructure testing and posture management tools provide.

ASPM exists to contextualize threats identified with existing security tools so teams can rapidly understand the business risk behind each threat (exploitability and material business impact).

Core Business Benefits of ASPM

The three main business benefits of ASPM are:

• Stronger security posture
• Better application data privacy and compliance
• Greater application architecture resilience

Benefit 1: Stronger Security Posture

ASPM can rapidly find and prioritize business risks that other cybersecurity solutions can’t detect – late-breaking vulnerabilities, changes to third-party dependencies, sensitive data exposure, and hardcoded secrets at the application level – because they weren’t present or detected in development but made their way to production. Even with a full arsenal of SAST, SCA, DAST, and IAST covering parts of your CI/CD pipeline, without ASPM, there’s limited application security coverage in production. More importantly, ASPM can contextualize threats so you know the potential business impact of each one.

ASPM can also automate manual processes, like security reviews and threat modeling, which are time-consuming and monotonous. These activities currently require accurate documentation, architecture diagrams, JIRA tickets, and completed questionnaires, which bottleneck the software development lifecycle.

Benefit 2: Application Data Privacy and Compliance

Continuous updates to cloud-native applications and microservices can impact and expose sensitive data. As a result, most engineering teams complete security questionnaires for major changes. According to GitLab’s 2022 Developer Survey, most engineers spend between one-quarter and half of their time on audit and compliance.

ASPM should ease data privacy and compliance tasks, which are often time-consuming and manual. Through automated discovery and mapping, ASPM provides deep visibility of how all application services and APIs manage data. ASPM makes it possible to report all sensitive data flows within an application, down to the columns and tables that are being accessed by individual services or APIs within a given application architecture.

Benefit 3: Resilient Application Architecture

Being able to detect, prioritize, and fix architectural changes with efficiency and precision is essential for any business. If application components or dependencies change, and those changes result in a mission-critical application crashing, it results in unplanned downtime. Aside from inconveniencing customers, downtime is costly. In 2014, Gartner estimated that the average cost of downtime was $5,600 per minute. Even if this estimate is conservative in current economic conditions, a 3-hour outage would cost over $1 million.

ASPM provides detailed, up-to-date architectural maps of applications with granular visibility of all services, APIs, libraries, dependencies, and data flows, which will help:

• Developers understand their application architecture. Many developers delay or neglect making critical documentation updates, which adds to perceived technical debt and hinders decision-making.
• Enterprise architects reduce technical debt. They’ll be able to lead their organization to create and maintain secure, scalable, and flexible application architecture.
• SREs understand application dependencies and their impact. They will be able to rapidly perform impact analysis of outages relating to cloud regions or application services.
• Executives get accurate and clear reports on any downtime-causing incidents so they have a complete picture of what’s affected and how long it will take to fix.

Critical Capabilities of ASPM

Now that we’ve covered the benefits of ASPM, let’s look at what key capabilities are required to deliver this value in an enterprise at scale:

• Cloud Application Discovery and Mapping
• Cloud Application Inventory
• Business Context Savvy
• Data Flow Discovery and Mapping
• Drift Detection
• Business Risk Scoring
• Unified Threat Database
• Policy-Driven Security Posture
• Automated DevSecOps Workflows
• Easy to Deploy and Scale

Cloud Application Discovery and Mapping

An organization’s application security posture must be comprehensive and complete if it is to be effective and trusted by teams.

One of the most prominent characteristics of ASPM is its focus on application architecture. From basic architectural discovery to detailed mapping, complete visibility into all dependencies like services, functions, APIs, libraries, data flows, and 3rd party dependencies is an essential part of ASPM.

This visibility is valuable to many different teams – including security, DevOps, engineering, SREs, and EAs – because it provides a single accurate system of record for cloud-native applications. Furthermore, teams can understand and trust an accurate map because it provides a situational context of the distributed chaos that most production cloud applications exhibit.

Cloud Application Inventory

Once an application is discovered and mapped, its architecture dependencies (services, APIs, data flows, third-party services, libraries) should be indexed, baselined, and stored for risk analysis, security posture insights, and reporting.

A searchable real-time inventory of a cloud-native application(s) allows teams to rapidly:

• Create a software bill of materials (SBOM) on-demand
• Query and report specific dependencies (e.g. all services with Log4J libraries)
• Query specific attack surfaces (e.g. all internet-facing APIs w/ PII data in prod)
• Report services with sensitive data that communicate with 3rd-party services

Business Context Savvy

If ASPM is able to help teams rapidly prioritize critical business risk, it must provide teams with enough context and metadata of how threats impact applications, services, APIs, and how these dependencies impact the business.

For example, developers often use clear naming conventions for services and APIs that perform a certain business function or task. This business context also helps quantify and prioritize risk, so that teams know what to fix first and why.

Relying on meta-data (e.g. manual tagging) and context from cloud infrastructure, OS, network, and containers is not enough given that cloud resources are dynamic and ephemeral. Maintaining complete context of business logic as it changes is fundamental.

Data Flow Discovery and Mapping

To augment business context, ASPM solutions need to be data-aware so they can discover, govern, and protect sensitive data within an application ecosystem. It also allows teams to prioritize risk based on what type of business data could be impacted or exploited.

An ASPM solution should be able to rapidly discover and accurately map all data flowing throughout your applications, services, APIs, and third parties in production. This level of visibility helps identify potential data privacy and compliance risks relating to different types of sensitive data like PII, PCI, and PHI.

As developers continuously update business logic and data access from distributed databases, caches, and APIs, it’s imperative that organizations capture, understand, and manage this activity as part of their application security posture.

Drift Detection

Drift is when unanticipated business risk is introduced through an application code or configuration change. ASPM provides the ability to baseline and version control an application architecture to detect when new dependencies are introduced, modified, or removed.

Cloud-native applications change hourly, therefore it’s imperative for teams to understand how architectures and attack surfaces are evolving, and what exposure they introduce.

Examples of drift:

• A new microservice introduces a new data flow and attack surface
• An existing API starts exposing PII data for the first time
• An EU-hosted application starts to access a US database hosting PII data
• An app starts to use an open source library that contains a CVE for the first time

Note: Drift in this context relates to the application layer, specifically the code/logic, and its run-time configuration within production.

Business Risk Scoring

ASPM takes a different approach to scoring risk by considering and correlating all attributes and dimensions of an application running inside a production environment.

To truly calculate business risk an ASPM solution should score risk using the following three dimensions:

• Criticality of a threat or vulnerability
• Probability that a threat attack surface could be exploited
• Criticality of business data that could be impacted or exposed

For example, a vulnerability could have a CVSS score of 9.9, which implies that it must be fixed right away. However, if this vulnerability exists in a monolithic application with no dependencies hosted inside a private data center, then the risk of this threat being exploited is very low. Further still, if this monolithic application does not process sensitive data, then the overall business risk is, in context, low.

In comparison, an internet-facing API that connects to a PII database that has a (lower) CVSS score of 8.2 is a critical business risk that is fully exploitable.

The purpose of ASPM is to provide a clear and contextual rating or score for each business risk so that teams can quickly identify the top 3 business-critical risks in production at any given time.

ASPM should not detect hundreds or thousands of risks like existing security tools. It should provide quality, actionable feedback to security and engineering teams so that noise, false positives, and toil are kept to a minimum. This way, the most critical risks to the business get fixed quickly and software delivery doesn’t get bottlenecked by security alerts or tickets.

Unified Threat Database

ASPM should integrate with databases of known vulnerabilities (CVEs), and provide unified analysis across all threats and attack surfaces so critical business risks can be identified, scored, and prioritized effectively.

Fortunately, there are several open-source tools that offer this capability at no cost, like Aqua, OSV, Mend, and Snyk.

ASPM’s role is to simplify and automate the manual process of determining what is critical and should be acted upon by teams. The more intelligence and inputs that ASPM can ingest and process from its ecosystem, the more coverage it can provide to an organization’s application security posture.

Automated DevSecOps Workflows

An ASPM solution should integrate with, and automate DevSecOps toolchains and workflows so that security and engineering processes can be streamlined and scaled as change becomes exponential.

ASPM should enable DevSecOps automation in the following areas:

• Cloud Service Providers & Container Orchestrators (Kubernetes, AWS, GCP, Azure) – Seamless and scalable integration across all cloud-native applications
• CI/CD Pipelines (Jenkins, GitLab, Azure DevOps, Harness) – Seamless integration with CI/CD pipelines so security postures are created for pre-production and production
• Issue Tracking (Jira, ServiceNow) – Automate actionable feedback to engineers
• CMDB and Service Catalog/Inventory (ServiceNow) – Continuously update all application assets and CIs that belong to each cloud-native application
• AST/SCA/CNAPP (Wiz, Snyk, Prisma) – Unify, contextualize, and score security findings from all existing security tools through the eyes of an application

Easy to Deploy and Scale

If ASPM cannot be scaled easily across your organization then its adoption and value will fail to reduce your business risk and improve your application security posture.

Modern cloud-native tools today use agentless approaches to integrate with clouds and applications thru standard open APIs and permissions. These tools are simple to install and are less intrusive to run and maintain across hundreds or thousands of applications in your organization.

More so, every application is unique in terms of its code libraries, architecture, dependencies, and configuration. This means ASPM must be capable of discovering and mapping complex heterogeneous applications without requiring manual configuration by people. The aim of ASPM is to automate manual processes not to burden existing ones.

How to Operationalize ASPM

You’re sold on the value of ASPM. You’ve allocated the budget and decided to move forward with an ASPM solution. Now what?

Establish an Owner

Every new process or initiative needs an owner who has clear objectives and goals that can be measured over time.

ASPM ownership will vary slightly according to the maturity of an organization’s security strategy, team, and tools. In modern progressive organizations, the owner of ASPM will be on a DevOps/DevSecOps or a Cloud/Platforms team. In other organizations, the owner may be on Application or Product Security teams, depending on their scope and responsibilities.

• Recommended Owner: DevOps/DevSecOps or Cloud/Platform Team

Keep reading for recommended metrics and goals.

Define Clear Roles and Responsibilities

In addition to the owner, establish your key stakeholders and determine the extent to which they’ll interact with ASPM (daily, weekly, monthly). Think about the following:

• Who is responsible for acknowledging and actioning a business-critical risk?
• Who is responsible for informing stakeholders of a business-critical risk?
• Will you rely on ASPM workflow automation? Or will the owner take this on?
• Who is responsible for fixing the business critical risks that ASPM raises?
• Who is responsible for governing and reporting status of fixes?

Specifying who is responsible for what will help reduce the ambiguity that often creates friction between teams.

Define Objectives and Goals

Finally, clearly define your objectives and goals for ASPM so you remain focused.

Example Objectives:

• Improve application security posture
• Discover and inventory all application microservices and APIs
• Identify and govern all 3rd party service dependencies
• Identify all sensitive data that could be exploited

Example Goals:

• Fix all critical business risks within 24 hours
• Reduce the number of security tickets by 50%
• Reduce the time of security architecture reviews by 50%
• Reduce hardcoded secrets by 75% in 5 mission-critical production applications

Integrate and Incubate ASPM

The first barrier is integrating ASPM into your cloud-native applications and DevSecOps tools. For this reason, it’s imperative that the owner of ASPM has permission to deploy new tools inside production. Specifically, the owner must be able to give ASPM the permission it needs to continuously interrogate and scan your cloud-native applications.

Phase 1: Integrate ASPM

Start small and find your first cloud-native application to integrate. Operationalize ASPM for one application team and create a blueprint or best practice for other teams in your organization. Document every challenge, use case, and success and use this information to iterate and sell the value of ASPM to other teams.

Phase 2: Incubate ASPM

Scale ASPM to 10 cloud-native applications and/or teams. This is about creating a repeatable ASPM process that can scale to deliver consistent use cases, workflows, and value across an organization without requiring a team of dedicated experts to oversee each ASPM deployment.

Phase 3: ASPM-as-a-Service

This is where application teams can onboard themselves by simply following the ASPM playbook you created in phases 1 and 2.

What Does ASPM Look Like in Operation?

What Does Success Look Like?

Now that you’ve established the people who will help make ASPM a success in your organization, it’s time to think about what success will look like. While there’s no right or wrong way to think about ASPM success, there are some basic quantitative and qualitative metrics to consider. For the quantitative metrics, we’ve aligned the targets to research findings from Googles’ s 2021 State of DevOps report.

Metric 1: Business-Critical Risk Introduction Rate

Description: Of the changes pushed to production, what percentage contain business-critical risks?

Target: Using the change failure rate statistics from Google as a model, here are some targets for the percentage of changes introduced to production containing business-critical risks.

• Elite: 0-15%
• High, Medium, and Low performers: 16-30%

Metric 2: Business-Critical Risk Resolution

Description: From the time that a business-critical risk is identified, how long does it take to resolve the issue?

Target: Using the time to restore service statistics from Google as a model, here are some target timeframes for business-critical risk resolution:

• Elite: Less than one hour
• High: Less than one day
• Middle: Between one day and one week
• Low: More than six months

In addition to the KPIs that you can measure with numbers, here are some qualitative ways to think about ASPM:

• Has ASPM eased manual tasks like security reviews?
• Are stakeholders using ASPM?
• Has ASPM reduced friction between teams?

Conclusion

ASPM is an innovative top-down way to identify and manage critical business risks in your applications. It augments and integrates with your existing tool ecosystem so you can contextualize the true impact of threats, vulnerabilities, and attack surfaces that impact your applications, end-users, and shareholders.

Finally, ASPM will help you answer questions like below, continuously and with confidence.

• What are the top business-critical risks in production right now?
• How many microservices and APIs could be exploited in production?
• What sensitive data is exposed by applications in production?

Beyond that, ASPM makes life better. Here’s a quick rundown of what awaits you.

Ready to explore ASPM? See Bionic in action now.