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 5-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”
In 2017, Equifax disclosed a breach that exposed the personal data of 147 million people. The root cause was a known Apache Struts vulnerability that had a patch available for two months before the breach. A SAST scan integrated into their build pipeline would have flagged the vulnerable code path the moment a developer touched a file anywhere near it. The scan did not exist. The patch sat undeployed. The breach cost Equifax over 700 million dollars in settlements.
SAST stands for Static Application Security Testing. Unlike general static analysis (which finds style issues and generic bugs), SAST is built to find security vulnerabilities specifically. injection, cross site scripting, buffer overflows, insecure cryptography, hardcoded secrets, command injection, path traversal, and hundreds of other vulnerability classes that show up in OWASP Top 10 year after year.
That distinction sounds like a technicality until you watch both kinds of tool read the same file.

Read the line numbers rather than the messages. eslint stopped at 15 and 22. semgrep stopped at 20 and 29. Four findings, and not a single line appears in both lists.
Line 20 is the one that matters. It builds a SQL statement by concatenating a value straight out of the request, and eslint walked past it without a word, because eslint was never asked whether that string reaches a database. It was asked whether the code is tidy, and the code is tidy. Meanwhile semgrep said nothing about the unused import on line 15, because an unused import is not a way in.
Neither tool is failing. They answer different questions: a linter judges the code you wrote, a SAST tool traces where untrusted input travels. This is why "we run a linter in CI" is not an answer to "do you do SAST", and why a clean lint run tells you nothing at all about line 20.
The shift left argument is concrete. A SAST finding during a PR costs the developer 15 minutes to fix. The same vulnerability found during a penetration test costs a security engineer a day to reproduce and report, plus the developer's time to fix, plus a retest cycle. The same vulnerability found in production costs incident response, customer notification, regulatory reporting, and possibly litigation. Shifting the detection earlier by weeks saves orders of magnitude in total cost.
Checkmarx, Veracode, Fortify, and Snyk Code are the major commercial SAST tools. Semgrep and CodeQL are the open source options that most startups and mid-sized companies run. GitHub includes CodeQL scanning for free on all public repositories and as part of GitHub Advanced Security for private repos. The tooling has reached a point where there is no financial excuse for skipping it.