Opening Framing: The Safest Door Is the One You Must Open Regularly
In Week 9 we studied evidence: how systems record truth and how attackers distort it. Now we confront a deeper reality:
Most systems are not compromised by "breaking in." They are compromised by being changed.
And change in modern computing is routine and necessary. Operating systems update. Packages update. Libraries update. Dependencies update. A system that never updates becomes vulnerable; a system that updates carelessly becomes compromised.
Updates are the primary mechanism by which defenders fix vulnerabilities — and the primary mechanism by which attackers try to insert "legitimate" malicious code. The update pipeline is both your greatest defense and a critical attack surface.
An update mechanism is a privileged delivery channel. If attackers can compromise it, they can deliver malware that looks like legitimate software.
Mental Model: The Medicine Supply Chain
Imagine a hospital. Medicines save lives — but only if:
- They come from a trusted manufacturer: verified source, licensed facility
- They are not tampered with in transit: sealed packaging, chain of custody
- They are correctly labeled: right medicine, right dosage, right expiration
- They are administered to the right patient: correct recipient, correct timing
Software updates are "medicine" for vulnerabilities. They fix security flaws, patch bugs, and keep systems healthy. But if the supply chain is poisoned, the medicine becomes the attack.
If a system accepts updates, it is accepting code that will run with authority. Therefore, updating is not merely maintenance — it is an act of trust. Security depends on answering: Who is allowed to publish updates? How does the system verify authenticity and integrity? What happens if verification fails?
Mental model: updates are medicine delivered through a supply chain. Poison the supply chain, and every patient who trusts it is compromised.
1) Patching: The Defender's Dilemma
Patching exists because vulnerabilities exist — and vulnerabilities are inevitable. Every piece of software has bugs; some bugs have security implications. The real security question is:
How long can you tolerate known weakness?
This creates a genuine dilemma:
- Patch too slowly: you remain exposed to known vulnerabilities that attackers are actively exploiting
- Patch too fast: you risk instability, outages, or breaking critical systems with untested changes
- Don't patch at all: you accumulate technical debt and eventually become impossible to secure
This is not a technical argument. It is a risk-management argument. The "right" patching speed depends on your threat model, your tolerance for downtime, your testing capacity, and the criticality of your systems.
Zero-day vulnerabilities (unknown to defenders) get the headlines, but most breaches exploit known vulnerabilities that simply weren't patched in time.
Key insight: patching is risk management, not just maintenance. The question is which risk you prefer — exposure or instability.
2) What "Supply Chain" Means in Software
In software, the supply chain is everything that stands between you and the code you run:
- Operating system vendor repositories: Microsoft Update, apt repositories, Red Hat repos
- Package managers and registries: npm, PyPI, Maven Central, NuGet
- Mirrors and CDNs: geographic distribution of packages
- Build pipelines and CI systems: where source code becomes binaries
- Dependency graphs: your dependencies' dependencies (transitive dependencies)
- Signing keys and certificates: cryptographic proof of authenticity
If any link in this chain is compromised, an attacker can deliver malicious code that looks completely legitimate. The code is signed, comes from expected sources, and installs through normal channels.
Modern applications have deep dependency trees. A single web application might depend on hundreds of packages, each with their own dependencies. You're not just trusting your direct dependencies — you're trusting the entire tree.
Key insight: your supply chain includes everyone whose code runs in your environment. That's far more people than most organizations realize.
3) Trust Chains: Authenticity vs Integrity
Two fundamental properties matter when accepting updates:
- Authenticity: "This update really came from who it claims to come from." Verified through digital signatures and certificates.
- Integrity: "This update was not altered in transit or storage." Verified through cryptographic hashes.
Systems try to enforce these using mechanisms like:
- Code signing: vendor signs packages with private key; you verify with public key
- Hash verification: published checksums let you verify downloaded files match
- Certificate chains: trust anchored in root certificates you already trust
- Secure transport: HTTPS prevents tampering during download
If you can't verify origin and integrity, you are downloading uncertainty.
But these mechanisms only work if the signing keys themselves aren't compromised. If an attacker steals a vendor's signing key, they can create "authentic" malware. If an attacker compromises the build system, they can inject malicious code before signing.
Key insight: cryptographic verification proves the update came from whoever holds the key. It doesn't prove the key holder is trustworthy or uncompromised.
4) Why Attackers Target Update Systems
Update systems are extremely attractive targets because they offer:
- Scale: compromise one pipeline, affect thousands or millions of machines that pull from it
- Privilege: updates typically run with administrator/root authority to modify system files
- Legitimacy: malicious code arrives through trusted channels, signed with trusted keys, installed by trusted tools
- Persistence: code is installed into normal system locations, survives reboots, and may be difficult to distinguish from legitimate software
- Stealth: update activity is expected and often not scrutinized
This is why sophisticated attackers — especially nation-state actors — invest heavily in compromising build systems, signing keys, and distribution infrastructure. It's not about breaking a lock — it's about becoming the locksmith.
A successful supply chain attack turns every organization's security practices against them. The more diligent they are about patching, the faster they install the compromise.
Key insight: supply chain attacks weaponize trust. The same mechanisms that make updates secure (signatures, trusted sources) make supply chain attacks devastating.
Real-World Context: Supply Chain Attacks in Practice
Supply chain attacks are not theoretical. They are among the most devastating attack vectors in modern cybersecurity:
SolarWinds / SUNBURST (2020): Attackers compromised the build system for SolarWinds Orion, a widely-used IT monitoring platform. Malicious code was inserted into legitimate updates, signed with SolarWinds' own keys, and distributed to approximately 18,000 organizations including US government agencies. The backdoor provided persistent, stealthy access for months before discovery. This is the canonical supply chain attack.
Codecov (2021): Attackers modified a bash uploader script used in CI/CD pipelines. For two months, the compromised script exfiltrated environment variables — including credentials and tokens — from thousands of build environments. The attack targeted the build pipeline itself, not the final product.
NotPetya (2017): Attackers compromised the update mechanism for M.E.Doc, Ukrainian accounting software. The malicious update deployed destructive malware that spread globally, causing over $10 billion in damages. Organizations were compromised because they did the "right thing" — they kept their software updated.
Supply chain compromise interacts with everything we've studied: malicious updates can install services (Week 6), create scheduled persistence (Week 7), and disable logging (Week 9). A compromised update is the cleanest intrusion — no noisy exploit required.
Common thread: in each case, attackers targeted the delivery mechanism rather than individual systems. Compromise the source, and every downstream consumer is affected.
Guided Lab: Examining Your Update Trust Chain
This lab focuses on understanding how your system trusts updates and what mechanisms exist to verify authenticity and integrity.