The CISO’s View of Securing Application Data in the Cloud


What Is Application Data Security?

Application data security is an application-centric approach to data privacy and protection. The goal is to secure and protect sensitive data as it flows through application services and APIs.

Why Does Application Data Security Matter?

Every company is responsible for securing sensitive data of some kind, whether it’s generic personally identifiable information (PII) protected health information (PHI), or information about financial transactions that is subject to the payment card industry data security standard (PCI-DSS).

For companies that build modern cloud-native applications, application data security should be a top priority. Protecting sensitive data isn’t just about complying with GDPR or CPRA to avoid massive fines, it’s about building and maintaining customer trust and growing the business, as it evolves digitally.

Big Breaches
The average cost of data breach in 2022 was $4.35 M. Here’s a reminder of some bigger breaches in recent history.

〉T-Mobile: $500 M ; 37 M customer accounts
〉Marriott: $23.8 M; 383 M records
〉Facebook: $277 M; 500 M customer account


Why Is Application Data Security So Difficult?

TL;DR: It’s difficult because:

1. Until recently, security posture management has focused only on cloud infrastructure and storage.
2. Application security testing (AST) tools lack data context.
3. Applications and APIs are highly dynamic, distributed, and ephemeral.
4. Application and API access permissions are often overlooked.
5. DevOps + CI/CD = frequent application, code, and API changes.

Many organizations first started managing their security posture from the cloud perspective (e.g. secure S3 Buckets). Some have opted to use a data-centric approach (e.g. secure relational databases). But until recently, the application-centric approach wasn’t possible. 

Running parallel to posture management are AST tools that test throughout parts of the SDLC, with most focusing on pre-production, specifically code repositories. There is no single tool that applies to the entire application lifecycle. This gap prevents organizations from understanding their application data security posture in production. This gap is critically important to fill because sensitive data lives in production, not in development or QA environments.

Further complicating matters is the way in which cloud-native applications are built. Complex, distributed microservice architectures with many dependencies have replaced monolithic applications with fewer dependencies. Similarly, security is challenged to understand all the ways that modern applications interact with sensitive data. APIs, upstream and downstream dependencies, third parties, shared databases/caches, and anything that consumes data in an application influences data security and determines exploitability.

Securing databases and managing access to systems are foundational cybersecurity practices, but restricting application and API permissions are sometimes overlooked or not fully understood. When developers are granted read-write access so their microservices can interact with databases programmatically, a single unvetted code change has the potential to expose an entire database of sensitive information. 

Plus, as DevOps teams introduce application changes weekly, daily, or hourly through CI/CD pipelines, it becomes harder to reconcile one’s data security perceptions with reality.

This guide defines three maturity levels and perspectives for data security: 

1. Cloud-centric
2. Data-centric
3. Application-centric

For each level, we’ll identify key challenges and common characteristics in terms of people, processes, and tools.


Level 1: Cloud-Centric

The first maturity level takes a cloud-centric perspective. It is about securing the foundation on which applications and data run. Organizations at this level understand the cloud shared responsibility model and are committed to fulfilling their part. Discovering and securing cloud infrastructure and storage from misconfiguration is the first step in managing application data security risk.


Leadership and the C-suite broadly support growing the application data security program, but there’s a lack of defined ownership. 

The key players at this level are often cloud security teams or cloud center of excellence (CoE) teams.


Cloud security is responsible for creating guardrails that help cloud engineering or DevOps teams provision cloud infrastructure and resources securely so they can innovate quickly without creating risk. Engineering teams are responsible for innovating within those defined security guardrails.


Cloud Security Posture Management (CSPM) tools are purpose-built to help teams deploy cloud infrastructure securely. CSPM applies common frameworks, regulatory requirements, and custom policies to identify and help remediate cloud misconfigurations.


While CSPM is a critical part of security, it is unable to provide visibility into the application, service, or data layers. CSPM can’t identify how data runs through applications or how sensitive data is being used in applications. 

As such, teams fill this gap in different ways, usually a mix of manual tasks and application security tools. Manual tasks include creating Visio diagrams, managing CMDBs, and updating spreadsheets to document application architecture and map data flows. AST tools include SAST, SCA, DAST, IAST, and RASP. By combining signals from SAST, SCA, DAST, IAST, and RASP, teams can claim to have security through the full application lifecycle. But in reality, no single solution alone can secure applications in production.

