White Paper

Application Security
Posture Management:
Securing Cloud-Native
Applications at Scale
CrowdStrike White Paper 2
Application Security Posture Management:
Securing Cloud-Native Applications at Scale

Table of Contents
Preface 3

Introduction 4

What Exactly Is a Business-Critical Risk? 5

The Current Cloud Security Landscape 6

Securing Cloud Infrastructure, Containers and Workloads:

Cloud-Native Application Protection Platforms (CNAPPs) 6

Securing Cloud-Native Applications 7

“Shift Left” 7

“Extend Right” — Application Runtime and API Security 10

Key Takeaways 11

What Is ASPM? 12

Where Does ASPM Fit Into Your Cybersecurity Strategy? 12

Core Business Benefits of ASPM 13

Key Characteristics of ASPM 17

How to Operationalize ASPM 22

Establish an Owner 22

Define Clear Roles and Responsibilities 22

Define Objectives and Goals 22

Integrate and Incubate ASPM 23

What Does Success Look Like? 24

Conclusion 25

Glossary of Key Terms 26

About CrowdStrike 27
CrowdStrike White Paper 3
Application Security Posture Management:
Securing Cloud-Native Applications at Scale

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 is that many of
today’s security strategies and tools focus on securing the posture of platforms — the cloud
infrastructure and networks on which software runs — but not the software itself.

The increased risk is also attributable to the rapid pace of change, the increased complexity of
distributed applications, and the lack of visibility and context into how new threats impact the
business. Due to continuous integration/continuous delivery (CI/CD), developers now deploy
code on-demand multiple times a day to production through automated pipelines like Jenkins,
GitLab and Azure DevOps. Furthermore, hybrid cloud, containers, orchestrators, microservices,
APIs and serverless architectures lead to chaotic application deployments that are difficult to
secure and manage. Finally, there are too many findings and alerts from application security
testing and cloud security tools. Most of these tools prioritize risk purely on the severity of a
vulnerability rather than exploitability and impact to business applications or data. As a result,
security and engineering teams are inundated with tickets for “must-fix” critical vulnerabilities.

Due to 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 truly critical
business risks get missed and ultimately result in a substantial breach.

At the same time, regulations around data privacy (e.g., the GDPR, CCPA) have dramatically
increased the business 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 rarely considered — until now. According to a 2023
IBM report, the average cost of a data breach is now up to $4.45 million, which makes security
everyone’s problem.1

Research shows that the average enterprise security team has about 76 security tools.2 Many of
these tools solve real problems, but even with the best tools and a modern security strategy, it’s
hard to answer the following three questions:

1. What are the top business-critical risks in production right now?

2. How many microservices and APIs could be exploited in production?

3. 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 an
answer, it's 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.

1
IBM, Cost of a Data Breach 2023 Report
2
Panaseer, 2022 Security Leaders Report
CrowdStrike White Paper 4
Application Security Posture Management:
Securing Cloud-Native Applications at Scale

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

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

Security 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. These threats
manifest in hundreds or thousands of incident tickets. These tickets are assigned to practitioners
across cloud, operations and engineering teams for resolution.

