TL;DR: OX Security’s OSC&R framework creates a MITRE-like reference model for software supply chain threats, giving teams a common way to describe attacker tactics, evaluate coverage, and scope red-team work, according to OXSecurity. The real shift is governance: supply chain security becomes measurable only when teams can define what is in the pipeline and what threat behaviors they must detect.
At a glance
What this is: OXSecurity’s OSC&R initiative is a software supply chain threat framework that standardises how teams describe and assess attacker tactics across the pipeline.
Why it matters: It matters because practitioners cannot govern software supply chain risk consistently if they cannot agree on the assets, attack patterns, and coverage gaps inside the pipeline.
Context
Software supply chain risk is broader than source code. It includes the build pipeline, signing process, dependencies, automation accounts, and the systems that move artifacts from commit to release.
The governance gap is not only technical weakness but shared terminology. When teams cannot consistently define what belongs inside the supply chain, they cannot measure exposure, compare controls, or align red-team scope with real attack paths.
That makes this a supply chain security and identity governance issue at the same time, because the pipeline is operated by workloads, service accounts, and automation identities that must be inventoried and controlled.
Key questions
Q: What breaks when software supply chain controls are not built into DevSecOps pipelines?
A: When supply chain controls sit outside the pipeline, teams lose visibility into what actually enters builds, and malicious or vulnerable dependencies can pass through as trusted inputs. The result is delayed detection, weaker release governance, and a false sense of security around applications that depend heavily on third-party code.
Q: Why does software supply chain visibility need to include pipeline identities as well as code?
A: Because attackers often compromise the systems that build and sign software, not just the source itself. If service accounts, runners, and release tokens are invisible, teams miss the actual trust relationships that let malicious changes propagate through the pipeline.
Q: What are the signs that supply chain controls are too fragmented to trust?
A: Different teams describe the same attack in different ways, red-team scope is unclear, and coverage reports focus on tools rather than adversary behaviour. Those symptoms usually mean the organisation has policy controls without a shared reference model for attack paths.
Q: How should security teams handle exposed secrets in modern software pipelines?
A: Treat exposed secrets as identity incidents, not just code defects. Identify the owning service, revoke the credential everywhere it may be used, and verify that downstream automation still functions. The goal is to shorten the secret’s usable life while preserving legitimate operations through a controlled rotation process.
Technical breakdown
Why a MITRE-like model matters for supply chain security
A MITRE-like model gives defenders a common vocabulary for attacker behaviour. Instead of debating vague notions of “supply chain security,” teams can map tactics, techniques, and procedures to named attack patterns, coverage gaps, and validation exercises. That matters because software supply chain risk spans code, build infrastructure, signing keys, and delivery systems. A reference model turns that complexity into something measurable, comparable, and testable across different environments and teams.
Practical implication: Use a shared threat model to classify supply chain controls by attack behaviour, not by tooling category.
PBOM and SBOM define different governance boundaries
An SBOM describes what software components are present in an artifact, while a PBOM, as framed here, is about what is inside the pipeline that builds and delivers it. Those are related but not interchangeable questions. If teams only know the bill of materials for the software, they can miss the identities, runners, secrets, and release controls that determine whether the pipeline itself can be abused. The article’s central point is that pipeline visibility is a prerequisite for meaningful supply chain threat analysis.
Practical implication: Inventory pipeline identities, runners, and release controls separately from software components.
Red-team scope needs behaviour-based reference points
Red teams and blue teams need more than a list of assets. They need a way to define which adversary behaviours should be tested, how coverage should be scored, and what evidence proves the control worked. Behaviour-based frameworks help because they translate supply chain risk into testable scenarios such as compromised build accounts, poisoned dependencies, or signing abuse. That is especially useful where multiple teams share responsibility across development, security, and operations.
Practical implication: Tie supply chain exercises to specific adversary behaviours and score them against those behaviours.
Threat narrative
Attacker objective: The attacker’s objective is to turn trusted build and release infrastructure into a distribution channel for compromise.
- Entry occurs when an adversary compromises a pipeline-adjacent account, runner, or dependency path rather than a normal user workstation.
- Credential or trust abuse follows when the attacker uses build-system privileges, signing access, or automation trust to reach release workflows.
- Escalation happens as the attacker moves from a single trusted component to broader artifact production, distribution, or downstream customer environments.
- Impact is achieved when malicious code, poisoned artifacts, or stolen pipeline trust are propagated at scale through the software supply chain.
Breaches seen in the wild
- HashiCorp GPG key exposure 2021: Codecov's poisoned Bash Uploader exposed the GPG key HashiCorp used to sign download checksums; HashiCorp rotated it and re-signed its releases.
- reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Software supply chain security fails when pipeline trust is treated as implicit: the article is right to centre common language, but the deeper issue is that build and release systems have become identity-rich attack surfaces. Service accounts, runner credentials, signing keys, and third-party actions all behave like NHIs with lifecycle, scope, and offboarding requirements. The governance problem is not just knowing what shipped, but knowing which machine identities can move that shipment. Practitioners should treat pipeline identity as a first-class control plane.
PBOM is the named concept that matters here: a pipeline bill of materials is the missing governance layer between software inventory and supply chain attack modelling. SBOMs tell you what the artifact contains, but they do not tell you which automation identities built it, which trust relationships were used, or where a malicious change could enter. That distinction changes prioritisation because the highest-risk control failures often sit upstream of the final package. Teams should use pipeline-level inventory as the basis for risk scoring, not as an afterthought.
A MITRE-like reference model only works if the organisation can map controls to behaviours: the value of OSC&R is not taxonomy for its own sake, but repeatable coverage analysis against adversary techniques. That aligns naturally with MITRE ATT&CK-style thinking and with NHI governance, because pipeline abuse often starts with credential access and trust abuse. Without behaviour mapping, teams end up measuring policy existence instead of attack resistance. Practitioners should demand control validation against real attack paths, not just control documentation.
Supply chain security and NHI governance are converging: software delivery now depends on non-human identities more than on human operators, which makes pipeline security an identity discipline in disguise. If runners, automation tokens, and signing keys are not lifecycle-managed, the supply chain inherits standing trust it cannot justify. This is why the article’s emphasis on visibility is so important: the attack surface is defined by who and what can act on behalf of the build process. Teams should govern pipeline identities with the same rigor they apply to privileged human access.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
- Read next: CI/CD Pipeline Identity Security Guide
What this signals
Pipeline identity is becoming the real control surface: software supply chain attacks increasingly succeed by abusing CI/CD runners, automation tokens, and signing trust rather than by touching a developer laptop. That is why governance has to move from code-only inventory to identity-aware pipeline inventory, with lifecycle ownership for every machine credential that can influence release.
Software supply chain security now needs behaviour mapping, not tool counting: a reference model is useful only when teams can tie controls to attack patterns and test those patterns repeatedly. Without that layer, organisations report coverage without proving resistance, which is exactly how pipeline compromise stays hidden until release time.
For practitioners
- Inventory pipeline identities and release trust Map every runner, service account, token, signing key, and third-party action that can influence build or release outcomes.
- Define a pipeline bill of materials Separate artifact inventory from pipeline inventory so you can see which automation identities, dependencies, and trust paths actually create risk.
- Map controls to adversary behaviours Use a behaviour-based reference model to tie detection, prevention, and validation to specific supply chain attack techniques.
- Scope red-team tests to pipeline abuse Test compromise scenarios involving maintainer tokens, build runners, dependency poisoning, and signing misuse rather than generic infrastructure intrusion.
- Rotate and offboard pipeline secrets aggressively Treat CI/CD credentials as high-value NHIs with explicit ownership, expiry, and revocation paths when projects, vendors, or staff change.
Key takeaways
- Software supply chain risk is not limited to code integrity, because build and release identities can be the real path to compromise.
- A common attack model makes supply chain defence measurable by linking controls to adversary behaviour instead of tool ownership.
- Pipeline inventory, secret lifecycle control, and behaviour-based testing are the controls that matter when release trust is the target.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Pipeline secrets and signing keys are central to software supply chain compromise. |
| NHI-05 — Overprivileged NHI | Build runners and release tokens often carry excess privilege across the pipeline. | |
| NHI-07 — Long-Lived Secrets | Persistent pipeline credentials create the trust window attackers exploit in supply chain attacks. | |
| Recommendation — Scan CI/CD and release workflows for leaked automation secrets and revoke exposed credentials immediately. Reduce runner and release credential scope to the minimum required for each pipeline stage. Replace persistent pipeline secrets with short-lived credentials and enforce explicit expiry. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The attack pattern centres on stealing or abusing pipeline credentials to distribute malicious artifacts. |
| Recommendation — Map supply chain detections to credential access and exfiltration behaviours in pipeline telemetry. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Pipeline identities need governed permissions and entitlement review like any other high-risk access path. |
| Recommendation — Apply PR.AA-05 to review pipeline entitlements and remove unnecessary release privileges. | ||
Key terms
- Software Supply Chain: A software supply chain is the set of tools, identities, dependencies, and processes that turn source code into deployed software. Because it relies on automation and privileged machine identities, it becomes a governance problem when access, signing, and deployment controls are too broad.
- Pipeline Bill Of Materials: A Pipeline Bill of Materials extends SBOM thinking into the delivery chain by recording what was used, transformed, and promoted during build and release. It matters because many supply chain risks are introduced after code is written, inside automation, packaging, and deployment steps.
- CI/CD runner: A CI/CD runner is the execution environment that performs build, test, or deployment jobs. It often has access to source code, tokens, and cloud credentials, which makes it a high-value identity surface when workflows are compromised.
- Pipeline Trust Gap: The mismatch between the trust a build or release system is given and the level of identity governance it actually receives. It appears when CI/CD accounts, signing identities, and automation tokens can change production outcomes without the monitoring, scope limits, or lifecycle controls usually reserved for privileged access.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is designed for practitioners who need to connect machine identity governance to real operational control.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org