Lens 4 · Someone else's code
Lens 4
Someone else's code
Supply chain, cryptographic failures, and data integrity. Three risks united by one thing: trust in code, protocols, and components you didn't write.
01 / 12
Module 3 · Your progress
✓
Risk ≠ vulnerability
✓
What changed and why
✓
Architecture against you
4
Someone else's code
5
We can't predict everything
Lens 3 was about your architecture creating risk. This lens is about everything you didn't build — dependencies, crypto protocols, data integrity — and why trusting external code is itself a risk.
02 / 12
Lens 4 · A03 — Supply chain
Third-party code
A03 · Supply Chain Failures
Lens 2 covered why supply chain rose in the rankings. The short version: we compose more than we write, and we don't audit most of what we import. Here's what you can actually do about it:
Trusted repository — maintain a curated list of approved dependencies. SBOM — know what's in your build. Integrity checks — verify at install, verify at runtime.
Software Bill of Materials — a complete inventory of all components, libraries, and dependencies in your software. Think of it as a nutrition label for code. It lists what's inside, what version, and where it came from. Required by some regulations and increasingly expected by enterprise customers.
Key principle
"The core reason is that we use third-party code, and we don't always know who developed those dependencies and how. And that's a risk."
Champion's takeaway
Your supply chain risk grows with every transitive dependency you didn't choose. Run
npm ls --all and count what you've never heard of.03 / 12
Knowledge check · scenario
Knowledge check
Scenario
A developer on your team wants to add an npm package to handle date formatting. The package has 200 weekly downloads, no security audit, and one contributor. The code looks clean.
What's the right next step?
B — Check for a well-maintained alternative first. 200 downloads, one contributor, no audit — these are warning signs, not automatic disqualifiers. But before reaching for a niche package, check if a trusted, well-maintained library already covers the use case. Forking (C) creates a maintenance burden. Blanket-banning single-contributor packages (D) is too rigid — some excellent tools have one maintainer. The issue is making an informed decision, not applying a rule.
04 / 12 · Quiz
Lens 4 · A04 — Cryptographic failures
Boring crypto
A04 · Cryptographic Failures
Key principle
"You should not develop crypto protocols. They already exist. You should know how to properly use them. That's it. Do not invent the wheel."
Cryptographic failures dropped from #2 to #4 — not because crypto matters less, but because tooling has matured. The core reason this category exists: developers implement protocols themselves instead of using existing, vetted libraries.
Even using existing protocols correctly is hard:
Worth remembering
"You can pass a year and a half of university cryptography and still not fully understand what each KMS configuration option means. That's not a personal failure — that's the nature of the field. And that's exactly why we should be very careful and pay attention to each configuration."
Practical rule
Boring crypto = correct crypto. If you're implementing something clever, you're implementing something wrong.
05 / 12
Myth vs reality
🔐
Common assumption
"Crypto is for crypto engineers, not for us"
Reality
You don't write algorithms — but you configure crypto every day. Which TLS versions to allow. How to store API keys — plaintext env vars or secrets manager? Whether to enforce certificate pinning. How often to rotate credentials.
Each wrong answer is a cryptographic failure under A04 — even with zero lines of crypto code. The "boring crypto" principle says use existing libraries. Correct — but using existing crypto correctly is its own skill.
Each wrong answer is a cryptographic failure under A04 — even with zero lines of crypto code. The "boring crypto" principle says use existing libraries. Correct — but using existing crypto correctly is its own skill.
06 / 12
Lens 4 · The boring crypto checklist
Five rules
The Boring Crypto approach
1
Use vetted, well-rated libraries
Not popular — vetted. Look for security audits, active maintenance, and a track record. Popularity alone doesn't mean secure.
2
Use standard protocol implementations
TLS 1.3, AES-256-GCM, Ed25519 — these exist for a reason. The boring choice is almost always the right one.
3
Minimal custom configuration
Every config knob you touch is a chance to weaken the protocol. Use defaults from vetted libraries unless you have a specific, documented reason to change them.
4
No speed-vs-security trade-offs
If someone suggests weakening crypto for performance, the answer is no. Optimize elsewhere. Crypto is the last thing you should compromise on.
5
Read the Boring Crypto advice list
It's intentionally short and easy to remember. One page of guidance that covers most decisions a Security Champion will face.
07 / 12
Lens 4 · A08 — Integrity failures
Three states, two moments
A08 · Software & Data Integrity
Maintaining integrity is structurally hard. Data exists in three states — at rest, in transit, and in process — and each requires different protections.
You verify the hash of a package when you install it. You check the signature of a container image before deploying. This is point-in-time verification — it proves the component was intact at that moment. Most teams do this well.
What about after deployment? If a component is compromised in production — modified binary, injected code, tampered config — do you detect it? Runtime integrity checking is harder, more expensive, and most teams skip it. That gap is exactly what A08 measures.
Key principle
"Are we able to maintain the integrity of components? Do we check it just during installation? But what about during runtime — if they've been compromised?"
Remember
Data has three states: at rest, in transit, in use. Each needs different integrity controls. Most teams only protect transit.
08 / 12
Knowledge check · scenario
Knowledge check
Scenario
Your CI pipeline verifies the hash of every dependency at install time. A month after deployment, one of those dependencies is compromised — a maintainer's credentials were stolen and a backdoor was injected into a patch release. Your running service pulls the update automatically.
What was missed?
C — Runtime integrity verification was missing. The install-time hash check was correct — for the version that existed at that moment. But without runtime integrity verification, the auto-updated component ran unchecked. Version pinning (B) helps but doesn't solve the fundamental gap: you need to verify components not just when you install them, but while they're running. This is the install vs. runtime distinction at the heart of A08.
09 / 12 · Quiz
Lens 4 · The picture
Every box is someone else's code. One compromised package — three levels deep — and the infection propagates all the way to your root.
10 / 12
Lens 4 · What we covered
Lens 4 complete
Someone else's code
A03 — Supply Chain: we use third-party code we didn't audit. Mitigate with trusted repos, SBOM, and integrity checks. There is no silver bullet — only constrained trust.
A04 — Cryptographic Failures: don't write your own crypto. Use vetted libraries with minimal custom configuration. The "Boring Crypto" approach: vetted, standard, minimal, no trade-offs.
A08 — Integrity Failures: data exists in three states (rest, transit, process). Components need verification at install and at runtime. The gap between the two is where this risk lives.
Your score: calculating...
Next: Lens 5 — injection, authentication, logging, and exceptional conditions. Four risks at the limits of what we can anticipate.
11 / 12
Lens 4 · Done
Lens 4 complete
Every dependency is a trust decision. Make them deliberately.
Three risks. One root: code, protocols, and components you didn't write are running in your product right now. The only defense is constrained, verified trust.
12 / 12
⏸ Pause to reflect