For example, a security team might detect a new vulnerability with a critical 9.5 CVSS score in an
operating system (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.

What’s missing in security today is a way to accurately assess risk, prioritize the issues that truly
need to be fixed and minimize the noise, tickets and toil inflicted on the teams and individuals
responsible for fixing those issues.

To accomplish this, we need 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, security teams can rapidly prioritize security flaws according to
the actual business risk. This will significantly improve their security posture and dramatically reduce
the number of tickets, noise and toil from manual processes.
CrowdStrike White Paper 5
Application Security Posture Management:
Securing Cloud-Native Applications at Scale

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
material impact to 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 one or more of these three key
attributes:

1. A threat with high severity (e.g., vulnerability, architecture flaw)

2. A threat attack surface with a high probability of exploit (e.g., internet-facing)

3. A threat that poses material business impact (e.g., personally identifiable information
exposure)

Threats shouldn’t be exclusively tied to security or adversaries. Threats also cover availability and
resilience — that is, an application’s ability to tolerate and recover from failure. For example, when
an application is unable to overcome a denial-of-service attack, the true risk is the lack of resilience
within the application's architecture.

Application security posture management (ASPM) is a new category of security intended to help
organizations 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:

1. What are the top business-critical risks in production right now?

2. How many microservices and APIs could be exploited in production?

3. What sensitive data is exposed by applications in production?

CrowdStrike White Paper 6
Application Security Posture Management:
Securing Cloud-Native Applications at Scale

The Current Cloud Security Landscape

Despite rapid growth and significant investment, cybersecurity is still a moving target as new
technologies, threats and attack surfaces emerge. This is especially true for cloud security. Here’s a
brief overview of how organizations are securing their cloud environments and resources today.

Securing Cloud Infrastructure, Containers and Workloads: Cloud-Native

Application Protection Platforms (CNAPPs)
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 configurations (CSPM) by interrogating cloud provider APIs and
analyzing the accounts and permissions (CIEM) of cloud services. Many vendors have extended
this visibility into virtual machine (VM) and container orchestration services (CWPP) like Kubernetes
and Amazon 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 that most CNAPPs offer:

Cloud Providers
Networks, Regions, Zones, IAM

Cloud Services
Servers, Config., OS,Processes, Storage

Cloud Workloads
Kubernetes, Containers, VMs

Application
Runtime, Config., Env. Variables

Services
Configuration Variables

Data Sources Frameworks

Binaries Data Third

PII, PHI, PCI Parties

Libraries APIs
Dependencies

Figure 1. ASPM extends visibility to the application, services and data layers
CrowdStrike White Paper 7
Application Security Posture Management:
Securing Cloud-Native Applications at Scale

Furthermore, 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 generally don’t provide visibility into how data flows through
applications and therefore can’t detect threats to sensitive data. The absence of data flow visibility
within and amongst applications makes it impossible for CNAPPs to understand an organization’s
compliance with data privacy regulations like the GDPR and CCPA.

Resilience: CNAPPs can provide system maps relating to the communication of cloud infrastructure,
network and workload/container dependencies. However, they are typically unable to map a true
application architecture end to end in terms of its microservices, functions, APIs, data flows and
third-party dependencies. As a result, it’s nearly impossible to find single points of failure for business
applications.

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.

Securing Cloud-Native Applications

One area of security that remains a significant blind spot is how continuous application code and
configuration changes developed and delivered via CI/CD affect the security posture of applications
running in production. There is an entirely unseen and unmanaged attack surface of application
microservices, functions, APIs, dependencies and sensitive data flowing throughout.

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

“Shift Left”
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 integrated
development environments (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.
CrowdStrike White Paper 8
Application Security Posture Management:
Securing Cloud-Native Applications at Scale

Application Security Testing

Application security testing tools — specifically SAST, SCA, DAST and IAST — test and evaluate
application code for vulnerabilities in pre-production environments. Here’s a brief rundown of SCA
and the *AST tools:

Static Application Security Testing (SAST) is a way to find security issues very early in the software
development life cycle — 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
Common Vulnerabilities and Exposures (CVEs).

Though 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:

• False positives and negatives: Some rules incorporated into SAST can produce ambiguous
results, which can generate false positives or worse: false negatives. Resolving the
abundance of issues from false positives falls on the human analysts, which leads nicely to
our next point.

• Inefficiency: The noise from false positive/false negative alerts and the human analysis
required to resolve them slows down development without guaranteeing a more secure
application in production. Plus, the testing itself can be slow. Depending on the vendor and
the size of the application, a scan can take anywhere from a few seconds to several hours.

Software Composition Analysis (SCA) inventories an application’s open-source code and supporting
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,3
approximately 70-90% of any given application is open source.

Though 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 and
loaded into memory.

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

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

Interactive Application Security Testing (IAST) is an evolution of SAST and DAST that combines both
static and dynamic testing functionalities. Some IAST tools integrate with IDEs to provide immediate
feedback to developers. IAST is powerful because it links discovered vulnerabilities with actual code
locations, which can help lead 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 that limit their scope, deployment
and value across complex hybrid cloud applications.

3
The Linux Foundation, A Summary of Census II: Open Source Software Application Libraries the World Depends On
CrowdStrike White Paper 9
Application Security Posture Management:
Securing Cloud-Native Applications at Scale

SAST SCA DAST IAST

Analyzes
Tests running Tests running
What Tests source code open-source
application in QA application in QA
software libraries

When/ Development (IDE Development

QA QA
Where or code repository) (code repository)

Helps penetration
Helps developers Reduces Specifies location
testers find holes
Benefits commit and fix open-source of vulnerabilities
in a running
secure code early vulnerabilities in code
application

False positives and

negatives, which Limited Agent-based
Limited test
Limitations create scope — doesn’t and difficult to
coverage
inefficiency cover custom code maintain

Table 1. Summary of pre-production application security testing and analysis tools

CrowdStrike White Paper 10
Application Security Posture Management:
Securing Cloud-Native Applications at Scale

“Extend Right” — Application Runtime and 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.

RASP is an agent-based solution capable of controlling application runtime 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 affect system performance and reliability due to its overall
deployment complexity.

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 can only detect attack surfaces
that are exploited by adversaries (at runtime) versus the full landscape of what’s exploitable. For
example, if a microservice exposes three APIs but only one of those APIs is invoked, then these
solutions wouldn’t know about the other two APIs because no events or telemetry would exist.

RASP WAAP

Security that's built into the A collection of cloud-deployed

What application runtime or operating cybersecurity implementations
system protecting APIs and web apps

When/Where Runtime/production Runtime/production

Can help protect against bots,

Offers automated protection in
Benefits distributed denial-of-service (DDoS)
the event of an attack
attacks and application vulnerabilities

Limited to the context of

the application framework; Requires extensive administration time
Limitations doesn’t account for application and expertise (managing thousands of
interactions with other services rules and parameters)
and components

Table 2. Overview of runtime protection tools

CrowdStrike White Paper 11
Application Security Posture Management:
Securing Cloud-Native Applications at Scale

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 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:

1. What are the top business-critical risks in production right now?

2. How many microservices and APIs could be exploited in production?

3. What sensitive data is exposed by applications in production?

CrowdStrike White Paper 12
Application Security Posture Management:
Securing Cloud-Native Applications at Scale

What Is ASPM?
ASPM is the practice of making applications secure and resilient to significantly reduce business
risk.

The goal of ASPM is to have a continuous and comprehensive understanding of a deployed

application’s state of security and resilience. ASPM is unique because it focuses on applications
running in production and it layers in business context and relevant security information from a
range of cloud and application security offerings.

ASPM provides clear visibility into even the most complex applications. This allows 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.

In May 2023, Gartner formally announced ASPM as a category4 due to the growing and urgent need
to fill this gap in coverage and address risk in a meaningful way. The questions that ASPM seeks to
answer include:

1. What are the top business-critical risks in production right now?

2. How many microservices and APIs could be exploited in production?

3. What sensitive data is exposed by applications in production?

4. What are the single points of failure in my application?

Where Does ASPM Fit Into Your Cybersecurity Strategy?

ASPM focuses on securing 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
CNAPPs provide.

ASPM contextualizes threats identified with existing security tools so teams can rapidly understand
the business risk behind each threat (exploitability and material business impact).
Dev and QA Production

✓ Application Attack Surface

SCA
Application ✓ Application Drift
SAST ASPM
✓ Application Risk
DAST
✓ Data Privacy Risk

Containers
Infrastructure and IaC CSPM
Scanning

← Testing → ← Posture →
Figure 2. ASPM in the cybersecurity landscape

4
Gartner, Invest Implications: Innovation Insight for Application Security Posture Management
CrowdStrike White Paper 13
Application Security Posture Management:
Securing Cloud-Native Applications at Scale

Core Business Benefits of ASPM

The main benefits of ASPM are:

1. Full visibility of applications running in production

2. Complete and up-to-date inventory

3. Risk-based vulnerability triage and prioritization

4. Application misconfiguration management

5. Better application data privacy and compliance

6. Greater application resilience

Core Benefit 1: Application Visibility

What you cannot see, you cannot secure. ASPM brings complete visibility to applications in
production. Ideally, an ASPM solution should not rely on traffic or actual use to identify all of the
microservices, databases, APIs, third-party connections, etc. This is the key differentiator between
ASPM and legacy application performance monitoring or observability.

This visibility is valuable to many different teams — including security, DevOps, engineering, site
reliability engineering and enterprise architects — because it provides a single source of truth for
cloud-native applications.

Core Benefit 2: Application Inventory

The complete visibility that ASPM provides gives way to another key benefit: an accurate, up-to-
date application inventory. Having a software bill of materials (SBOM) is essential for software
supply chain security and for organizations doing business with the U.S. government. SBOM-related
regulations will likely become more stringent and have wider applicability.

Fortunately, ASPM provides a trusted system of record for all services, dependencies, libraries and
configuration files in deployed applications. Even as developers push changes to production daily or
hourly, those changes should be captured and available in an ASPM solution.

Core Benefit 3: Application Vulnerability Triage and Prioritization

ASPM helps organizations triage and prioritize application vulnerabilities based on risk. ASPM should
correlate how threats from late-breaking vulnerabilities, changes to third-party dependencies,
excessive privileges and hard-coded secrets affect the application.

More importantly, ASPM takes a different approach to scoring risk. To calculate business risk, an
ASPM solution should encompass:

1. The severity of a threat or vulnerability

2. The probability that an attack surface could be exploited

3. The criticality and sensitivity of data that could exposed

CrowdStrike White Paper 14
Application Security Posture Management:
Securing Cloud-Native Applications at Scale

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 that has no dependencies and
is hosted inside a private data center, then the risk of this vulnerability 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.

Let’s compare this to a vulnerability with a CVSS score of 8.1. Despite having a lower score, the
context of where the vulnerability is in the application makes it a critical business risk. In this second
example, the vulnerability is available via the public internet and connected to sensitive data, making
it an exploitable threat and active risk.

CVSS 9.9 CVSS 8.1

Private data center: Public internet access:

non-sensitive data sensitive data

RISK: MODERATE RISK: EXTREMELY HIGH

Fix immediately

Figure 3. Prioritization based on vulnerability score vs. ASPM risk assessment

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 three business-critical risks in production at any given time.

ASPM should not treat vulnerabilities equally under unequal conditions. It should provide context
about where the vulnerability is along with high-quality, actionable feedback for remediation.
Security teams should end up with less noise and fewer false positives so they can work with
engineers to fix the riskiest vulnerabilities quickly without bottlenecking continuous delivery.
CrowdStrike White Paper 15
Application Security Posture Management:
Securing Cloud-Native Applications at Scale

Example: Zero-Day Code Vulnerability Investigation

Challenge: A human resource and payroll software company detected the Log4j vulnerability in their
build and test environments, but they were unable to locate the instances of Log4j in production.
Because none of their cybersecurity tools provided this level of visibility in production, the security
team had to conduct a vulnerability investigation that involved 50 full-time equivalents (FTEs) over
the course of three days.

Business Impact: In the end, the company estimated that this three-day manual review cost them
over $150,000 to resolve a single incident.

Solution: Using ASPM, the company was able to find, contextualize and prioritize the business
risks in their production environment that stemmed from the Log4j vulnerability. Within minutes,
the company had a detailed architectural map of its applications in production along with each
component, service and data flow that was at risk of exploitation ranked in order of severity.

Core Benefit 4: Application Misconfiguration Management

Application misconfigurations are configurations — either in the code or in the environment —

that create risk. Specific examples of application misconfigurations include improper secrets
management — such as hard-coded or un-rotated secrets — and insecure environment variables.

Though some tools can detect partial application misconfigurations (for example, SAST can find a
hard-coded password in non-executed code), only ASPM can detect application misconfigurations
living in production. Furthermore, ASPM leverages its understanding of application architecture to
determine the business impact of misconfigurations.

Example: Detecting Cross-Environment Dependencies

Challenge: A growing financial services company sought to better understand its application
architecture as part of an effort to reduce the lead time for application updates. Because the
development team had no accurate diagram of the application’s architecture, each update had to
undergo time-consuming manual dependency analyses and security reviews.

Business Impact: Storing millions of customer records in a development database is a massive GDPR
violation that could cost the company millions in fines and fees. Conversely, slowing development
and innovation in a highly competitive industry could halt the company’s growth.

Solution: ASPM quickly identified an active/deployed microservice with a dependency in

the development environment. By proactively identifying this instance of cross-environment
communication, the company was able to remove the dependency and eliminate potential issues
associated with it.
CrowdStrike White Paper 16
Application Security Posture Management:
Securing Cloud-Native Applications at Scale

Core Benefit 5: Application Data Privacy and Compliance

Continuous updates to cloud-native services and microservices affect the flow of data, making
it time-consuming and difficult to understand which applications are connected to sensitive data
and what impact that data exposure creates. According to GitLab’s 2022 Developer Survey,5
most operations professionals spend between one-quarter and half of their time on auditing and
compliance.

ASPM eases data privacy and compliance tasks, which are often time-consuming and manual.
Through automated discovery and mapping, ASPM proves regulatory compliance in minutes by
providing 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.

Example: GDPR Compliance

Challenge: An American restaurant chain was opening its first locations in the EU and needed to
comply with the GDPR. The company set up a host for its new EU microservices within a Microsoft
Azure region in the EU. It was struggling to gain full visibility of where customer data was being
stored and processed to ensure full compliance with the GDPR data sovereignty provision, which
requires all data collected from EU citizens to be stored in the EU or a jurisdiction that has similar
levels of protection.

Business Impact: GDPR fines can break a business. Depending on the violation’s severity, fines can
be up to €20 million or 4% of the company’s worldwide turnover from the previous year, whichever is
higher.6

Solution: With ASPM, the company mapped the data flow of each microservice in production and
found that data from an EU microservice was being stored outside the EU, thus violating the data
sovereignty provision of the GDPR. By proactively finding and fixing GDPR and other data privacy
violations, organizations can avoid costly fines, legal action and burdensome noncompliance
follow-up.

Core Benefit 6: Application Resilience

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 2016, Ponemon Institute found that the average cost of downtime
was $9,000 per minute.7 Even if this estimate is conservative in current economic conditions, a three-
hour outage would cost over $1.6 million.

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

• Developers understand their application architecture. Many developers delay or neglect

making critical documentation updates, which adds to perceived technical debt and hinders
decision-making.

5
GitLab, The GitLab 2022 Global DevSecOps Survey
6
GDPR Fines
7
Ponemon Institute, Cost of Data Center Outages
CrowdStrike White Paper 17
Application Security Posture Management:
Securing Cloud-Native Applications at Scale

• Enterprise architects reduce/limit actual technical debt. They will be able to lead
their organization to create and maintain secure, scalable and flexible application
architecture.

• Site reliability engineers (SREs) restore service quickly in the event of unplanned
downtime. They will be able to pinpoint the root cause; identify the extent to which
an issue affects other components, data flows and applications in production; and
remediate the issue to limit the amount of downtime.

• 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.

Example: Eliminating Downtime for a Financial Services Company

Challenge: A large financial services company experienced a cloud region failure. Adding to
the chaos, the company had no accurate system of record that identified which applications
and services were running in each cloud provider, region, and zone and no visibility into cross-
application and cloud dependencies. The company needed to prevent this from happening
again by having full, accurate and immediate visibility into its application architecture.

Business Impact: The total downtime for this incident cost the company over $10 million.

Solution: By adding ASPM to its security strategy, the company has been able to proactively
explore and understand the impact analysis of application dependencies across multiple
cloud service providers, regions and zones. This level of visibility helps make its cloud
application architectures more resilient by detecting single points of failure or lack of failover
in application services. It has also provided the company with the assurance that it will be well
equipped to minimize the impact of any future unplanned downtime, should it occur.

Key Characteristics of ASPM

Now that we’ve covered the benefits of ASPM, let’s look at some common characteristics to
look for in an ASPM solution. ASPM tools must be:

• Up-to-date

• Contextual

• Data-aware

• Drift-aware

• Risk-based

• Able to unify threat ingestion

• Policy-driven

• Able to integrate into workflows automatically

• Easy to deploy and scale

CrowdStrike White Paper 18
Application Security Posture Management:
Securing Cloud-Native Applications at Scale

Up-to-Date

Once an application is discovered and mapped, its architecture dependencies (services,

APIs, data flows, third-party services, libraries) are indexed, baselined and cataloged for risk
analysis, security posture insights and reporting.

A searchable and continuously updated application inventory allows teams to:

• Create an SBOM for any application or service on demand

• Report which applications or services contain a specific dependency (e.g., libraries

containing Log4j)

• Report the exact number of specific application attack surfaces that exist (e.g., how
many internet-facing APIs are in production)

• Report how many services touch sensitive data and communicate with third-party
services

Contextual

To help teams rapidly prioritize risk, ASPM must provide context and metadata of how
application, services, APIs and their dependencies impact the business. For example,
developers often use clear naming conventions for services and APIs that perform or expose 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 metadata (e.g., tagging) and context from cloud infrastructure, OS, network and
containers is not enough given that cloud resources are dynamic and ephemeral. Maintaining
complete and clear context of business logic as it changes is fundamental.

Data-Aware

To augment business context, an ASPM solution needs to be data-aware so it 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, such as personally identifiable information (PII), payment card information
(PCI) and protected health information (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.
CrowdStrike White Paper 19
Application Security Posture Management:
Securing Cloud-Native Applications at Scale

Drift-Aware

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, so 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 U.S. database hosting PII data

• An application 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
runtime configuration within production.

Risk-Based

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:

1. Criticality of vulnerability or misconfiguration

2. Probability that a vulnerability or misconfiguration will be exploited to become an

active threat

3. Sensitivity of data that could be impacted or exposed

For example, if there is a critical vulnerability in a library, but that library is not loaded into
memory, there is no way to exploit this risk.

ASPM should not amplify hundreds or thousands of risks like existing security tools. It should
provide high-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 Ingestion

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.
CrowdStrike White Paper 20
Application Security Posture Management:
Securing Cloud-Native Applications at Scale

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.

Policy-Driven

An ASPM solution should provide the ability for teams to define, apply and govern one or more
risk policies to applications based on industry standards, regulatory frameworks or custom
requirements.

Different applications are subject to different security standards, industry regulations and
compliance audits. It is therefore important to measure and govern an application security
posture from different perspectives depending on the use case.

For example, the GDPR has different requirements than NIST or PCI DSS. If an application is
subject to all three, then the security posture needs to be seen through the eyes of all three
policies.

ASPM policies should be extensible, version-controlled and — ideally — managed as code

to promote reuse and scalability across hundreds or thousands of applications across an
enterprise.

Automated Workflow Integration

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 must enable DevSecOps automation in the following areas:

1. Cloud Service Providers and Container Orchestrators (Kubernetes, AWS, GCP,

Azure): Integrate seamlessly and scalably across all cloud-native applications

2. CI/CD Pipelines (Jenkins, GitLab, Azure DevOps, Harness): Seamlessly integrate with
CI/CD pipelines so security postures are created for pre-production and production

3. Issue Tracking (Jira, GitLab, ServiceNow): Automate feedback loops to engineering

teams

4. Configuration Management Database (CMDB) and Service Catalog/Inventory

(ServiceNow): Continuously update all application assets and configuration items s
that belong to each cloud-native application

5. Cloud Security/CNAPP (CrowdStrike Falcon® Cloud Security, Wiz, Palo Alto Prisma):
Unify, contextualize and score security findings from all existing security tools through
the eyes of an application

6. Application Security (Sonatype, Synopsys, Checkmarx, Snyk): Consolidate and

correlate findings from pre-production application security solutions
CrowdStrike White Paper 21
Application Security Posture Management:
Securing Cloud-Native Applications at Scale

ASPM also automates manual processes such as security reviews and threat modeling, which
are notoriously time-consuming and monotonous. These activities currently require accurate
documentation, architecture diagrams, Jira tickets and completed questionnaires, which
bottleneck the software development life cycle.

Easy to Deploy and Scale

If ASPM cannot be deployed and scaled easily across your organization, then its adoption and
value will fail.

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

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. The aim of ASPM is to
automate manual processes, not to burden existing ones.
CrowdStrike White Paper 22
Application Security Posture Management:
Securing Cloud-Native Applications at Scale

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/platform team. In other organizations, the owner may be on
application or product security teams, depending on their scope and responsibilities.

Recommended Owner: DevOps/DevSecOps, security engineering, security architecture or

cloud/platform teams

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 the 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 on what you
are trying to achieve.

Example Objectives:

• Improve application security posture

• Automate security architecture reviews

• Discover and inventory all application microservices and APIs

• Identify and govern all third-party service dependencies

• Identify all sensitive data that could be exploited

CrowdStrike White Paper 23
Application Security Posture Management:
Securing Cloud-Native Applications at Scale

Example Goals:

• Auto-discover, map and inventory all 132 cloud applications in AWS

• 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 hard-coded secrets by 75% in five mission-critical production applications

Integrate and Incubate ASPM

The first barrier is integrating ASPM into your existing ecosystem of 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 environments. 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.
The purpose of this phase is to 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 applications teams can onboard themselves by
simply following the ASPM playbook you created in phases 1 and 2.

Figure 4. How to operationalize ASPM

CrowdStrike White Paper 24
Application Security Posture Management:
Securing Cloud-Native Applications at Scale

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. Though 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, you could align the targets to research
findings from Google’s 2021 State of DevOps report.8

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 time frames for business-critical risk resolution:

• Elite: Less than one hour

• High: Less than one day

• Medium: Between one day and one week

• Low: More than six months

In addition to the key performance indicators (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?

8
Google Cloud, State of DevOps 2021, p. 9
CrowdStrike White Paper 25
Application Security Posture Management:
Securing Cloud-Native Applications at Scale

Conclusion
ASPM is an innovative way to identify and manage risk. It augments and integrates with
your existing tool ecosystem so you can contextualize the true impact of vulnerabilities,
misconfigurations and attack surfaces that impact your applications, end users and
shareholders.

ASPM will enable you to answer those three difficult questions continuously with confidence:

1. What are the top business-critical risks in production right now?

2. How many microservices and APIs could be exploited in production?

3. What sensitive data is exposed by applications in production?

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

Metric Life Before ASPM Life with ASPM

Number of security Hundreds or even thousands of risks detected

per week using multiple tools, with a high Focused on only the most critical business risks
risks likelihood of duplication, irrelevancy, etc.

Proportion of
business-critical risks
More risks per deployment Fewer risks per deployment
to the number of
deployments

Average time to fix Long lead times and difficulty locating issues Less time to fix business-critical risks due to
critical business risks and finding appropriate owner better context, risk prioritization and ownership

Application security
Worsens or stagnates over time Strengthens over time
risk posture over time

A defined owner with clear responsibilities

Lack of clear security ownership and
Roles and focused primarily on understanding application
responsibilities spread across multiple teams
security risk posture, fixing the top 2-3 risks per
responsibilities and roles, which slows the process of finding
week and tracking/reporting progress to other
and fixing issues and creates friction
stakeholders

Resilience and Higher technical debt and lower confidence in Lower technical debt and higher confidence in
confidence resilience resilience

Clear and code-accurate application

Reliant on manual processes that are often
Processes architecture, SBOMs and security reviews/
delayed, neglected and prone to human error
checklists optimized with automation

Table 3. Application security excellence through ASPM

Ready to explore ASPM? CrowdStrike Falcon® is now the only platform that offers ASPM.

See it in action
CrowdStrike White Paper 26
Application Security Posture Management:
Securing Cloud-Native Applications at Scale

Glossary of Key Terms

Here are a few key terms and definitions used throughout this resource.

Vulnerability

Weakness in an information system, system security procedures, internal controls or implementation

that could be exploited or triggered by a threat source.9

CVEs

Common Vulnerabilities and Exposures (CVEs) are known weaknesses or software flaws that meet
specific criteria. CVEs are reported, investigated and published/tracked in a centralized database.

(Cyber) Threat

Any circumstance or event with the potential to adversely impact organizational operations (including
mission, functions, image or reputation), organizational assets or individuals through an information
system via unauthorized access, destruction, disclosure, modification of information and/or denial of
service. Also, the potential for a threat source to successfully exploit a particular information system
vulnerability.10

In plain language:

If a vulnerability is exploitable, then it is a threat. CVEs are recognized (common) vulnerabilities, but
there are other sources of weakness. In the realm of cloud and application security, weakness takes
the form of misconfigurations, improper access or anything that has the potential to create risk to the
business if exploited.

There is no such thing as a vulnerability-free application. There is no such thing as a weakness-

free application. The challenge is understanding which weaknesses are exploitable, prioritizing the
weaknesses based on risk and remediating those weaknesses quickly and without friction between
security, development and operations teams.

Application

Software designed to accomplish a set of tasks or fulfill a set of requirements. Many modern, cloud-
native applications are made up of many different services (also called microservices) that, together,
fulfill the complete set of requirements or tasks.

Service (Microservice)

Application services, or microservices, are small independent services in an application that

communicate over well-defined APIs. Microservices architectures make applications easier to scale
and faster to develop, enabling innovation and accelerating time to market for new features.11

9
https://csrc.nist.gov/glossary/term/vulnerability
10
https://csrc.nist.gov/glossary/term/cyber_threat
11
https://aws.amazon.com/microservices/
CrowdStrike White Paper 27
Application Security Posture Management:
Securing Cloud-Native Applications at Scale

API

An application programming interface (API) enables software programs, services and external/third-
party programs to communicate with each other using a set of definitions and protocols. APIs enable
the connections in microservice application architectures.

Application Data Flow

The path through which data flows in an application.

In plain language:

Modern applications are made up of (micro)services that use APIs to deliver instructions that dictate
the behavior of those services, including how data flows through the application.

About CrowdStrike
CrowdStrike (Nasdaq: CRWD), a global cybersecurity leader, has redefined modern
security with the world’s most advanced cloud-native platform for protecting critical
areas of enterprise risk — endpoints and cloud workloads, identity and data.

Powered by the CrowdStrike Security Cloud and world-class AI, the CrowdStrike
Falcon® platform leverages real-time indicators of attack, threat intelligence,
evolving adversary tradecraft and enriched telemetry from across the enterprise
to deliver hyper-accurate detections, automated protection and remediation, elite
threat hunting and prioritized observability of vulnerabilities.

Purpose-built in the cloud with a single lightweight-agent architecture, the

Falcon platform delivers rapid and scalable deployment, superior protection and
performance, reduced complexity and immediate time-to-value.

CrowdStrike: We stop breaches.

Learn more: https://www.crowdstrike.com/

Follow us: Blog | X | LinkedIn | Facebook | Instagram

Start a free trial today: https://www.crowdstrike.com/free-trial-guide/

© 2024 CrowdStrike, Inc. All rights reserved.