Software Supply Chain Executive Briefing: Board Questions on Code You Build and Buy

Every organisation runs code it did not write and cannot fully inspect, and attackers have learned that poisoning that code once reaches thousands of victims through their normal update and build processes. Open source packages, build pipelines, developer tools, AI coding assistants and vendor updates are now the main way malicious code enters trusted environments, usually carried by a stolen publishing token or maintainer account. Regulators have noticed: the EU Cyber Resilience Act puts security duties on anyone placing software on the EU market, and the UK Software Security Code of Practice asks software vendors to appoint a senior responsible owner. This briefing is for directors, chief executives, chief technology officers, chief risk officers and CISOs, in organisations that build software, buy it, or both. It covers software you produce and software you consume; supplier contracts and vendor oversight are covered in the Third-Party and Supply Chain Risk Executive Briefing, and the engineering detail in the Software Supply Chain Security Guide.

The risk in one paragraph

A software supply chain attack compromises something you already trust (a library, a build server, a developer's account, a signing key or a vendor's update channel) so that malicious code arrives with a valid signature and passes through normal approval. It then runs with whatever access your build systems and production services hold, which often includes cloud credentials and secrets. Most recent attacks did not exploit a clever vulnerability: they stole a token. A single npm publishing token, CI bot token or code signing key in the wrong hands was enough to push malicious releases downstream. For a board the exposure has two sides: as a consumer, whether you would know within hours that you had pulled a poisoned component and could remove it; and as a producer, whether your own pipeline could be used to ship malicious code to your customers, with the liability and regulatory consequences that follow.

Why this is a board-level issue now

• The attacks have industrialised. The Shai-Hulud worm used stolen npm tokens to republish packages with a credential stealer that spread itself (first wave), and later waves in 2026 reached enterprise packages (Mini Shai-Hulud). The tj-actions compromise leaked CI/CD secrets from thousands of repositories through one stolen bot token (tj-actions).
• Trusted maintainers and builders are targets. The xz utils backdoor came from a maintainer identity built up over years (xz utils); SolarWinds attackers inserted code during the Orion build and reached around 18,000 customers (SolarWinds).
• Developer tools are now part of the chain. IDE extensions and AI coding assistants run with developers' access. A tampered marketplace extension update in 2026 planted an attacker's SSH key on developer machines (Cursor marketplace). See the Application Security and AI-Generated Code Executive Briefing.
• EU law is phasing in. The Cyber Resilience Act entered into force on 10 December 2024. Manufacturers must report actively exploited vulnerabilities and severe incidents from 11 September 2026, and the main obligations apply from 11 December 2027. Fines for breaching the essential requirements can reach 15 million euros or 2.5% of worldwide annual turnover, whichever is higher. See the EU Cyber Resilience Act Executive Briefing.
• UK and US expectations have changed shape. The UK Software Security Code of Practice (published 7 May 2025) is voluntary but sets 14 principles and asks for a senior responsible owner at senior leadership level. In the US, OMB memorandum M-26-05 (23 January 2026) rescinded the mandatory secure software self-attestation memos M-22-18 and M-23-16 in favour of a risk-based approach; agencies may still use the CISA attestation form and may ask for SBOMs in contracts. Federal customers will still ask questions; the answers are now less standardised.

Two sides of the exposure

MITRE ATT&CK records these attacks as T1195 Supply Chain Compromise, with T1195.001 Compromise Software Dependencies and Development Tools and T1195.002 Compromise Software Supply Chain.

Why it is really an identity problem

The common thread in recent incidents is a non-human credential: a registry publishing token, a CI bot token, a cloud key in a build environment, a code signing key. These credentials are rarely protected by MFA, often long-lived, and held by many people and systems. The Codecov attackers altered a CI script to harvest the secrets of every customer pipeline that ran it, which then exposed a vendor's product signing key (HashiCorp). Three controls change the odds most:

• No long-lived publishing tokens: trusted publishing from CI using short-lived federated identity, so there is no static token to steal.
• Least privilege for pipelines: build jobs get read-only access by default, and release and signing credentials are available only to protected release jobs. See the CI/CD Pipeline Identity Security Guide.
• Protected signing keys: keys held in hardware or a managed key service, used only by the release pipeline, with every use logged. See the Code Signing Security Guide.

Five questions for the board to ask

1. If a widely used component were found poisoned this morning, how long would it take us to know every system that contains it? A credible answer is a measured time based on SBOMs or a software inventory, not a search across teams.
2. Who can publish or sign software in our name, and how are those credentials protected? Expect a list of publishing and signing identities, short-lived where possible, with owners and MFA on human accounts.
3. Can we prove that what we ship was built from our reviewed source, on our build system? Look for build provenance (for example at a stated SLSA Build level) and verification at deployment.
4. What do our developer tools and AI coding assistants have access to, and who approves new ones? Extensions, plug-ins and agents run with developer credentials and can reach source and secrets.
5. Which of our products fall under the EU Cyber Resilience Act, and are we ready for its reporting duties? Expect a product list, an owner and a process for the 24 hour early warning on actively exploited vulnerabilities.

Red flags in management answers

