We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Security Testing Operations
Free preview: the first part of this 6-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Security Testing Operations
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
On December 9, 2021, a researcher published a proof of concept for a remote code execution vulnerability in Apache Log4j, a Java logging library so ubiquitous that it was a transitive dependency of nearly every Java application on the planet. Within hours, attackers were scanning the entire internet for vulnerable endpoints. Within days, every security team in every company was racing to find which of their services used Log4j, directly or buried four levels deep in the dependency tree, and whether those services were exposed. The vulnerability scored a perfect 10 on the CVSS scale. The patch was available, but identifying which services needed it was the hard part.
The Log4Shell incident taught the industry a lesson it should have already known. You do not just ship your code. You ship every dependency your code pulls in, and every dependency those dependencies pull in. The average Node.js application has over 1,000 transitive dependencies. A Python machine learning project can easily hit 500. A Java with Spring Boot pulls in hundreds of jars, most of which the developer never explicitly chose.
That claim is easy to state and easy to nod along to, so here it is happening on a package.json small enough to read in full.

Three names in a file became sixty-three packages on disk. That ratio is the whole reason SCA exists as a separate discipline from code review: a reviewer can read three lines and approve them honestly, and still have approved sixty-three packages they never saw.
Look at which findings are marked as yours. Four of the seven live in libraries nobody typed into that file, and the single worst finding in the run, a critical in form-data, is one of them. form-data arrived because request needed it. Nobody made a decision about form-data, nobody reviewed it, and no amount of care at the moment of choosing a dependency would have surfaced it. That is the gap an SCA tool is built to close, and it is why the answer to Log4Shell was tooling rather than discipline.
Software Composition Analysis (SCA) tools exist to solve exactly this problem. They parse your lockfile, resolve the full dependency tree including transitives, check every package and version against vulnerability databases, and tell you which ones have known CVEs, what the severity is, and whether a patched version exists. Dependabot, Snyk, Mend, and OWASP Dependency-Check are the leading tools. Most can automatically open pull requests to upgrade vulnerable dependencies, which means the fix for a known CVE can land without a developer filing a ticket.
The cost of not running SCA is measured in incident response hours. Stripe's security team described their Log4Shell response as requiring every engineer to stop feature work for a week to audit dependencies. Companies that had SCA in place already had a list of affected services within minutes.