Key Takeaways

Here are the key takeaways for the cloud-centric level:

  • Generic buy-in, unclear ownership.
  • Security provides guardrails to help developers provision cloud infrastructure and services securely.
  • Securing application, service, and data layers requires manual effort and/or a combination of various other tools.


Level 2: Data-Centric

This level takes a data-first approach with a specific focus on securing where data is stored and managed. For example, AWS S3 buckets or relational/non-relational databases like Oracle, MongoDB, and DynamoDB.


Application data security ownership is shared across data privacy, data security teams, and even database administrators.

Responsibility is siloed like cloud security, with a specific perspective on where data is hosted and managed versus what is consuming or requesting the data.


After securing cloud infrastructure with CSPM, organizations focus on finding the data resources (etc., storage services, relational databases, NoSQL) they need to secure, identifying who should have access to what data, managing access requests/permissions processes, and specifying legitimate business needs to access sensitive data.

There are usually policies in place to meet the data protection regulations they need to comply with, i.e., GDPR, CCPA, HIPAA, etc. Accordingly, training and awareness programs at this level focus on compliance.


Data security posture management (DSPM) provides visibility as to where sensitive data is, who has access to that data, how that data has been used and what the security posture of the data store. With a data-centric solution, teams will be able to perform data risk assessments and evaluate alignment to data governance policies.

In its 2022 Hype Cycle for Data Security, Gartner points out that DSPM is nascent and products have a wide range of abilities for mapping user access and privileges and to identify, discover, and track data and identify associated risks. 

Furthermore, DSPM integrations with other security tools are limited. This makes it difficult for teams to contextualize DSPM signals from the application perspective, which inhibits remediation. 

Laminar DSPM
Laminar DSPM

Key Takeaways

Here are the key takeaways for the data-centric level:

  • Semi-defined application data security ownership.
  • Able to comply with data protection regulations with manual processes.
  • Limited context of how applications and APIs interact with data.


Level 3: Application-Centric

The third level approaches data security from an application-centric perspective. This approach is based on the idea that having full visibility into how an application is architected, as well as its dependencies and data flows will empower teams to secure applications, APIs, and sensitive data at scale.

At this level, organizations proactively and continuously protect sensitive data in production. They seek to understand their application data security posture by asking questions like:

  • How does software delivery affect our application data security in production?
  • Which code changes expose sensitive data?
  • Which 3rd party services are requesting or consuming sensitive data?
  • Which application services and APIs are internet facing that expose sensitive data?
  • Which application services are in compliance with data privacy regulations like GDPR?


Application data security ownership is well defined. Security champions are embedded across the organization, particularly in product, engineering, and DevOps teams. These champions bring on-demand data security subject matter expertise to the individuals and teams building applications and fixing security bugs.


In addition to having embedded security champions in every department, application data security training programs are elevated and become central to the organization’s culture. Raising security issues is rewarded and acknowledged. DevOps and engineering teams are trained to understand application data security best practices.

Data protection compliance is systematic and requires much less manual effort, and technology supports this. 

Here’s why that matters:

A major retailer in the United States is focused on maintaining customer trust and confidence. They are particularly interested in securing payment data.

Their security team of 8 performs between 200 and 300 1-hour manual security reviews per month to support:

  • 1,500 developers working on
  • 1,300 application services across
  • 500 teams

Based on average salary costs, this company spends ~$1.6 million per month just to perform security reviews.


At this level, organizations have invested in Application Security Posture Management (ASPM). ASPM brings full visibility into an application’s architecture, identifies critical assets, and maps data flows. The output of ASPM is similar to security reviews and threat modeling exercises, but with much less time and manual effort. 

Bionic ASPM

ASPM takes its full visibility one step further by analyzing all environment variables and dependencies in production. This holistic approach gives organizations real-time context of what the application is doing in production and identifies the top critical risks to fix right away. ASPM helps organizations actively govern their applications and protect sensitive data by prioritizing the most critical threats in production.

Bionic Violations by Status, Severity, and Impact

Key Takeaways

