Contextual prioritization funnel: Narrow-in on real, business-critical app risks with Apiiro

For application security posture management (ASPM) platforms, prioritizing security findings is one of the most important value-adds. 

But prioritization is only as strong as its underlying context. 

We know…prioritization and context get thrown around A LOT. So what do they really mean?!

At Apiiro, when we say context, we’re talking about what we know about your application architecture based on deep code to runtime knowledge. We then leverage that context to prioritize security findings based on their…

1. Likelihood of manifesting as a real risk and
2. Potential business impact.

To do that, we start with a comprehensive and continuous code inventory, including data models, APIs, pipelines, security controls, code modules, developer behavior, etc., as well as their connections with one another, and their changes over time. That foundation allows us to contextualize potential risks (i.e. open source vulnerabilities, pipeline misconfigurations, risky material code changes, exposed secrets, etc.) and more accurately prioritize them. To make our prioritization even more multi-dimensional, we also layer in context from runtime connections (i.e., Kubernetes clusters) and third-party databases (i.e., EPSS).

The value? Helping AppSec teams save time triaging alerts and minimizing interruptions to developers.

To make it clear just how valuable that context is, we’re excited to unveil our new interactive contextual prioritization funnel. 

Although the underlying risk factors—garnered from our Deep Code Analysis (DCA), runtime context, and third-party database ingestion—are what set us apart and provide value to our customers, we hope that by visually surfacing and segmenting risk likelihood and impact factors, it’s even easier to cut through the noise and narrow in on real, business-critical risks. 

In this post, we’ll drill into different risk factors that Apiiro surfaces in our new contextual prioritization funnel. 

Risk factors derived from Deep Code Analysis (DCA)

Application development is incredibly complex, with virtually infinite combinations and permutations across languages, technologies, frameworks, data flows, configurations, etc. 

We make sense of that complexity with our patented DCA technology. It’s our crown jewel, enabling us to put security findings in the context of your actual application architecture and, ultimately, your business. It goes beyond simplistic vulnerability detection to analyze all application and supply chain components, monitor each and every commit and pull request for material (or significant) changes, and flag anomalous behavior. It also enables us to garner incredibly valuable insights that we leverage to calculate these risk factors: 

In applicative code and in active development

Apiiro takes into account whether or not findings are related to code in test files and documentation, which we term ‘in applicative code,’ as well as whether or not the risks are ‘in active development,’ meaning they’re in repositories that have had pull requests or commit activity in the last 90 days. These two factors help weed out vulnerabilities that are immaterial to your active, public-facing applications.

Used in code

These days, “reachability” has become the gold standard for prioritizing risks. Although reachability is defined differently by different vendors, the general idea is to go beyond detecting a vulnerability in an incorporated package to determine whether that package and its vulnerable function is actually being used. Most open source security tools do this through runtime analysis.

Our answer to reachability, which we call “used in code,” takes a fully code-based approach, determining whether packages are explicitly being imported in the code. With this approach, you can distinguish vulnerable or malicious packages—as detected by Apiiro’s native open source security capabilities or ingested SCA findings—that are actively being called versus those lingering in your project files without any impact on your application. Used in code helps minimize triage time and ensure you’re focusing your efforts on real risks.

High business impact

For every enterprise organization, some applications and repositories more of an outsized impact on the business than others. And, thus, any risks identified within those repositories and applications need to be addressed with far greater urgency. 

Through DCA, we detect sensitive data, business-critical components, and contribution activity to define how critical each application or repository is—from low to medium to high business impact. Apiiro then surfaces enriches risks with that insight so you can filter out and focus in on the ones that will have a greater impact on your business.

SAST findings with related APIs

Powered by DCA, Apiiro’s inventory includes an exhaustive map of APIs in code, their changes over time, and their associated risks. Apiiro leverages that rich underlying inventory to tie SAST findings to their related APIs and surface that connection as a risk factor. If a SAST finding, such as sensitive data exposure or SQL Injection, is related to an actual entry point, it’s much more likely to be a real risk.

Risk factors derived from runtime context

Although Apiiro’s foundation is in code, we also layer in runtime intelligence by connecting to Kubernetes clusters (i.e. GKE, EKS, or AKS) and even CSPM tools like Wiz. From these connections, we gather context from your runtime environment and map assets back to code, surfacing these risk factors that are crucial for prioritizing findings based on real risk:

Deployed and internet-facing

By mapping code modules to their runtime containers, Apiiro can determine if a risk is deployed and/or connected to the internet. Runtime context is an invaluable tool for prioritizing risk and can be leveraged not only to focus efforts on existing risks, but also to prevent new risks from being deployed.

Risk-specific risk factors

Finally, Apiiro layers in context from third-party databases and our own native verification methods on top of our Deep Code Analysis and runtime context to add these risk factors to our risk prioritization:

Open source risk factors: High EPSS, exploit POC, and known exploit

Apiiro leverages these open source security insights to help determine the likelihood of a particular risk being exploited:

• Known exploited: Includes only the risks associated with packages for which known exploited vulnerabilities have been detected according to CISA KEV. 
• High EPSS: Includes only the risks associated with packages that have vulnerabilities with a high likelihood of being exploited in the next 30 days according to the EPSS algorithm.
• POC exploit: Includes only the risks associated with packages that have vulnerabilities for which there are proof-of-concept exploits in the wild.

Exploit intel is crucial—along with other likelihood and risk factors—to focus your remediation efforts.

Secrets risk factors: Valid, in a public repo, and production secrets

In addition to enriching secrets—ingested by third-party tools or natively detected by Apiiro—with valuable insights such as the type of secret it is and whether or not it’s exposed, Apiiro goes a step further to help cut through the noise with these risk factors:

• Valid: Includes only the risks for secrets that were verified as usable by an attacker. Apiiro also monitors for when a secret has been revoked so you can track changes made to secrets over time for more streamlined secrets management.
• Public repository: Includes only the risks associated with repositories that are exposed to the general public—thus needing immediate action. Apiiro analyzes and inventories all your source control management (SCM) repositories and their insights, including status, contribution activity, connections, and more.
• Production secrets: Includes only the risks associated with secrets that belong to a cloud, payment, or monitoring tool. These types of secrets tend to have a higher impact if exploited and should be prioritized accordingly. 

These factors help prioritize secrets in code that are more likely to fall into the wrong hands and give a bad actor access to your business-critical systems.

OWASP Top 10

Globally recognized as one of the most important standards for developers and application security, the OWASP Top Ten, affiliated projects such as the OWASP API Security Top 10, and guides such as the Secure Product Design Cheatsheet include categories of risks that have informed tools and processes for decades. 

In Apiiro, you can filter SAST risks that fall into the OWASP Top 10–2021 categories or their matching CWEs to rapidly identify and remediate these risks. 

···

With the addition of the contextual prioritization funnel you can sharpen your focus across all risks and specific types of risks to lighten your triage load and give you a more granular and representative understanding of your application risk posture. Plus, with Apiiro’s risk-based policy and workflow engine, all of these risk factors can be leveraged to define how and when you block commits or releases, trigger processes, and alert your team.

To get a more in-depth look at the part prioritization plays in ASPM platforms, download our ASPM Deep Dive.