• "We scan for vulnerabilities": scanning finds known flaws, not malicious packages or tampered builds. Ask what stops a malicious release from being installed.
• "We sign everything": signing proves who signed, not what was signed. If an attacker controls the pipeline or the key, the malware is signed too.
• "We have SBOMs": ask whether they are generated automatically for every release, ingested, and matched to advisories. A file nobody reads does not reduce risk.
• No owner for open source: nobody decides which public registries and packages are allowed.
• Tags instead of pins: builds pull third-party actions or images by mutable tag, so a compromised upstream changes your build silently.
• Secrets in pipelines everywhere: cloud admin keys available to every build job, including those triggered by external pull requests.

What good looks like

Decisions for the board

• Producer or consumer first: organisations that sell software or software-based products should prioritise build integrity, signing and CRA readiness; organisations that mainly consume software should prioritise inventory, approved sources and speed of response.
• Risk appetite for open source: decide whether teams may pull directly from public registries or only through a governed proxy with a delay or review for new packages. The second option costs some developer speed and removes a large share of risk.
• SBOM expectations from suppliers: decide for which critical software you will require SBOMs and vulnerability exploitability statements in contracts.
• Size matters: a small organisation can get most of the value from pinned dependencies, a managed package proxy, MFA on registry accounts and trusted publishing. A large producer needs a platform team owning build integrity, provenance and key management, and a product security function for CRA duties.

Where to invest first

1. Remove long-lived publishing and CI tokens: move to trusted publishing and short-lived credentials; inventory what remains. Cheap, and it addresses the most common entry point.
2. Software inventory that can be searched in hours: automated SBOM generation and ingestion for what you build and your critical bought software. See the SBOM Guide.
3. Governed dependency intake: a package proxy, pinning and checks for malicious packages and dependency confusion. See the Malicious Package and Dependency Confusion Guide.
4. Build integrity and provenance: isolated builders, protected release jobs and signing keys. See the SLSA and Build Provenance Guide.
5. A rehearsed response: a playbook for a poisoned dependency, including secret rotation for every pipeline that ran it. See the Malicious Open Source Package Response Playbook.

Metrics to track

A 90-day plan

• Days 1 to 30: appoint a senior responsible owner; list every publishing, CI and signing credential with an owner; identify products that may fall under the EU CRA.
• Days 31 to 60: enforce MFA on all registry and repository accounts; move the highest-risk publishing tokens to trusted publishing; turn on SBOM generation for the main products; pin third-party CI actions by commit.
• Days 61 to 90: run a poisoned-dependency tabletop and time the search for affected systems and the secret rotation; report measured times, gaps and a funded plan to the board.

Common failure patterns

• Static tokens in CI: long-lived registry or bot tokens in pipeline variables, as in the SpotBugs token leak that started the reviewdog and tj-actions chain.
• Trusting the release artefact over the source: the xz utils trigger shipped in release tarballs, not in the Git repository.
• Secrets left after the clean-up: teams remove the bad package but do not rotate the credentials it could read, so the attacker keeps access.
• Developer workstations out of scope: extensions and AI tools on laptops hold the same source and cloud access as the pipeline.
• Compliance by paperwork: attestations and SBOMs produced for customers but not used internally.

Lessons from incidents

The 2025 chain that ran from SpotBugs to reviewdog to tj-actions is the clearest lesson for boards. One personal access token leaked from one project's pipeline. It was used to compromise a maintainer's account, then a widely used CI action, which then printed the secrets of thousands of downstream pipelines into their build logs. None of the victims was attacked directly: they were exposed because their builds trusted a third-party component by a movable tag and gave it access to every secret in the job. The board-level points are that the entry point was a machine credential, that the blast radius was set by how much access ordinary build jobs held, and that the recovery cost was dominated by finding and rotating every exposed secret. In our assessment, organisations that pinned actions by commit and limited job permissions were largely unaffected. See the Supply Chain NHI Breaches Lessons Guide.

Practitioner checklist

• Senior responsible owner for software security named and reporting to the board.
• Inventory of publishing, CI and signing identities with owners; long-lived tokens on a removal plan.
• Phishing-resistant MFA on all repository and registry accounts.
• SBOM generated for every release and ingested into a searchable inventory.
• Dependencies and CI actions pinned and pulled through a governed proxy.
• Release and signing credentials limited to protected release jobs; signing keys in hardware or a managed key service.
• Build provenance produced and verified before deployment.
• Vulnerability disclosure process published; EU CRA reporting route defined where in scope.
• Poisoned dependency playbook exercised, including full secret rotation.

Standards and references

• UK Government: Software Security Code of Practice
• European Commission: Cyber Resilience Act
• European Commission: Cyber Resilience Act reporting obligations
• OMB: M-26-05, Adopting a Risk-based Approach to Software and Hardware Security
• NIST: SP 800-218, Secure Software Development Framework
• OpenSSF: SLSA specification
• MITRE ATT&CK: T1195 Supply Chain Compromise
• NIST: Cybersecurity Framework 2.0

How NHI Mgmt Group can help

We provide independent non-human identity risk assessments and board briefings, focused on the publishing tokens, CI credentials, signing keys and cloud secrets that turn a supply chain compromise into a breach. Our NHI Foundation Level Training Course helps security, platform and IAM teams govern the machine credentials in their pipelines. Contact us to arrange a briefing.

Related NHI Mgmt Group resources: Software Supply Chain Security Guide · UK Software Security Code of Practice · Supply Chain NHI Breaches Lessons Guide · Third-Party and Supply Chain Risk Executive Briefing. This guide summarises regulatory expectations for board members and is not legal advice.