Software supply chain attack
In threat terms, a software supply chain attack compromises something an organisation already trusts and installs, rather than attacking the organisation directly. The malicious code arrives signed, through the update mechanism, and reaches every customer of the compromised component at once.
How it works
Several distinct routes share the label. A dependency in a public package registry is compromised, either by taking over a maintainer’s account or by the maintainer being coerced or replaced, and a new version ships hostile code to everyone who updates. The build system is compromised, so the source stays clean and the artefact does not, which is the hardest case to detect because reviewing the code proves nothing. A vendor’s update infrastructure is compromised and signed updates carry the payload. Or a supplier with a trusted network route into customers is used as the path.
What they have in common is that the trust decision was made in advance and correctly: this is a component we depend on, signed by the party we expect.
What goes wrong
Endpoint controls are not looking. A signed component from a known vendor, installed by the update process, behaving within its normal execution context, is precisely the profile a security product is tuned to ignore, and tightening that tuning generates unacceptable noise. Detection therefore has to come from behaviour after installation: the component making network connections it never made before, reading data unrelated to its function, or spawning processes it has no reason to spawn.
The second problem is that most organisations cannot answer the first question asked during one of these events, which is whether they contain the affected component and in what version. Without an SBOM generated per build, answering takes days, and the answer arrives after the decision had to be made. Transitive dependencies make this worse: the affected package is usually not one anybody chose.
Third, the durable outcome is often a backdoor in something that will be reinstalled from the same source during recovery, so eradication has to include the pipeline and not just the hosts.
Where this shows up in an audit
In a due diligence this is a structural question rather than a scan. Who can publish to the artefact repository, are builds reproducible, are artefacts signed with provenance, is dependency resolution pinned or floating, and is there an inventory per release. A target that cannot show the pipeline controls carries a risk that no amount of application testing will surface. Findings are paired with composition analysis output, which answers what is present, while this answers who could change it. This is part of how we assess third-party and build-chain risk in a due diligence.