What a Supply Chain Attack Actually Is

Your perimeter held. Your code was reviewed. Your scanners were green, your dependencies were up to date, and you were compromised anyway, by an update you chose to install, from a vendor you selected, delivered over a channel you authorised, carrying a valid signature.

The Concept Explained

Every security control you are used to defends the things you expose: open ports, public endpoints, authentication surfaces, user input. That model assumes the attacker is on the outside trying to get in.

A supply chain attack inverts it. The attacker compromises something you trust, and lets your own systems import the result.

How It Works

The trust you have already extended

Start with an uncomfortable inventory. A typical service in production runs:

• Code your team wrote, which is reviewed
• Direct dependencies your team chose, which are probably reviewed once at adoption
• Transitive dependencies nobody chose, often hundreds, frequently thousands
• A base image containing an entire operating system userland
• Build tooling, compilers, and pipeline actions pulled from public sources
• A runtime, libraries, and agents injected by the platform

The proportion your team actually wrote is usually a rounding error. Everything else arrived because something you trusted vouched for it, and most of it was never evaluated by anyone in your organisation.

That is not a failure of discipline. Nobody can review a dependency tree of that size. It is the actual operating condition, and supply chain security starts from accepting it rather than pretending otherwise.

Why attackers prefer this

The economics are the whole story:

Direct attack     compromise one target      ->  one target
Supply chain      compromise one upstream    ->  every downstream consumer

Compromising a widely used package, a popular pipeline action, or a vendor's build system gives an attacker reach into thousands of organisations they could never have breached individually, including ones with far stronger security than the upstream they attacked.

It also selects for a different kind of adversary. The patience required is considerable: contributing to a project for two years before acting, or sitting in a build system for months. That profile means these attacks skew toward well-resourced actors with specific objectives, and it means the payload is frequently targeted. Thousands are infected; a handful are exploited.

Why detection is genuinely hard

Conventional detection asks whether an artifact has been tampered with. In a supply chain attack, it has not: the malicious artifact is exactly what the vendor produced and shipped.

• Checksums match, because the checksum was calculated on the malicious build.
• Signatures verify, because the legitimate signing key signed it.
• The version is the version you asked for.
• The vendor's own release notes describe it.

Nothing downstream is in a position to notice. The subversion happened upstream, before any of the integrity mechanisms were applied, and those mechanisms faithfully attest to the compromised result.

That observation is the reason this course exists, and it points directly at what has to change.

From securing systems to securing artifacts

If integrity checks cannot help because the artifact is authentic, the questions have to become different ones:

Traditional          Is this artifact unmodified since the vendor released it?
                     -> Yes. And that is not the question.

Supply chain         What is actually inside it?
                     Where did each part come from?
                     How was it built, by what, from which inputs?
                     Who is asserting that, and can I check their claim?
                     Does it meet my policy, and what enforces that?

Every module in this course answers one of those. Knowing what is inside is SBOM (Module 6). Knowing where it came from is dependency and source integrity (Module 2). Knowing how it was built is provenance (Modules 3 and 4). Knowing who asserts it is signing and attestation (Module 5). Enforcing the answer is verification (Module 7).

What the attacks share

Four incidents are dissected in Lesson 1.3. What they have in common is worth stating up front, because it shapes every control that follows:

• The distribution channel was legitimate. Nothing was smuggled in.
• The compromise happened upstream of the integrity mechanisms, so those mechanisms certified it.
• Time to detection was long, measured in months or years, and detection was frequently accidental.
• The victims did nothing wrong by the standards of conventional security practice.

That last point matters for how you present this work internally. These are not incidents caused by teams being careless. They are caused by a trust model that the industry accepted for decades and is only now instrumenting.

In Production

• Start with an inventory, not a tool. Most organisations cannot answer "what artifacts are running in production, and where did each come from" without a project. That gap is the real starting position.
• The build system deserves the scrutiny you give production. It has network access, credentials, and the ability to modify what ships. It is frequently less monitored than the workloads it produces (Module 3).
• Assume the compromise will look legitimate. Design controls that check how something was made, not just whether it changed in transit.
• Time to answer is the metric that matters. When the next widely used package is backdoored, the practical question is how many hours it takes you to determine whether you are affected (Module 6).
• This is a platform-team problem. Individual teams cannot verify a dependency tree of thousands. Controls have to live in shared infrastructure: registries, build systems, and admission policy.

Tradeoffs and Decision Framework

Trust against verification cost. Verifying everything yourself is not feasible; trusting everything blindly is the current default. The work is deciding which trust relationships to instrument, and the highest-leverage ones are the build system and the point of deployment.

Prevention against detection. Preventing every compromise upstream is not achievable, since you do not control upstream. Detecting quickly and answering exposure fast is achievable, and is where most practical value sits.

Breadth against depth. Signing every artifact weakly is easier than verifying a few things well. Verification with no enforcement is theatre, so depth on the critical path beats breadth with no teeth (Module 7).

Doing this now against later. Provenance and SBOMs are most valuable when you need them urgently, which is exactly when you cannot retrofit them. Their value is entirely front-loaded, which makes them a hard sell and a genuine one.

Common Mistakes

Treating vulnerability scanning as supply chain security. Scanners find published flaws in known packages, not deliberately introduced backdoors.

Assuming a valid signature means safe. It means the artifact is what the publisher produced, which is precisely the problem when the publisher was compromised (Lesson 1.4).

Focusing only on dependencies. Dependency risk is real and highly visible. The build system is the higher-leverage target and receives far less attention.

Believing a private registry solves it. It controls distribution, not what went into the artifact you pushed.

Reviewing direct dependencies only. The transitive tree is where the volume, and usually the risk, actually lives.

Waiting for a mandate. The controls take months to roll out and their value is realised in the first hour of an incident.

Treating it as a compliance exercise. Generating attestations nobody verifies satisfies an auditor and stops nothing.