Here are the key takeaways for the application-centric level::

  • Holistic and contextual approach. 
  • Application data security champions are embedded in every part of the organization.
  • Security is talked about openly. This blog post from Coinbase is a great example of what this looks like. 
  • Application security scales with deployment cadence (weekly, daily, hourly).
  • Threats that pose the greatest risk are visible, contextualized, and can be fixed in minutes.



Here’s a quick summary of all three perspectives.

Level 1: Cloud-CentricLevel 2: Data-CentricLevel 3: Application-Centric
ChallengeSecuring cloudSecuring dataSecuring application data

Ownership of application data isn’t well definedShared ownershipWell-defined ownership based on application or service
Cloud security/Cloud CoESiloed responsibility based on data sourceApplication data security expertise embedded across organization

Focus on developing guardrails and templates for secure cloud deploymentsFocus on finding sensitive data, tagging it, and understanding accessFocus on automation to eliminate manual processes
Manual processes to translate cloud and infrastructure security to the applications and data layers Continuous risk assessment based on application data flows, threat severity, and application exploitability

Ready to Learn More?

Shift Left, Measure Right: Calculating DevSecOps Success


Earlier and more frequent inclusion of security in the software development lifecycle and throughout the CI/CD pipeline, aka “shifting security left,” has become a widely accepted best practice for DevSecOps teams. With organizations spending millions on people, processes and tooling, how do we know if shifting left is delivering results?

If you measure success based on the number of security tests and tools in your CI/CD pipeline, the number of vulnerabilities you detect, or mean time to remediate, you’re missing the bigger picture. It’s not about the number of vulnerabilities you detect or how quickly you fix them. In the end, detecting and fixing is not equivalent to securing. Unless you fix the vulnerabilities and threats that are exploitable, your applications will remain insecure once deployed.

This guide highlights some ways to think about and measure the effectiveness of your DevSecOps process and security posture.

But First….DevOps and DevSecOps: What’s the Difference?

DevOps was the starting point for what is now DevSecOps. DevOps first focused on integrating teams, CI/CD tools, and processes to speed software development and delivery. DevSecOps emerged soon after when everyone realized that they needed to embed security into their CI/CD process.

DORA and More

Google’s DevOps research assessment (DORA) team tracks the following five metrics to determine DevOps success and maturity: deployment frequency, lead time for code changes, mean time to recovery, change failure rate, and reliability. Over time, DORA metrics offer insight into how mature DecOps organizations have become. But even DORA has no real metrics that measure the effectiveness of security within DevSecOps.

Step 1: Map Your Security Gates and Tools

Before you can measure the effectiveness of DevSecOps, you need to map out the security checkpoints that you’ve established in your CI/CD pipeline. With each stage, list the tools and processes that you use.

PlanCode BuildTestReleaseMeasure
Threat Modeling
Code Reviews
Unit Testing
Security Architecture Reviews

Step 2: Find the KPIs that Matter

The next step is to find the KPIs to measure the effectiveness of your tools and gates. Many industry leaders use DORA metrics, but there are still too many vulnerabilities to possibly fix, too many signals and alerts that lack business risk context, and too much toil.

Here are some KPIs that can give you a better understanding of your level of DevSecOps success. In this context, a critical risk is any threat that is exploitable and has access to sensitive data.

Critical Risk Volume# of critical risks detected in pre-productionTo understand the volume critical risks found in pre-prod. Requirement for Critical Risk Escape Rate KPI.
Critical Risk Remediation Queue # of critical risk ticketsTo understand the stress levels and workload placed on the developers that need to fix these issues.
Known Risk Acceptance # of known risks not remediated (accepted) and pushed to production with reasonTo understand how many risks you are accepting and why.Requirement for Known/Accepted Risk Severity Evolution KPI.
Critical Risk Volume # of critical risks detected in deployed appsTo compare to the volume of critical risks found in pre-prod.Requirement for Critical Risk Escape Rate KPI.
Critical Risk Escape RateRatio: # of critical risks found in pre-production to # found in productionTo assess effectiveness of pre-production security.
Critical Risks Per DeploymentAverage # of critical risks for each deploymentTo benchmark expected critical risks.
Mean Time Between Critical RisksAverage time between critical risk detectionTo understand how successful your team is at preventing or reducing future critical risks.
Known/Accepted Risk Severity Evolution# of issues pushed to production as an accepted risk that evolved into critical risksTo understand how real life production context changes risk severity.

