Supply Chain and Third-Party Risk: When Your Attack Surface Is Not in Your Own Building

Core premise: you harden your own building, but the attacker may never enter through it. A large share of a modern enterprise's attack surface sits on someone else's systems. Angle: risk mechanics and a checklist. No operational detail.

Why "locked doors" is not the same as secure

The traditional posture is to tighten your own perimeter. But today's execution path looks like this:

your code → calls a few dozen open-source packages → runs on cloud services → deployed by CI/CD → collaborated on via SaaS → partly maintained by outsourced teams

Controlling any link in that chain hands an attacker a key into your environment — without breaching a single one of your own defences.

Four links, four risk mechanics

Link one: open-source packages — "the code you did not write"

In modern applications, self-written code is usually a small fraction; the rest comes from packages. That brings three risks:

Risk one: substitution. An attacker gains publish rights (say, by stealing a maintainer's credentials), plants malicious logic in the package, and every project depending on it is hit on the next update.

Risk two: name confusion. Publish a package with a name similar to a popular one (a slight spelling difference), tricking developers into installing it.

Risk three: long-term dormancy. Ship a seemingly useful package, accumulate users, then add malicious behaviour in some later version.

Defensive meaning: "pin the version, verify the fingerprint" is the baseline. Mature teams write dependency hashes into configuration files and compare automatically at install time — confirming they received the original, not a substituted build.

Link two: vendors and service providers — "the people you trust are trusted too"

Many enterprises outsource development, operations, or support. Two problems follow:

Problem one: excessive access. For convenience, providers often demand broader access than internal staff — and keep it indefinitely.

Problem two: lateral contagion. A provider serves many clients. If it is breached, the attacker can use it as a springboard to reach several enterprises at once.

Defensive meaning: vendor access should follow the same principles as employee access — least privilege, just-in-time, full audit. And one key question: how fast can you revoke their access if they are breached?

Link three: cloud dependencies — "the layer you cannot see"

Moving workloads to the cloud shifts part of the security responsibility to the provider (shared responsibility). That creates a common misconception: "the cloud makes us secure automatically".

In practice, most cloud security incidents are not provider breaches — they are customer misconfigurations: public buckets, over-broad permissions, disabled logging, leaked keys.

Defensive meaning: cloud environments need "configuration governance", not just "buying the service". Continuous configuration checks and automated detection of anomalies matter far more than after-the-fact remediation.

Link four: toolchain and CI/CD — "automation automates your risk too"

Automated deployment makes "change a line, ship it" routine. But if the CI/CD system is controlled, an attacker can:

• inject malicious code during the build (leaving no trace at the source level);
• read the keys and credentials used at deploy time;
• deploy any version they wish.

Defensive meaning: treat CI/CD as one of your highest-value assets — its permissions, secrets, and access logs deserve special handling.

Why attackers like supply chains

From an attacker's view, supply chains offer three advantages:

1. One attack, many victims — far more efficient than breaching each target;
2. Bypassing existing defences — arriving via a trusted source trips far fewer checks;
3. Stealth — malicious behaviour can hide inside a normal update for a long time.

A checklist you can use directly

Open-source dependencies

• Is there a complete dependency inventory (with versions and hashes)? Who maintains it?
• Is there automated scanning for known vulnerabilities? Who acts on results?
• Is there an approval process for adding a dependency?

Third-party providers

• Have you inventoried every external party with access to your systems?
• Is their access minimised and time-bound?
• How long does revoking access take if they are breached?
• Do contracts include security obligations and audit rights?

Cloud environment

• Are public buckets and over-broad permissions checked regularly?
• Are cloud audit logs enabled and actually reviewed?
• Do long-lived keys exist? Can they be replaced with temporary credentials?

CI/CD and toolchain

• Who holds access to the deployment system?
• How are the secrets used during builds managed?
• Can you detect "what was deployed differs from the source"?

Governance

• Is there a named owner for supply-chain risk?
• When was the last third-party risk review?

Three one-liners

1. The attack surface is no longer inside your building. Hardening only your own systems is locking a single door.
2. Supply-chain risk is about transitive trust. You trust a provider; the attacker only needs that trust once.
3. A checklist beats panic. Most supply-chain incidents stem from basics not done, not from exotic attacks.

Next steps

• For how credentials change shape in the cloud, read cloud identity and permissions
• For where credentials sit in the attack chain, read credentials and AD concepts
• For an overall defensive review, read defense lessons from a red-team postmortem