A developer tools company distributes software used inside thousands of organisations. What supply chain controls matter most, and why is this threat model different from a typical SaaS?

Why the threat model differs

A SaaS compromise affects the SaaS. A compromise of distributed developer software affects every organisation that installs it, and it runs on machines holding source code and production credentials. The blast radius is not your customers' data; it is your customers' entire engineering estate.

This makes the build and distribution pipeline the highest-value target in the company — considerably more valuable than production infrastructure — and it is frequently protected less well, because it is "internal".

The controls that matter most

1. Build integrity and reproducibility. The artefact shipped must be provably the result of building the reviewed source. Reproducible builds allow independent verification that a binary corresponds to its source, which is the only defence against a compromised build machine inserting code that is in no repository.

2. Signed artefacts with a protected signing key. Keys in hardware security modules, signing as a separate stage from building, with the key never available to build code. If the build can access the signing key, compromising the build compromises signing.

3. Provenance attestation. A signed statement of what was built, from which commit, by which builder, with which dependencies — verifiable by the consumer. This is what makes "is this the real artefact" answerable.

4. Dependency control. Pinned versions with verified hashes, an internal mirror so builds do not fetch from the public internet at build time, and review of new dependencies. Dependency confusion — where an internal package name is registered publicly and takes precedence — remains a live vector.

5. Isolation of untrusted build inputs. Contributions from outside must not run with access to signing credentials, deployment tokens or internal networks. The pipeline definition itself must come from the trusted branch, not from the contribution — otherwise every other control is bypassed.

6. Update channel integrity. The auto-update mechanism is a remote code execution channel by design. It needs signature verification on the client, rollback protection to prevent forcing an old vulnerable version, and staged rollout so a bad or malicious update reaches a bounded population.

The organisational controls

• Two-person review for changes to build and release infrastructure, treated with more rigour than application code.
• Separation of duties between those who can commit code and those who can release.
• An inventory of what is in each release, so that when a dependency vulnerability is announced, the answer to "are we affected, and which versions" takes minutes.
• A tested revocation and emergency update path. The response to a compromised release is a race, and the mechanism must exist beforehand.

The uncomfortable question

"If our build system were compromised today, how long until we noticed, and what would we tell customers?" For most organisations the honest answers are "possibly never" and "we do not know which artefacts are affected" — and both are addressable with provenance and inventory, before rather than after.