The weakest links

Hollywood attackers crack encryption, but real attackers walk through unlocked doors.

The two most reliably unlocked doors in modern software are both things this curriculum has been quietly preparing you to see.

Door one: the code you borrowed

A vulnerable dependencyConcept · lights on your mapvulnerable dependencyA known flaw in a package your product ships on top of, sometimes several layers down the tree. Once it is public, exploitation is a race that slow patchers lose, so teams automate the scanning and treat the patching as urgent. The industry’s biggest breaches increasingly start here. is a security hole in code you borrowed, one of the hundreds of packages Module 3 showed you underneath every product. Those packages are the building’s basement, the levels below the one you live on, holding everything up.

Often it is not even a package you chose. Module 3’s transitive dependencies mean the hole can sit in a dependency of a dependency, a library you have never heard of, several floors down in that basement.

When a hole is found in a popular package, it is disclosed publicly and assigned an ID, a CVE number, so that every affected team can find and fix it. But publication tells defenders and attackers at the same moment, so disclosure day starts a race.

Nothing here is hypothetical. In 2021, a hole in Log4j, a tiny logging library buried under an enormous share of the world’s software, set off exactly this race, at global scale.

The defense is unglamorous and absolute. Know what you run (down the whole dependency tree), scan automatically (Module 12’s dependency-audit patrol, now wearing its reason), and patch fast.

So when security news says “critical vulnerability in [library you’ve never heard of] affects millions of sites,” you now know the whole story. Everyone’s basement shares pipes.

Door two: the data you kept

The second door works differently. It does not let attackers in. It decides how much they leave with, once anything else has let them in.

What they leave with comes from the company’s stored PIIConcept · lights on your mappersonally identifiable informationAny data that identifies a real person. In the breach frame, whatever you hold is what you can lose, so every record doubles as exposure.. Module 7’s word covers the names, addresses, cards, and ID scans that point at real people. Each record is an asset while it serves a customer. The moment an intruder copies it, that same record becomes the harm, since every copied record is one more person the company must now write to and warn.

That is what turns data retentionConcept · lights on your mapdata retentionThe discipline of deciding how long each kind of record lives and actually deleting it at the end. In the breach frame it is a security control, since a record already deleted has nothing to give an attacker., Module 7’s keep-or-delete rules, into a security tool. Audit the filing cabinet like a ledger, and every drawer earns one of three verdicts.

Read the three verdicts as trades. The active customers’ data earns its risk, since the product cannot serve them without it. The 2019 signups stopped being customers years ago, so their records earn nothing and can still leak, and that combination is what liability means here.

The ID scans are the worst drawer. They belong to a feature that no longer exists, so nothing reads them and nothing needs them, and the only event left in their future is a breach. The audit calls them payload, the word for what an attacker carries out.

Retention discipline is that audit, acted on. A schedule fixes how long each class of record is kept, deletion jobs enforce the schedule, and deletion requests are honored with Module 7’s machinery. None of it is glamorous, and all of it is breach-size reduction, decided years before the breach.

The principle fits in one sentence. Data you don’t hold can’t leak. The most secure record is the one you deleted on schedule.

The shape of the whole module: defense in depth

Step back, and Phase 7 assembles into one architecture, layers that each assume the others fail.

• MFA assumes passwords leak.
• Least privilege assumes accounts get phished.
• Encryption at rest assumes disks get stolen.
• Hashing assumes databases get dumped.
• Rotation assumes keys escape.
• Retention assumes the breach happens anyway, and shrinks it.

The professional name is defense in depth. It can sound like paranoia, but its emotional register is Module 10’s resilience thinking, pointed at adversaries instead of accidents.

Nothing is trusted absolutely, and everything is survivable.

The mental model to remember

Real attackers walk through unlocked doors, and the two most common are the code you borrowed and the data you kept too long.

A vulnerable dependency turns disclosure day into a race. Publication tells defenders and attackers at the same moment, and the defense is to know what you run, scan automatically, and patch fast.

PII retention is breach-size reduction decided in advance. Every record is an asset and a pre-breach liability, and data you don’t hold can’t leak.

The module’s whole shape is defense in depth, layers that each assume the others fail.

You should now be able to read any breach story and name the doors, and notice that the effective defenses are always boring. Boring is the point.