Part of an ongoing series walking domain by domain through the Cybersecurity Architect's Handbook, Second Edition — and the companion labs that ship with it.
If you've been following along, you know the rhythm by now. I've been working through the second edition of the Cybersecurity Architect's Handbook's "secret menu" one domain at a time — taking the book's concepts and pairing them with the hands-on labs that live alongside it, then writing up what each domain is really trying to teach once you stop reading and start typing commands. We've climbed through the rings of the architecture: detection, prevention, monitoring, the automation that ties a SOC together, the innermost ring of identity and encryption, the vulnerability and configuration management hygiene that the fancier controls all quietly depend on, and last time the morning after the bad day arrives — incident response and the forensic discipline underneath it.
Every one of those domains had something in common, even the ones that reached upstream into hygiene: they all deal with systems that are already running. Hosts you've deployed. A network you're watching. A SOC you're operating. An intrusion you're chasing. This installment goes further upstream than any of them. It steps back to the code itself — before there's a host to harden or an alert to triage — and asks how you find the flaw while it's still cheap to fix and nobody has shipped it yet.
That's the domain at the heart of Application Security Testing. The controls in every domain we've covered so far protect the infrastructure that software runs on. This one protects the software itself — and in a world of cloud services and APIs, the application is increasingly the entire attack surface that matters. The mature move is to stop treating security testing as a final gate before release and shift it left, out of a pre-release checkpoint and into the developer's editor, the pull request, and the CI/CD pipeline.
And here is the conceptual heart of the domain, the thing the labs exist to make you feel rather than read: no single testing technique sees the whole picture. A static analyzer reads code it cannot run. A dynamic scanner attacks a running application it cannot read. A human with an intercepting proxy finds the logic flaws automation never trips. A secrets scanner finds the exposures that aren't code flaws at all. Each catches what the others miss — and the companion labs put every one of those lenses in your hands against the same vulnerable application, so the complementarity stops being a diagram and becomes something you watch happen.
Two Books, One Cover Price
For anyone joining the series here, the same thing is true of this domain as every other one I've covered: the book is only half of what you get.
he printed second edition runs to nearly 700 pages, providing concepts and frameworks that a cybersecurity architect will need to understand and address. That's the framework.
But the companion GitHub repository carries another 700-plus pages of step-by-step, build-it-yourself lab content — material that never had to fit inside a print binding and so could go as deep as the hands-on work demanded. The SAST / DAST / IAST / SCA taxonomy and where each technique fits, why the OWASP Top Ten has organized this field since 2003, and the reason these techniques are complementary rather than redundant — the single most important idea in the domain and the one every architect eventually learns the hard way. For this domain alone, that means standing up a code scanner and reading a vulnerability back to the exact line that caused it, attacking a live web app from the outside the way an attacker would, pausing and rewriting a request mid-flight by hand, and pulling a forgotten credential out of a repository's git history long after the file that held it was "deleted."
Concepts you can read about in an afternoon. The instinct for which lens to reach for, and when, you can only build by running all four against the same target and watching each one surface what the others can't.
What the Labs Actually Build
The labs in this domain are deliberately sequenced to walk the full set of testing techniques — from source code that never runs, to a running application probed from the outside, to the manual craft a human brings, to a class of exposure that lives in none of the code at all — but each stands on its own if you only need one piece.
SonarQube — reading the code it cannot run. The first lab stands up SonarQube Community Build on a fresh Debian 13 host with Docker, creates a project and an analysis token, and runs the scanner over a deliberately vulnerable application. The payoff isn't the list of findings — it's learning how SAST reasons about code paths, why it produces false positives where it can't prove a flow is safe, and how to triage findings through the quality-gate model. Here's the point I want every reader to internalize: that quality gate is the same control mechanism Veracode, Checkmarx, and GitHub Advanced Security enforce commercially. The policy changes between tools. The concept does not.
OWASP ZAP — attacking the app it cannot read. The second lab points OWASP ZAP — the world's most widely used open-source web-application scanner — at a running, deliberately vulnerable target and lets it spider, passively observe, and actively attack. Then it switches from the automated scan to ZAP's intercepting proxy: pausing a live request mid-flight, editing a price or a user ID before it reaches the server, and watching the application respond to input it never expected. Run it against the same target you scanned with SonarQube and the complementarity stops being theoretical — where SAST pointed at a line of code, DAST shows you the working attack. The intercepting-proxy workflow you learn here is identical in concept to Burp Suite's, so the skill transfers straight to the tool most professional testers eventually adopt.
Burp Suite Community — the manual craft. The third lab is about depth rather than breadth. Burp Suite is the de facto standard for professional web penetration testing, and Community Edition includes exactly the tools that matter for learning the manual tradecraft: the intercepting proxy, the pre-configured embedded browser, Repeater, and Intruder. Repeater is the heart of it — taking one request and reasoning about it payload by payload is how the vulnerabilities automated scanners miss (broken access control, business-logic flaws, the subtle injection that only fires in a specific sequence) get confirmed by a human who understands what the application is supposed to do. Doing the same intercepting-proxy work in both ZAP and Burp proves how directly the skill transfers between the two leading tools; Professional simply removes the throttle and adds the automated scanner, Collaborator, and saved projects.
TruffleHog — the flaw that isn't in the code. The fourth lab attacks a different class of exposure altogether — not a flaw in the code, but a secret accidentally left inside it. Using TruffleHog, you scan a known-vulnerable test repository to validate the install, then build your own repo, commit a fake-but-realistic AWS key, "fix" the mistake by removing it in a later commit, and prove that the secret is still there in the git history. A filesystem scan of the working tree comes back clean; the history scan surfaces the credential anyway. That single comparison is the most important lesson in the lab, and it's why TruffleHog's two defining capabilities — deep history scanning and live verification against the provider's API — are what the commercial platforms (GitGuardian, GitHub Advanced Security, Gitleaks) are built around too.
The Architect's-Eye Throughline
What I wanted these labs to teach isn't "how to run SonarQube" or "how to drive Burp's Repeater." Tools change. The patterns underneath them don't — and if you've read the earlier posts in this series, you'll recognize the move, because it's the same one every domain rewards.
No single lens sees the whole application. This is the domain's version of the lesson the incident-response post landed on — that the analyst who has sat in every seat of the SOC understands the whole response. Here it's every lens on the same code: static for the source, dynamic for the runtime, manual for the logic, secrets scanning for what got left behind. Run all four against one target and the complementarity is no longer something you take on faith.
The clean surface is lying to you. Readers of the forensics post will feel the echo. The carving lab taught that a clean-looking disk doesn't mean the data is gone — the bytes are usually still sitting in unallocated space, and the skill is knowing how to bound them. The TruffleHog lab teaches the exact same instinct one layer up: a clean working tree means nothing if the git history is dirty, and "we removed it from the code" is never remediation. The secret is still recoverable, so the only real fix is rotation — revoke and reissue, never merely delete. Distrust the tool's first answer; go verify against the full record.
A finding is a hypothesis, not a verdict. SAST flags a pattern it can't prove is reachable, which is why triage exists. DAST answers the question by sending the actual payload and showing you the response — the working attack as proof. TruffleHog's live verification separates an active, exploitable credential demanding immediate rotation from a lead that couldn't be confirmed. Every one of these labs trains you to chase a claim down to evidence before you act on it.
The payoff is the one the domain overview names directly. The practitioner who has run all four understands what a mature program actually assembles: SAST and SCA embedded in the pull-request gate, DAST run against staging builds in the pipeline, secrets scanning at commit time and in CI, and manual penetration testing reserved for what automation can't replicate. These labs map cleanly onto every part of that — SonarQube onto the commercial SAST platforms, ZAP onto Burp Professional and Invicti, Burp Community onto the manual craft those tools sell faster and better-supported, TruffleHog onto the enterprise secret-scanning suites. You learn the discipline on tooling you can run for free, and you carry that fluency into whatever your organization standardized on. You cannot design an application-security program you have never operated.
Tested on Real Infrastructure
These aren't aspirational walkthroughs — and that, too, has been the through-line of this whole series. Every step was executed on actual Debian 13 "Trixie" hosts and live container stacks, and the lab tells you when something breaks and why. SonarQube bundles Elasticsearch and will start and then die within a minute, complaining about max virtual memory areas, unless you raise vm.max_map_count before launching the container — the single most common first-install failure, handled up front. ZAP on a Debian 13 desktop wants the official cross-platform installer and a JRE rather than the apt package, and on Gnome or Cinnamon you run that installer as root to get a working launch. Burp's embedded browser won't start under Debian 13's sandbox until you explicitly allow it to run without one — a setting toggle, not a mystery. TruffleHog needs --no-update on every invocation in a controlled lab so it doesn't reach out mid-scan. And the whole secrets lesson rests on running the filesystem scan and the git scan back to back and seeing them disagree. Even the target has its teeth: OWASP Juice Shop ships no obvious default admin login — the credentials are hidden, which is the point of using a real intentionally-vulnerable app instead of a clean demo.
That's the difference between reading about a control and being able to defend it in a design review.
Put Your Hands On It
If you want to actually walk the full set — read a vulnerability back to the exact line with SonarQube, watch ZAP turn a scan finding into a working attack, rewrite a live request by hand in Burp's Repeater, and pull a "deleted" credential back out of git history with TruffleHog — that's all waiting in the lab repository, the 700-plus pages that ship alongside the book.
Grab the Cybersecurity Architect's Handbook, Second Edition here: Amazon
And if you build something with these labs — or find a flaw I didn't — I'd genuinely like to hear about it. You can find me at secdoc.tech. The series continues with the next domain soon.
