Product engineering teams must own supply chain risk
Modern software products are no longer built. They are assembled.
Every production system is now an aggregation of external code, managed services, open-source packages, SaaS platforms, CI/CD tooling, and infrastructure you do not control.
What you deliver to customers is not primarily the output of a single codebase or team. It is the by-product of a global, decentralised software ecosystem.
This is our software supply chain.
Every organisation now participates in one, whether they acknowledge it or not. And it is no longer just a graph of technical dependencies. It is a chain of custody that defines:
- Who is allowed to influence your product
- How that influence is exercised
- Whether changes are observable
- If compromises are reversible
- If integrity is provable
Why are product teams now operating in hostile territory?
Recent events in the JavaScript/npm ecosystem demonstrate a shift in how software products are being attacked.
High-profile incidents including maintainer-account takeovers, credential phishing campaigns, malicious dependency updates, and the “2025 Shai-Hulud 2.0” worm show that the weakest link in modern product delivery pipelines is no longer internal code, it is the trust model surrounding the third-party software they are built upon.
To start, we need to be clear about how directly your software supply chain shapes the outcomes your products can achieve. A representative failure mode looks like this:
- Credential Theft: A third-party maintainer’s credentials are compromised
- Malicious Publish: A malicious version of a dependency is published
- Silent Bypass: Because no trusted pipeline is enforced, security controls fail to prevent the publishing
- Auto-Ingestion: The package installs cleanly and downstream products ingest the infected dependency automatically
- Compromise: Your product, credentials, customer data and broader business ecosystem is now compromised
We are here because third-party, mostly open-source dependencies, have historically been granted implicit trust by default by engineering teams. That trust model is now demonstrably broken. Sustained and increasingly sophisticated attacks on open-source ecosystems show that “trusted” dependencies are no longer a safe assumption but a primary attack surface.
When trust itself is compromised, build pipelines and update mechanisms become high-leverage distribution channels for attackers. Exploitation happens silently, propagates automatically, and frequently persists for long periods before detection. By the time teams recognise an incident, compromised code has often already been embedded deeply across environments, customers, and releases.
The solution is cryptographic proof of where our dependencies originated (provenance) and whether they were signed by a trusted environment (attestations).
We need to make trust explicit, enforceable, and verifiable for the dependencies we rely on throughout our product development lifecycle, so that integrity is proven before the products depending on them reach customers.
The software supply chain is no longer an engineering detail, it is a core value flywheel that directly influences product outcomes. That is why this post explores what the software supply chain is, and what autonomous teams must do now to ensure the integrity of what they build.
Is your supply chain an asset or liability?
Like its physical equivalent, your software supply chain directly shapes commercial outcomes. Which in turn directly influences your products:
- Delivery velocity
- Operational stability
- Incident likelihood
- Regulatory exposure
- Product reputation
- Customer trust
- Long-term revenue
Your software supply chain also defines the blast radius when something goes wrong. When it’s compromised, the impact is rarely confined to a single service or release. Failures propagate through delivery timelines, operational stability, customer experience, and most critically, the trust of your customer. What begins as a technical fault rapidly becomes a reputational, regulatory, retention, and revenue risk.
Software supply chains are one of the primary engines of modern product productivity. They allow organisations to externalise complexity into supply networks of specialist-built components, managed platforms, and shared infrastructure, which significantly accelerates delivery while increasing technical depth.
A great example of this is React, a foundational supply component that commoditises large-scale client-side application development by standardising state management, composition models, and rendering lifecycles.
Without software supply chains, most product roadmaps would collapse under the weight of undifferentiated lower-layer engineering. The risk is not that organisations depend on software supply chains, it is that they do so without enforceable guarantees of integrity, provenance, and authenticity.
What does decentralisation cost when trust fails?
Product organisations have intentionally pushed ownership closer to the teams building value.
Teams now:
- Own roadmaps
- Control releases
- Operate independent toolchains
- Select dependencies freely
- Ship continuously
This operating model dramatically increases the likelihood of achieving product–market fit. However, it also weakens centralised technical governance by design, as delivery authority is decentralised to teams. Decisions that used to be centrally controlled are now made locally (and if they are not, teams are unable to achieve true autonomy). This decentralisation creates unseen areas where risk can enter your product's foundations.
When teams can ingest external dependencies freely, ship code from uncontrolled environments, and release without provenance guarantees, risk does not accumulate locally, it accumulates systemically.
This is because supply-chain failures rarely remain contained within a single feature or service.
They propagate across systems and teams because compromised components commonly lead to credential leakage and unauthorised access to customer data. For example, when your build setup unknowingly runs infected software that sends access keys outside the company, or when a bad update quietly copies database credentials while your application is running.
The result is slowed roadmap execution, erosion of customer trust, and a shift from delivery to sustained incident response. As deployment frequency increases, so does the operational and financial cost of compromise.
This has led organisations to develop platform-level capabilities that raise the bar on autonomous product teams security posture with minimal investment needed from the teams themselves.
What is the trust gap?
The central security platforms discussed in the previous section often provide capabilities to teams such as:
- Vulnerability scanning
- Dependency analysis
- Software Bills of Material (SBOM)
- Static analysis
- Policy linting
These measures have raised the baseline and improved visibility of posture, but they stop short of addressing the main problem that results in far too many attacks: trust.
After all, vulnerability scanning, dependency audits, bills of material, and static analysis describe what is in your software. They do not prove whether it is authentic, untampered, or reproducibly built.
Autonomous teams are encouraged to move fast and make local decisions about the dependencies and tooling they adopt. But every time a team installs a third-party package, they implicitly place trust in software built by someone outside the organisation, using processes they do not control and infrastructure they cannot see. For example, code that enters your product may have been created on someone’s home computer, with no checks on how it was built or whether it was altered before it reached you.
A malicious update delivered through a trusted channel will bypass scanners that only reason about code structure rather than origin, execution context, or trust identity. Cryptography, which is how software proves it has not been changed or tampered with, is essential for establishing trust, but it only becomes effective when combined with identity, policy, and enforcement. Once compromised software is inside your build pipeline, detection is already too late, and you may remain exposed until the attack is noticed by the wider community, often several months after initial exposure.
This is the gap we need to close, by making trust explicit, verifiable, and enforceable at the point software enters your product, not after damage has been done. That is exactly where verifiable and enforceable (attestation) policies around the origin (provenance) of our supply chain come into play.
How do we close it?
Today, one of the industry’s most robust answers to the problem of trust in software delivery is a framework called SLSA (Supply-chain Levels for Software Artifacts). It is not a tool or a product, but a mental model around how software should be built if trust is to be earned rather than assumed.
SLSA introduces a structured model of provable integrity into software delivery. It exists to answer the question: “can this software be trusted to run in your product?”. Rather than relying on reputation, assumptions or convention, SLSA requires evidence.
SLSA formalises three guarantees every product leader should demand from engineering:
- Software can be traced back to its original source
- Builds are executed in controlled and verifiable environments
- The artifacts produced by those builds cannot be silently altered after the fact
This shifts trust away from dependency names and version numbers, and replaces it with something stronger: proof.
That proof takes the form of attestations.
Think of an attestation as a tamper-proof digital passport for your code. It is a cryptographically signed statement that binds a software artifact to its origin. It records:
- Source: Which repository the code came from
- Version: The exact commit that was built
- Builder: The system that performed the build
- Workflow: The specific process that produced the output
In simple terms, an attestation says: “This package was built from this source, in this pipeline, and here is the proof”.
Crucially, SLSA does not centralise control away from teams. Verifiable trust is pushed directly into the hands of developers, allowing dependencies to be validated before software is even built.
Attestations are not only for CI pipelines, they can be verified locally on developers’ machines as part of pre-commit checks and development workflows.
In doing so, compromised dependencies can be stopped before they ever reach version control. The question then becomes: how do product teams apply these ideas without slowing delivery…
How do I start implementing supply chain trust today?
The shift to SLSA can start now. It affects how your product is built and released today. Teams do not need a large programme, a formal maturity model, or a transformation plan to begin.
Instead, product leaders should view this as a progressive journey up the SLSA levels, moving from simple documentation to hardened infrastructure.
Step one - Remove build ambiguity
The first step is to always build software through a central, trusted build server, while creating metadata alongside each release that records what was actually built. Releases must only ever be produced by controlled, scripted pipelines.
Teams should be able to trace every deployed build back to a specific source revision and build process. If this cannot be done reliably, then the organisation has no trustworthy release process.
This maps to SLSA Build Level 1.
Ensure the build process is fully scripted using a recognised system such as GitHub Actions or Jenkins, while producing basic provenance metadata that describes what was built. At a minimum this should include the commit hash that was used for the build, published alongside the artifact.
Step two - Establish build trust
Once builds are scripted, the next priority is ensuring the output can be trusted. If a dependency or artifact cannot prove where it came from using cryptographic proof, it should not flow through the pipeline.
This maps to SLSA Build Level 2.
It requires implementation of build infrastructure that acts as a hardened root of trust. The build platform must assert identity at runtime using OpenID Connect (OIDC). By doing so, the platform itself cryptographically signs the build provenance.
This changes the trust model entirely. The signature no longer originates from a developer’s laptop or a long-lived private key stored in CI. It is derived from a verified pipeline identity controlled by the platform.
The result is a tamper-proof seal that guarantees the software was built by the pipeline, in the declared repository, under the declared workflow conditions.
Many modern ecosystems already support this model. For example, npm can publish packages with provenance, provided the runner has an OIDC identity available:
npm publish --provenance --access public
Step three - Make trust explicit
Finally, make trust explicit at the product boundary. Not all systems carry the same business risk, and not every workload needs the same security posture. Teams must explicitly decide what “trusted” means for each product and enforce it through policy, not convention.
The goal at this stage is to prevent the build environment itself from becoming an attack vector.
This maps to SLSA Build Level 3.
At this level, builds must run in ephemeral, isolated environments. Each build executes inside a fresh container or virtual environment that is created for a single run and destroyed immediately afterwards.
This eliminates entire classes of failure:
- Cross-build contamination
- Configuration drift
- Hidden persistence in runners
- Compromise spreading between pipelines
High-risk workloads must be built in hardened isolation by default.
We should all be implementing a trust operating system
The software supply chain is no longer a background engineering concern. It is an operating system for your product. It defines what you can ship, how confidently you can ship it, and how much damage can occur when something goes wrong.
Product teams already own delivery velocity, customer experience, and reliability. Supply chain integrity needs to sit alongside these responsibilities as a first-order concern.
