# product # engineering # security # architecture - 15 mins read 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...