Static Analysis & Secrets Detection

Static analysis and secrets detection both live at the same spot in the pipeline — the commit — and a lot of DevSecOps overviews lump them into one "shift-left scanning" sentence. The CDP blueprint expects you to know why that's an oversimplification: a SAST engine reasons about what your code does, a secrets scanner reasons about what a string looks like, and the tuning strategy, the failure mode, and the correct response to a hit diverge sharply once you look past the shared timing. This chapter goes past the category overview in SAST, DAST & SCA and the program-level view in secrets management into what the exam actually grades: tuning a rule set so real findings survive contact with a real team, triaging a false positive without disabling the rule that would have caught the next real one, naming the exact tools the curriculum names — SpotBugs, TruffleHog, Bandit — and walking one finding all the way from a raw scanner alert to a merged fix.

Two gates, one commit — and why they're not the same job

☺ Like you're 10: Both checks happen the moment you hit save, but one is judging your logic and the other is judging your text — mixing them up is the single biggest trap in this chapter.

A SAST engine builds a model of your program — an abstract syntax tree, a control-flow graph, sometimes a full interprocedural data-flow graph — and asks whether a dangerous pattern of operations exists: does untrusted input reach a dangerous function without passing through anything that neutralizes it. A secrets scanner builds no model of your program at all. It treats every file as an undifferentiated stream of bytes and asks a completely different question: does this string's shape or randomness match what a real credential looks like. It has no concept of a function, a variable, or a call graph, and it doesn't need one — a leaked AWS key is exactly as dangerous sitting in a comment, a log fixture, or a README as it is sitting in application code.

That difference in what's being modeled cascades into everything downstream:

Keep that table in your head for the rest of this chapter — it's the single distinction the exam checks for most often, usually by handing you a scenario with both kinds of finding in the same pull request and grading whether you respond to each one correctly.

How a SAST engine actually finds a bug

☺ Like you're 10: The engine doesn't "read" your code like a person — it turns it into a map of every path data can travel, then checks whether any path runs from something untrusted straight into something dangerous.

Every SAST engine starts by parsing source (or bytecode) into a structured representation — an abstract syntax tree (AST) — and building a control-flow graph on top of it. Deeper engines go one step further and build a data-flow graph that tracks a specific value as it's assigned, passed as an argument, and reassigned across functions. Three vocabulary terms carry almost every rule you'll see on the exam:

• Source — where untrusted data enters the program: an HTTP request parameter, a form field, a message off a queue, a file read from user upload.
• Sink — a dangerous operation that shouldn't receive unsanitized input: a SQL execute call, eval(), a shell command, a raw file-system path, an XML parser with external entities enabled.
• Sanitizer — anything on the path between them that neutralizes the taint: a parameterized query binding, an allow-list validator, an output encoder. A source reaching a sink with a sanitizer in between is safe; the same source reaching the same sink with nothing in between is the finding.

The engines named across this course's tool pages implement that model at different depths, and the exam expects you to know which is which:

Notice that SpotBugs and FindSecBugs are not the same tool wearing two names — this is a common exam wrinkle. SpotBugs (the modern fork of the older FindBugs project) is a general-purpose bytecode analyzer that ships bug patterns for things like null-pointer dereferences, resource leaks, and bad equals/hashCode implementations — useful, but not security-focused. FindSecBugs is a plugin that layers a security-specific detector catalog on top of SpotBugs's existing dataflow engine — detector families like SQL_INJECTION_JDBC, XSS_SERVLET, COMMAND_INJECTION, HARD_CODE_PASSWORD, and WEAK_MESSAGE_DIGEST_MD5. Run SpotBugs alone in a Java pipeline and you get code-quality findings with no security detectors at all; the security value in the worked example below comes specifically from FindSecBugs riding on SpotBugs's engine, not from SpotBugs by itself.

Tuning rules and triaging false positives

☺ Like you're 10: A rule set that flags everything gets ignored, and a rule set that gets weakened every time it's wrong stops catching anything real — tuning is finding the narrow path between those two failures.

An out-of-the-box SAST rule set is written to be broadly applicable across every codebase that might install it, which means it's necessarily imprecise about any one codebase's actual patterns. Tuning is the exam-relevant skill of narrowing that rule set until its output is mostly signal, without silently deleting the coverage that would have caught tomorrow's real bug. Four techniques cover most of what shows up on the exam:

