GIC Engineering Consultants
Home Articles Services Contact
Compound Risk: The Threat Neither Dashboard Shows You Alone

Compound Risk: The Threat Neither Dashboard Shows You Alone

By Marcus House, Splunk Enterprise Architect

Most security programs watch threats against AI and software vulnerabilities as two separate disciplines, on two separate screens, owned by two separate instincts. That separation is reasonable. It is also where compound risk hides.

Two True Signals That Compound

Consider what each signal tells you on its own.

An active threat against an AI system, an ATLAS-mapped detection, tells you an adversary is interested. Someone is probing your model, attempting extraction, testing prompt-injection paths. On its own, it's a detection to triage among many.

A critical vulnerability in a component, especially a KEV-listed one, tells you a known-exploitable weakness is present, and CISA confirms it's being exploited in the wild. On its own, it's a remediation to prioritize among many.

Now put them on the same application. An AI system that is both under active attack and built on a component an attacker can already exploit is not the sum of two medium risks. It's a single high-priority situation: a motivated adversary, and a working way in. That is the case you want at the top of the queue, and it's precisely the case neither dashboard surfaces, because each is only looking at its own half.

What Compound Risk Correlation Does

The Compound Risk view in SCIP, the Splunk app that I built for supply chain and AI threat intelligence, correlates active MITRE ATLAS detections against the critical and KEV-matched vulnerable components on the same application, and surfaces the applications where both are true. It answers a question neither the AI-security side nor the vulnerability side can answer alone: where is adversary interest landing on top of an exploitable path?

The mechanism is deterministic, not inferential. You configure the mapping between your AI applications and their SBOM products in Setup Section 1d, so SCIP knows which software inventory belongs to which AI system. From there the correlation is a straight join of two signals SCIP already produces in Splunk: the ATLAS detections it runs against your AI systems, and the vulnerability matches it runs against your SBOM inventory. Same application, active detection, critical or KEV-listed component present. That intersection is the view.

Nothing here is guessing. SCIP does not use AI to find this. It detects threats against AI deterministically, and it correlates those detections against deterministic vulnerability matches. The compounding is arithmetic, not judgment.

Why This Is Hard to Get Anywhere Else

A dedicated AI-security tool sees the threat activity but not your software bill of materials. A vulnerability or SBOM tool sees the components but not the ATLAS-mapped attacks. The correlation only exists if both signals live in the same place, keyed to the same application. SCIP produces both natively in Splunk, which is what makes the single-view correlation possible. To my knowledge, no other Splunk-native app puts threat activity against AI systems and supply-chain vulnerability data in one correlated view.

The Honest Boundaries

Worth being precise about what this is. Compound Risk correlates two signals SCIP already generates; it does not invent a third. It depends on the AI-application-to-SBOM-product mappings being configured, and bad mappings produce bad correlation. It does not replace either underlying view; the ATLAS detections and the vulnerability findings still matter on their own. And it is a prioritization lens, not a verdict: a compound hit means look here first, not you are breached.

One Question, Not Two

There is a reason this matters now. AI systems are moving under formal governance, and as that scrutiny becomes real, "is my AI system secure?" and "is the software my AI system runs on secure?" stop being two questions for two teams. They are one question about one asset. Compound Risk is what that single question looks like on a dashboard.

If you run AI systems on software you didn't write, and everyone does, the components underneath them are part of their attack surface. Configure your AI-application-to-SBOM-product mappings in Setup and the correlation populates. Install SCIP from Splunkbase: splunkbase.splunk.com/app/8814

Which of your AI applications are sitting on a known-exploitable component right now, and would you know if an attacker was already probing it?

← Back to Articles