The final metric, Attack Surface Coverage, is a maturity assessment rather than a KPI. Here are the three maturity levels of Attack Surface Coverage:

  • Level 1: 33% coverage (Infrastructure/cloud)
  • Level 2: 66% coverage (Infrastructure/cloud + network)
  • Level 3: 99% coverage (infrastructure/cloud + network + applications)

Step 3: Assess the Team Experience

DevSecOps is both a technical and cultural endeavor, so it’s important to take into account the sentiment of key stakeholders. You can gauge experience ratings in many different ways. Depending on the size and geographic distribution of your team, you might choose an informal Slack poll or a short survey. Whatever form your survey takes, here are some questions worth asking.

Developer Experience

  • Do you have the context and understanding needed to fix critical risks?
  • How much time do you spend on manual code reviews and security checklists?
  • What percentage of your time is spent on fixing security issues? Do you classify this as toil or meaningful work?
  • Do you have adequate time to innovate?

Security Experience

  • Do your tools provide clear and meaningful signals?
  • Do you understand how risk is prioritized in your organization?
  • How much time do you spend on manual code reviews and security checklists?
  • Do you have time to take on proactive security projects?

SRE/Operations Experience

  • How resilient are your applications? How many single points of failure are present?
  • How are you managing your application inventory and dependencies?
  • Do you have the necessary tools and processes to quickly pinpoint the root cause of an outage and restore service?

CISO Experience

  • How many application threats exist right now in production that are exploitable and connect to sensitive data?
  • Is the security posture of your applications in production getting better or worse?
  • Do you have the tools and data that you need to answer these questions?

DevSecOps shouldn’t just be measured on deployment frequency, agility, and speed. Rather, it should be about understanding what is making you more secure.To learn about how Bionic ASPM can provide vital data about your application security posture to help you measure DevSecOps excellence, book your demo today

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


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.


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.

Comparison of AST Technology

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

Compare RASP vs WAAP
Figure 2: Comparison of RASP and WAAP

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.


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:

CNAPP visibility breakdown

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

ASPM cybersecurity landscape
Figure 3: ASPM Cybersecurity Landscape

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.

Zero day vulnerability investigation example

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.

Customer example of GDOR compliance

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.

Customer example of impact analysis

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.

application data flow map
Figure 5: Application Data Flow Map

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.

drift prevention in action
Figure 6: Drift Prevention in Action

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.

Business Risk Scoring in Action
Figure 7: Business Risk Scoring in Action

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?

Operationalizing ASPM

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?


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.

ASPM Performance Breakdown

Ready to explore ASPM? See Bionic in action now.


Bionic ASPM [Datasheet]

Agentless. Automated. Continuous.

Bionic creates a complete application security posture of applications running in production that maps all services, APIs, dependencies, attack surfaces, and data flows into a real-time architecture map.

Bionic integrates with your SCA (e.g. Snyk) and CSPM tools (e.g. Wiz, Prisma, Lacework) to unify and contextualize all your security alerts.

Application & API Security

Discover, map, and catalog all your application and API dependencies so you detect every exploitable CVE, attack surface, and threat.

Data Privacy & Compliance

Discover, map, and secure all your PII, PCI, and PHI data flows within your applications for GDPR, CCPA, and PCI compliance.

Architecture Drift

Baseline and govern application architecture drift as developers continuously deploy using their CI/CD pipelines.

Bionic Overview

Integrates in Minutes

Bionic uses an agentless approach to integrate with your cloud providers, apps, and DevOps tools in minutes.

Architecture Maps & Data Flows

Bionic builds a complete real-time application architecture map of all application services, APIs, dependencies, and sensitive data flows.

Application Security Posture

Bionic applies risk scoring to every application architecture, attack surface, and exploitable vulnerability that exists in production.

Bionic also integrates with your SCA and CSPM tools to unify and contextualize your security risks with application context.

Automate DevSecOps Workflows

Bionic integrates with all CI/CD pipelines and DevOps tools like Azure DevOps, JIRA, and ServiceNow.