• Baselining, not blanket suppression. Run the scanner once against the existing codebase, accept the current findings as a starting baseline, and gate the pipeline only on new findings introduced by a change — Semgrep's --baseline-commit flag and SonarQube's "New Code" period both implement exactly this. A 3,000-line legacy repo with 400 pre-existing findings shouldn't block every future PR until all 400 are cleared; it should stop growing that number on day one.
• Confidence and severity thresholds, tuned per rule category. Bandit reports both a severity and a confidence independently; Semgrep rules carry a confidence metadata field; SonarQube's Quality Gate conditions are configured per-severity. Gating merge-blocking on HIGH confidence while routing MEDIUM and LOW to a dashboard for periodic review keeps the hard gate trustworthy without throwing away lower-confidence signal entirely.
• Documented, expiring suppressions — never silent ones. An inline suppression comment (# nosec B608, // NOSONAR, a CodeQL query-level exclusion) is sometimes the right call, but only when it carries a linked ticket and a reason a reviewer can evaluate. A suppression with no justification is functionally identical to disabling the rule for that one line forever — nobody ever goes back and re-checks it.
• Writing your own rules. Off-the-shelf rule packs cannot see your team's internal footgun APIs — a database wrapper that skips parameter binding, an internal templating helper that doesn't auto-escape. A custom Semgrep rule closes exactly that gap:

# .semgrep/rules/no-raw-db-wrapper.yaml
# Off-the-shelf rules can't see our own footgun API — write one that can.
rules:
  - id: acme-raw-query-wrapper-no-bind
    languages: [python]
    severity: ERROR
    message: >
      Db.raw() concatenates its argument directly into the SQL string.
      Use Db.query() with bound parameters instead. See go/db-wrapper.
    metadata:
      cwe: "CWE-89: SQL Injection"
      confidence: HIGH
    patterns:
      - pattern: Db.raw($QUERY)
      - pattern-not: Db.raw("...")   # a pure string literal has nothing to inject

Triage is the decision that happens every time a finding — new or existing — actually lands in front of a human, and it always resolves the same open question first: is this real, and is it reachable.

Findings that pile up unreviewed are also where a dedicated triage layer earns its place: a platform like DefectDojo ingests output from every scanner in the pipeline — SAST, SCA, DAST, secrets — dedupes overlapping findings, and carries a false-positive marking forward across re-scans so the same triage decision doesn't have to be made twice. See Vulnerability Management & Triage for how that aggregation scales past a single repo.

Worked example: from a SpotBugs finding to a shipped fix

☺ Like you're 10: Read the scanner's message, find the exact spot where untrusted data meets a dangerous function, patch that exact spot, then run the scanner again to prove it's actually gone.

Here's the full loop the exam wants you to be able to run without hesitating. A merge-blocking FindSecBugs check fails on a Java servlet:

$ mvn com.github.spotbugs:spotbugs-maven-plugin:check

[ERROR] Bug type:    SQL_INJECTION_JDBC
[ERROR] Priority:    High     Confidence: Medium     CWE: 89
[ERROR] Class:       com.acme.orders.OrderLookupServlet
[ERROR] Method:      doGet(HttpServletRequest, HttpServletResponse)
[ERROR] Line:        47
[ERROR] A prepared statement is generated from a nonconstant String;
[ERROR] if this string is externally influenced, this may be SQL injection.
[ERROR]
[ERROR] BUILD FAILURE — 1 High-priority security finding, merge blocked

Step 1 — read the finding, don't just read the message. The bug type SQL_INJECTION_JDBC and CWE-89 tell you the category before you've even opened the file: this is FindSecBugs's SQL injection detector, which means its dataflow engine already traced a specific source-to-sink path — it doesn't fire on vague suspicion.

Step 2 — open line 47 and trace the same path by hand. This is the part triage actually consists of:

// BEFORE — OrderLookupServlet.java, lines 44-49
// FindSecBugs's taint trace: getParameter() is a declared source,
// executeQuery() is a declared sink, and nothing in between neutralizes
// the value — string concatenation only, no bind variable.
String customerId = request.getParameter("customerId");     // source
String sql = "SELECT * FROM orders WHERE customer_id = '"
           + customerId + "'";                              // taint flows in, unsanitized
ResultSet rs = statement.executeQuery(sql);                  // sink

// AFTER — the value is bound as a parameter, never concatenated into
// the SQL text itself; the driver escapes it before it ever reaches the DB
String customerId = request.getParameter("customerId");
String sql = "SELECT * FROM orders WHERE customer_id = ?";
PreparedStatement ps = connection.prepareStatement(sql);
ps.setString(1, customerId);                                 // driver-escaped, not concatenated
ResultSet rs = ps.executeQuery();

Step 3 — confirm it's real, not a false positive. doGet handles an unauthenticated servlet endpoint, customerId comes straight from a query parameter with no allow-list validation anywhere upstream, and the concatenation reaches executeQuery directly. Real, reachable, no sanitizer — the "YES" branch of the triage flow above, so this gets fixed now, not ticketed.

Step 4 — apply the fix and re-run locally before pushing. PreparedStatement is a sanitizer boundary FindSecBugs recognizes explicitly — the driver, not string concatenation, is what places the value into the query, so the taint path FindSecBugs was tracing no longer exists. Re-running spotbugs:check reports zero SQL_INJECTION_JDBC findings, and the merge gate goes green.

The same finding in Python wears different vocabulary but is the identical bug. Bandit's check B608 (hardcoded_sql_expressions) flags an f-string or %-formatted string handed to cursor.execute(), and its report looks like >> Issue: [B608:hardcoded_sql_expressions] Possible SQL injection vector through string-based query construction. Severity: Medium Confidence: Medium. The fix is the same parameterized-query pattern, just spelled cursor.execute(query, (customer_id,)) instead of a PreparedStatement. CWE-89 and its remediation are language-independent; only the detector name and the syntax change.

Secrets detection: pattern, entropy, and live verification

☺ Like you're 10: A secrets scanner doesn't understand your code at all — it just checks whether a piece of text looks like a real password, and then, when it can, actually asks the real service if that password still works.

A secrets scanner has no source, sink, or sanitizer to reason about. It works two ways instead, usually combined: signature matching against known credential shapes (an AWS access key always starts AKIA, a GitHub personal access token starts ghp_, a Stripe live key starts sk_live_, a PEM-encoded private key starts with a recognizable header line), and entropy scoring — a generic-looking 40-character random string with no known prefix still has high Shannon entropy, which is what a signature match alone would miss entirely.

The tool the curriculum leans on hardest for the second half of this chapter is TruffleHog, specifically because of what happens after a match: for many well-known secret types, TruffleHog makes a live, read-only API call against the actual vendor — AWS's sts:GetCallerIdentity, a scoped GitHub API check — and splits its output into Verified and Unverified results. A verified hit isn't "a string that looks like a credential"; it's confirmation that a real, currently-active credential is sitting in the repository right now. That single distinction is what makes secrets triage faster and more decisive than SAST triage: there's no reachability analysis to argue about, because the tool already asked the credential itself. TruffleHog also defaults to scanning the entire git history — every commit, every branch — not just the current diff, which is why it's commonly run both as a CI gate on new commits and as a standalone deep scan when onboarding a legacy repository that's never been checked before.

Gitleaks takes a different position in the same pipeline: it's fast, config-driven (a TOML rule file), and doesn't perform live verification by default — which is exactly why it's the tool teams reach for as the pre-commit and CI diff-scanning layer, catching a leak in milliseconds before it's even verified, with TruffleHog's slower, verified deep scan running as a second layer against full history. Tuning a secrets scanner looks nothing like tuning a SAST rule, because a false positive here is almost never "the logic doesn't actually reach a dangerous state" — it's "this is an obviously fake key in a test fixture or a documentation example." The right fix is an explicit allowlist, not a severity threshold:

# .gitleaks.toml — remove a real false-positive source, not the detection itself
[[rules]]
id = "generic-api-key"
regex = '''(?i)(api[_-]?key)["']?\s*[:=]\s*["'][0-9a-zA-Z]{32,}["']'''

[allowlist]
description = "Fixtures and docs use obviously-fake keys, never live secrets"
paths = [
  '''test/fixtures/.*''',
  '''docs/examples/.*'''
]
regexes = [
  '''sk_test_FAKEKEYFORDOCSONLY[0-9a-zA-Z]*'''
]

Notice what that config does not do — it doesn't lower a severity threshold or narrow the detection pattern itself the way a SAST rule tune might. It carves out two specific, reviewed paths and one specific, obviously-fake string. Detection stays exactly as sensitive everywhere else in the repository.

Worked example: a verified secret in CI

☺ Like you're 10: When the scanner confirms the password still works, you don't debate it — you go change the password first, and clean up the old commits second.

A pull request trips a TruffleHog CI gate:

$ trufflehog git file://. --since-commit main --only-verified

✅ Found verified result 🔑
Detector Type: AWS
Decoder Type:  PLAIN
Raw result:    AKIAABCDEFGHIJKLMNOP...
Commit:        a1c9e2f (42 commits back, branch: feature/reporting-export)
File:          scripts/export_to_s3.py
Line:          18
Verified with: sts:GetCallerIdentity → arn:aws:iam::482910XXXXXX:user/reporting-export

The correct response sequence, in order, and why the order matters:

1. Treat it as compromised the instant "Verified" appears. There's no triage question to resolve first — sts:GetCallerIdentity already proved this is a real, currently-usable AWS credential, not a string that resembles one.
2. Rotate it at the source immediately — deactivate the IAM key and issue a replacement — before touching git at all. The exposure window is bounded by how fast this step happens, not by how fast the branch gets cleaned up.
3. Only then clean the git history if policy requires it (git filter-repo, BFG). This step tidies the record; it does not undo the exposure — anyone who already cloned the branch had the old key regardless of what history looks like afterward.
4. Re-run the scanner against full history to confirm no other verified hits remain, then merge. A single verified finding is rarely the only one in a branch that's been open for 42 commits.

Compare that sequence to how the SpotBugs example resolved: there, the fix (a code change) came first and the re-scan came second, full stop. Here, the fix (a credential rotation, entirely outside the codebase) comes first, and the git and re-scan steps are cleanup that follows it. Same three-step shape — confirm, fix, verify — completely different definition of "fix."

Common exam traps

☺ Like you're 10: Most of the wrong answers on this chapter come from treating the two scanners as interchangeable, or treating a quiet gate as a clean one.

• Ranking a verified secret by severity instead of acting on it immediately. The exam wants "rotate now" as the first action on a verified hit, not "file it as High and prioritize next sprint" the way a SAST finding might legitimately be handled.
• Believing .gitignore protects a file that's already been committed. It only stops future additions. A secret committed before the ignore rule existed is still in history and needs a history scan (trufflehog git file://. --since-commit <first-commit> or a full unscoped run), not a .gitignore entry, to surface it.
• Treating a suppression as a resolution. A # nosec or // NOSONAR with no linked justification is a silent, permanent hole in the gate. It's also a compliance gap, not just a security one — see Compliance as Code at Scale for how an auditor expects that trail to look.
• Assuming "SpotBugs" alone catches security bugs. Vanilla SpotBugs ships general bug-pattern detectors, not security ones — the security detector catalog comes from the FindSecBugs plugin layered on top, and a Java pipeline that runs SpotBugs without FindSecBugs is not doing SAST at all, whatever the CI log implies.
• Running only diff-based secrets scanning and assuming the repo is clean. A diff scan only ever sees what changed since the base branch. A secret committed years before scanning was ever turned on stays invisible until someone runs a deliberate full-history pass.
• Over-tuning a SAST rule into silence. Disabling an entire rule category because of one noisy false positive is how the real SQL injection two months later goes uncaught. Narrow the rule's pattern or scope — as in the custom Semgrep example above — don't turn it off.

Two chapters bracket this one. If the gate vocabulary — sources, sinks, quality gates, blocking versus advisory checks — felt unfamiliar, back up to DevOps Foundations & the CDP Toolchain and Secure SDLC Gates & the DevSecOps Maturity Model first. From here, Software Composition Analysis in Depth covers the majority of a codebase that neither of today's scanners ever looks at — the dependencies — and Dynamic Analysis in Practice picks up everything invisible until the application is actually running. For the hands-on version of everything above, Part 2 of the capstone wires both scanners into a real pipeline, and the leaked credential triage drill is a timed run of the TruffleHog scenario in this chapter.