Security teams keep adding tools — SCA, SAST, container scanning, runtime detection — yet still struggle to answer a simple question: if an attacker compromised our build pipeline tomorrow, would we recognize the technique? The MITRE ATT&CK framework was built to answer exactly that question, giving defenders a shared vocabulary for adversary behavior instead of a pile of disconnected alerts. Enterprise ATT&CK v15 (April 2024) catalogs 14 tactics, roughly 203 techniques, and 435 sub-techniques, including a dedicated Supply Chain Compromise entry (T1195) with three sub-techniques covering dependencies, build tools, and hardware.
Vendors like Aqua Security have leaned heavily on ATT&CK to market their cloud-native and runtime detection coverage, particularly through the Aqua Nautilus research team and the open-source Tracee project. But mapping detections to ATT&CK tactics is not the same as closing the gaps that real supply chain incidents — SolarWinds, Codecov, 3CX, XZ Utils — have exposed. This piece breaks down what ATT&CK actually covers, where runtime-focused tools like Aqua stop short, and how Safeguard closes the build-time gap.
What Is the MITRE ATT&CK Framework, and Why Does It Matter for Supply Chain Security?
MITRE ATT&CK is a publicly maintained knowledge base of adversary tactics and techniques, first released in 2013 and now maintained by the MITRE Corporation with community contributions. It organizes real-world attacker behavior into 14 tactics (the "why," like Initial Access or Persistence) and hundreds of techniques (the "how"), each backed by documented incidents. For supply chain security specifically, the relevant entry is T1195 (Supply Chain Compromise), broken into T1195.001 (compromise software dependencies and development tools), T1195.002 (compromise software supply chain), and T1195.003 (compromise hardware supply chain). It matters because it gives security and engineering teams a common language to say "this alert corresponds to a known technique used in the SolarWinds breach" rather than treating every finding as novel.
How Many Real Incidents Have Mapped to T1195, and What Do They Have in Common?
At least four major, publicly confirmed incidents since 2020 map directly to T1195, and all four exploited trust in the build or distribution pipeline rather than a runtime vulnerability. SolarWinds (disclosed December 2020) involved attackers inserting the Sunburst backdoor into Orion software builds — T1195.002. Codecov (disclosed April 2021) involved a modified Bash Uploader script that exfiltrated CI secrets for months — T1195.001. The 3CX attack (March 2023) was a cascading, second-order supply chain compromise originating from trojanized X_TRADER software. Most recently, the XZ Utils backdoor (CVE-2024-3094, discovered March 29, 2024) showed a maintainer account compromised over roughly two years of social engineering before malicious code was inserted into liblzma. In every case, the malicious activity happened before the affected artifact was ever deployed — meaning runtime detection saw nothing until it was too late.
How Does Aqua Security Map to ATT&CK, and Where Does That Coverage Actually Apply?
Aqua Security maps its detections primarily to the MITRE ATT&CK Containers matrix (introduced in 2021) and the Cloud matrix, using Tracee — its eBPF-based runtime security tool — to flag behaviors like privilege escalation, container escape, and suspicious process execution once a workload is already running. This is genuinely useful for tactics like Execution, Privilege Escalation, and Defense Evasion inside a live container or Kubernetes cluster, and Aqua's annual Cloud Native Threat Report has documented real increases in runtime attacks, including a reported rise in software supply chain attacks targeting public registries. The gap is temporal: Tracee and similar runtime-focused tools instrument the container after the image is built and deployed. T1195.001 and T1195.002 activity — a poisoned dependency pulled during npm install, a tampered CI script, a compromised maintainer commit — happens upstream of that boundary. Runtime ATT&CK mapping tells you a technique fired inside a running workload; it does not tell you whether the artifact running in that workload was trustworthy when it was built.
What Does "Left of Runtime" Coverage Actually Require Under ATT&CK?
Closing T1195.001/.002 requires provenance and build-integrity controls that map to ATT&CK tactics runtime tools were never designed to observe, such as Initial Access via compromised developer credentials and Persistence via malicious CI/CD pipeline modifications. The complementary frameworks that engineering teams increasingly pair with ATT&CK reflect this: the OWASP CI/CD Security Top 10 (published 2022) enumerates risks like insufficient pipeline-based access control and poisoned pipeline execution, while SLSA (Supply-chain Levels for Software Artifacts, v1.0 released April 2023) defines four levels of build provenance guarantees, from basic build tracking to hermetic, verifiable builds. Neither framework is a replacement for ATT&CK — they operate at a different layer, covering the build and distribution stages that precede the runtime tactics ATT&CK's Containers matrix documents. A mature ATT&CK program needs both: technique-level detection at runtime, and provenance verification at build time, tied back to the same T1195 sub-techniques.
How Should a Vulnerability Management Program Prioritize Findings Using ATT&CK?
Findings should be prioritized by mapping each vulnerability or misconfiguration to the ATT&CK technique it most directly enables, then weighting toward techniques with documented exploitation in the last 24 months. For example, a hardcoded CI/CD credential maps to Valid Accounts (T1078) and Unsecured Credentials (T1552) — both used in the Codecov incident — and should outrank a theoretical container escape technique with no observed exploitation in your environment's threat model. CISA's Known Exploited Vulnerabilities (KEV) catalog, which as of mid-2024 listed over 1,100 CVEs with confirmed in-the-wild exploitation, is a useful cross-reference: CVEs on that list frequently correspond to well-documented ATT&CK techniques, giving teams a data-backed way to triage the flood of "critical" CVSS scores that scanners produce. Without this mapping, teams tend to chase CVSS severity alone, which the CVSS specification itself notes does not account for exploitation likelihood or environmental context.
How Safeguard Helps
Safeguard was built specifically to close the build-time gap that runtime-focused platforms like Aqua leave open, while still giving teams a clean way to reason about coverage in ATT&CK terms. Where Tracee and similar tools instrument workloads after deployment, Safeguard instruments the pipeline itself — generating verifiable SBOMs at build time, tracking artifact provenance from commit to registry, and flagging the exact conditions that enabled T1195.001 and T1195.002 incidents: unsigned commits, unpinned dependencies, unauthorized pipeline modifications, and secrets exposed to CI runners.
Every finding Safeguard surfaces is mapped to its corresponding ATT&CK technique and tactic, so security teams can report coverage the same way they already report on runtime tools — but with the build and dependency layer included rather than assumed. Safeguard cross-references CVEs against CISA KEV and known exploitation data before surfacing them as priorities, so engineering teams aren't stuck triaging every CVSS 9+ finding equally. And because Safeguard tracks provenance continuously rather than at a single scan point, it can detect the kind of slow-burn compromise seen in the XZ Utils backdoor — where a trusted maintainer's access degraded gradually over roughly two years — by flagging anomalous commit patterns and dependency changes as they happen, not months later during an audit.
For teams already running Aqua or a similar runtime platform, Safeguard is not a replacement — it's the upstream half of the same ATT&CK-mapped story: provenance and build integrity feeding into the runtime detection you already have, so a technique like Supply Chain Compromise is covered end to end instead of only from the point of deployment onward.