Skip to main content

Supply-chain and identity attacks

Estimated read: 20-30 minutes · Builds on: M6: Identity & access management and M11: Cloud security fundamentals

This is a fast-moving topic

Briefings give you the durable shape of a trend, not breaking news. For the latest, see Staying current.

What you'll get from this briefing​

  • The strategic shift: attackers log in or come through a supplier rather than "hack in" through the perimeter.
  • How software supply-chain attacks work: compromise one, reach thousands.
  • Why vendor/third-party risk is now core GRC work (and an entry-level workload).
  • The identity attack playbook: credential theft, MFA fatigue, token theft, over-privilege.
  • What zero trust actually means, minus the marketing.

1. The strategic shift: around the walls, not through them​

Decades of investment made the traditional perimeter (firewalls, hardened networks) genuinely harder to breach head-on. Attackers responded the way any rational adversary does: they changed the entry point. Two doors are now favourites:

  1. Your suppliers: the software you install, the services you integrate, the vendors who hold your data or have access into your network. Trust flows along those connections, and trust is exploitable.
  2. Your logins: why break the window when a stolen key opens the front door? A large share of modern intrusions begin not with an exploit but with a valid credential, used by the wrong person.

Both share one property that matters for defenders: the initial activity looks legitimate. A signed software update installs. A real username logs in. That's what makes these attacks effective, and it's why behavioural detection (M8) and identity discipline (M6) are where modern defence concentrates.

2. Software supply-chain attacks: compromise one, reach thousands​

The pattern: instead of attacking 10,000 organisations, compromise one thing they all install.

  • Vendor build compromise. The most famous public example is the SolarWinds incident (disclosed 2020): attackers compromised a vendor's software build process, so a routine, digitally-signed product update delivered a backdoor to thousands of customer organisations, including government agencies. The victims did nothing wrong except install a trusted update on schedule.
  • Open-source component compromise. Modern software is assembled from open-source libraries, so poisoning one widely-used component poisons everything downstream. The xz-utils backdoor (found 2024) is the canonical example: a patient attacker spent years gaining maintainer trust on a small compression library that ships inside major Linux distributions, then inserted a backdoor, caught (narrowly, and famously) by an engineer investigating a minor performance anomaly.
  • Other flavours you'll hear named: dependency confusion and typosquatting (tricking build systems into pulling a malicious lookalike package), and compromised developer credentials pushing malicious updates to legitimate packages.

Defences to know by name:

  • Patching discipline still wins: supply-chain attacks are the rare argument for caution windows on brand-new updates, but unpatched software remains the far larger risk; the resolution is risk-based patching, not not-patching (M5: Essential Eight).
  • SBOM (Software Bill of Materials): a machine-readable ingredient list for software, so when the next poisoned library is announced you can answer "do we run it, and where?" in minutes instead of weeks.
  • Vendor assurance, which brings us to GRC.

3. Third-party and vendor risk: the GRC angle​

M10 flagged vendor risk as a huge entry-level GRC workload; supply-chain attacks are the reason why. The working questions of third-party risk are simple to state and endless in practice:

  • What do we depend on? (an inventory of vendors, software, and integrations, you can't assess what you haven't listed)
  • What could each one break or leak? (data held, access granted, business process supported)
  • What assurance do we have? (security questionnaires, certifications like ISO 27001, SOC 2 reports, contract clauses on breach notification)
  • What's the plan when a vendor is breached? (because "when", not "if": your incident-response plan needs a supplier-compromise scenario)

A junior GRC analyst spends real hours sending, chasing and assessing vendor questionnaires. It isn't glamorous; it's the immune system of the modern interconnected organisation, and it's genuinely how careers start.

4. Identity is the perimeter now​

M6 made the argument; here's the attack-side view of why identity dominates current intrusions:

TechniqueHow it worksThe counter
Credential stuffingPasswords leaked from site A replayed against site B, because humans reuseUnique passwords (manager), MFA
Phishing for credentialsFake login pages, now AI-fluent (threat-landscape briefing)Phishing-resistant MFA (passkeys/hardware keys), user reporting culture
MFA fatigue / push bombingSpam push-approval prompts until a tired user taps "approve"Number-matching prompts, rate limits, hardware keys
Token/session theftSteal the already-authenticated session cookie or token, bypassing the login (and its MFA) entirelyShort-lived tokens, device binding, conditional access, monitoring
Over-privileged accountsOne compromised login shouldn't unlock everything, but often doesLeast privilege, access reviews, PAM (M6)
Dormant/service accountsForgotten accounts with standing access and no owner watchingJoiner-mover-leaver discipline, regular access reviews (M6)

Two implications worth saying out loud in an interview:

  • "MFA everywhere" is necessary but not sufficient: attackers now target the session after the MFA, which is why monitoring identity logs (impossible travel, anomalous token use, your M8 tabletop) matters even in MFA'd environments.
  • In the cloud, identity is nearly the whole game (M11): most real cloud breaches trace to leaked keys, misconfigured access, or over-privileged identities, not exotic exploits.

5. Zero trust, minus the marketing​

You'll meet "zero trust" as a buzzword; here's the plain version. The old model trusted by location: inside the network = trusted. Supply-chain and identity attacks break that assumption: the attacker is inside, wearing a valid login or riding a trusted update.

Zero trust flips the default: trust nothing by location; verify every access explicitly. In practice it's a direction, not a product, assembled from things you already know:

  • strong identity verification for every request (not just at the front door),
  • least privilege, so any single compromised identity opens as little as possible,
  • device health checks and conditional access,
  • segmentation, so one foothold can't roam,
  • continuous monitoring, because verification isn't a one-off event.

If a vendor tries to sell "zero trust in a box", the correct professional response is the M8 one: polite skepticism, then verify.

Self-check​

Q1. Why do attackers favour supply-chain and identity paths over attacking the network perimeter directly?

Because perimeters got hard and trust got exploitable: a compromised vendor update or a valid stolen login looks legitimate on arrival, bypassing perimeter defences entirely. It's cheaper to log in (or ride in via a supplier) than to break in.

Q2. What is an SBOM and what question does it let you answer quickly?

A Software Bill of Materials: a machine-readable ingredient list of the components inside your software. When a component compromise is announced (like the xz-utils backdoor), it answers: "do we run the affected component anywhere, and where?", in minutes rather than weeks.

Q3. Your organisation has MFA on every account. Which identity attacks remain, and what closes the gap?

Token/session theft (stealing the post-login session, bypassing MFA), MFA fatigue (bombarding push prompts), and abuse of over-privileged or dormant accounts. Counters: phishing-resistant MFA (passkeys/hardware keys, number matching), short-lived tokens and conditional access, least privilege with access reviews, and monitoring identity logs for anomalies.

References & further reading​