How to Measure DevSecOps Success with ASPM
By Jacob Garrison, Security Researcher at Bionic
DevSecOps teams are shifting left to create more secure applications. The benefits of this strategy have caught on, with industry experts estimating that 90 percent of organizations are in various stages of DevSecOps adoption. A problem remains: how do you measure the risk reduction from shifting left?
Earlier inclusion of security testing in the application development lifecycle is proven to help. IBM’s 2023 Cost of a Data Breach Report notes that using DevSecOps is the most important factor in reducing the cost of a data breach. Historically, however, it’s been difficult to measure the impact each security gate has on the total risk posture of the business.
Today’s applications are distributed and complex, spanning hundreds of services across hybrid cloud and third-party service providers. Testing branches of code in isolation is a great start, but only reveals a small percentage of an application’s attack surfaces or vulnerabilities. To see everything, it’s crucial to measure right by expanding visibility into production.
In this article, I’ll explain how Application Security Posture Management (ASPM) assesses the security of your applications post-deployment to validate the effectiveness of your shift left tools and DevSecOps strategy.
Deployed Code as the Foundation of Truth
Reliable data drives better decisions. ASPM allows teams to directly analyze deployed code to get an accurate and complete view of your applications in production. ASPM tools like Bionic are intrinsically agentless, and scan every line of code in a deployed application to find every service, API, dependency, and data flow. This differs from traditional solutions that observe network traffic to identify the components that are invoked with requests and transactions.
For every new change or CI/CD deployment, ASPM tools collect all related artifacts, packages, files, metadata, configurations, manifests, and environment variables. Because they use the actual deployed binaries and environmental configurations of production, you get full visibility and a code-accurate inventory. This will ultimately help you understand what your total attack surface entails, which typically differs from what your pre-production tools and analysis have detected.
Accurate Application Architecture Mapping
After collection, the artifacts and configuration data are reverse engineered to create a detailed visual representation of all application code dependencies and attack surfaces in production.
Sensitive Data Discovery Classification
Understanding where sensitive data lives in your applications is the first step to protecting it. ASPM tools infer sensitive data types such as PII, PCI and PHI using the SQL and NoSQL statements in your deployed code. For every deployment, ASPM detects changes to sensitive data access. When increased data exposure is detected, it also raises a violation, assesses the severity of that violation, and incorporates that information into the service’s overall risk score.
Business Risk-based Prioritization
Risk scoring improves your overall application security posture while reducing security alert fatigue from shift left tools. It does this by assessing the application services that, in the context of production, create the most business risk to the organization. ASPM assesses the severity of violations in a service, connectivity (i.e., internet facing or internal), and proximity to sensitive data when assigning a risk score. By surfacing the top risks, security and engineering teams remain focused on the handful of critical threats most dangerous for the business.
It’s Time to Validate, Right?
Even with earlier and more frequent pre-production testing, there’s still no guarantee that what was once secure will stay secure. That’s because shifting left is only part of a strong security strategy. It’s vital to measure the impact of pre-production security efforts by actively and continuously analyzing applications in production.