Reduce Critical Vulnerabilities by 95% with Application Context

How Do I Measure Right?

For years, software teams have been shifting left and implementing DevSecOps. How do they know it’s truly improving their risk posture?

There isn’t a single security professional that will state, “We’ve never been breached, which means we don’t have risks in production.” What makes measuring application risk complicated is, traditionally, exploits in production are unknown until a breach occurs.

This blog discusses the typical approaches to determining an application’s security posture, along with the advantages and shortcomings of each.

Why Measure Right

Today’s development teams use continuous delivery and create cloud-native apps. However, constant code changes create an ever-changing landscape of risk. 

Understanding the application security posture (also known as validate right or measure right) is a blindspot for many organizations – and that’s a problem.In fact, 83% of software teams store sensitive data in the cloud. Couple that with the fact that 45% of development teams knowingly push vulnerabilities to production, and it becomes crucial to understand how individual risks fit into the bigger picture.

Current Measure Right Strategies

Most engineering teams, including DevOps and SRE, dedicate their time to the success of deployed applications. So if organizations can effectively measure their software’s performance, why is it so difficult to measure the software security posture?

The common DevSecOps framework is to implement security tools in the CI/CD pipeline. But once those tools are implemented, their effectiveness generally measures pre-production. If you’re only measuring security before deployment, how can you be confident that your runtime is secure?

There are several common methods for analyzing the security of production. Let’s compare the strengths and weaknesses of these methods for measuring right.

Uncover Risks Through Bug Bounties

Bug Bounty programs are a way to purchase pentesting-as-a-service. Software companies pay a bug bounty when a white hat hacker discovers (and reports) an exploitable vulnerability.

These programs are a method to uncover common exploits in production. And, since many white hat hackers submit bug bounties as a stream of income, there’s a large audience skilled at finding the typical mistakes.

Unfortunately, many reported bounties are not actual risks. For example, 41% of Gitlab’s bug bounty submissions are false positives. And, since an employee must verify each bug submission, these bug bounty programs create a large volume of manual work.

Measuring right with bounty information requires data analysis on an incomplete data set. While the critical bug bounty metrics vary by organization, report volume, valid report volume, and report volume by severity are frequently analyzed. Also, since vulnerabilities are only reported upon discovery, it’s impossible to know the number of outstanding risks at any given time.

Ultimately, bug bounty programs should not be the sole method to determine your production security posture. These programs cannot deliver an architectural view of the production risks, and there’s no guarantee that white hat hackers will find the exploits before black hat hackers do.

Recording Events with SIEM

Security Information and Event Management (SIEM) tools log events as they occur across an organization. By tracking event trends, it’s possible to estimate an application’s production security posture.

The largest benefit of using SIEM to measure right is that most organizations already own the tooling. This means that teams can find additional value in the data they already have.

With that said, the data that’s useful for measuring right comes from attempts to exploit production. These attacks or events could be unintentional mistakes from internal employees or, more maliciously, from external bad actors. Performing data analysis on event logs can provide insights into where attacks originate. 

SIEM tools are effective for maintaining logs, prompting defensive responses, ensuring compliance, and performing post-mortems. Even with these clear benefits, from a measure right perspective, SIEM tools do not offer the proactive assistance or architectural security indicators that many organizations need.

Tracking Behavior with APM

Application Performance Monitoring (APM) tools measure software operation. They are incredibly useful for tracking user behavior and detecting performance bottlenecks; however, security is not their primary use case.

With an APM, the software architecture is visualized based on user actions. These tools analyze packets on the network, which allows them to generate an architectural diagram of the application’s usage.

An application security add-on is commonly available for purchase from APM vendors. Some of the events that can be automatically flagged include new endpoint access, OWASP top 10 style attacks, and abnormal traffic levels. 

Unfortunately, dangerous events must occur at least once before an APM can detect them. So, when security teams learn about a data exfiltration route, their data is already compromised.

Additionally, APMs are agent-based. So, from a measure-right lens, an organization must go through the process of installing agents on every single production service to ensure visibility. This administrative burden often results in partial coverage and an incomplete view of the security posture.

APM  (source –

Correlating Alerts with ASOC

Application Security Orchestration and Correlation (ASOC) tools emphasize critical risks in software. They ingest data from existing security tools and infer significance, which allows them to highlight important alerts.

It’s common for enterprises to run their full suite of Application Security Testing tools in their CI/CD pipeline. Generally, this means that ASOCs are bombarded with alerts that contain little-to-no business context. The lack of architectural understanding makes it difficult for ASOC tools to draw meaningful conclusions.

To validate your security posture with an ASOC, data must be ingested directly from production. This requires the deployment of agent-based tools which can have an adverse effect on application performance (e.g. IAST or RASP) to exercise the application at runtime.

Additionally, because ASOCs depend on the results of other scanners to generate insights, the calculated security posture will improve as you tune your other security tools. So, for example, reducing false positives from an IAST tool will result in a more accurate security posture from an ASOC.

Ultimately, when using an ASOC, having confidence in your other application security testing tools is a crucial prerequisite. And, since many security scanning tools run scans before deployment (SAST, SCA, etc.), the risks they surface are often inconsequential components of the deployed application.

Securing Production with ASPM

Application Security Posture Management (ASPM) tools provide complete visibility into the security posture of production software. They continuously analyze software architecture to understand the full potential of deployed code.

Overlaying threats (including vulnerabilities and misconfigurations) onto the software architecture allows ASPM tools to rank the most business-critical risks automatically. Exploitable code paths accessing sensitive information are highlighted, ensuring security teams are aware of all dangers in production. 

These tools analyze runtime code to build accurate visualizations of production; any and all execution paths appear in the generated diagrams. The architecture is re-analyzed with every code release. It’s important to note that because ASPM tools don’t look at network traffic, they provide defensive security rather than event response.

ASPM tools are purpose-built to “measure right.” They allow organizations to continuously measure their security posture and ensure they operate within the acceptable risk. With ASPM, security teams can be confident that they’re aware of the outstanding risks in production and are prioritizing the correct issues.

Measure Right ASPM

Many tools and processes are unable to proactively measure right. If you want complete visibility into your application security posture, set up a Bionic demo today.

Did you find this blog helpful or interesting?

Click the social media button of your choice to share the blog with you friends and colleagues.

See a Live Demo of the Bionic Platform