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 each of the book's concepts and pairing it with the hands-on labs that live alongside the book, then writing up what that 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, response, the automation that ties a SOC together, and last time the innermost ring of identity and encryption — the controls that still mean something after everything else has fallen.
This installment does something different. It stops climbing rings entirely and looks down at the ground all of them are standing on.
There's a line I come back to whenever someone wants to talk about their shiny new detection stack: the most sophisticated control in the world is worthless if it's running on a host with a default password and a three-year-old kernel. Every domain we've covered so far quietly assumed the architecture underneath it was fundamentally sound and asked how to defend it. This domain confronts the uncomfortable truth that the architecture is never fundamentally sound. Every system carries latent weaknesses — unpatched software, misconfigurations, default credentials, settings that have silently drifted away from where you left them — and new weaknesses are disclosed faster than any team can close them.
Two questions sit underneath all of it. What is wrong with the systems I already have — and how do I make them right and keep them that way. Vulnerability management answers the first. Configuration management answers the second. The first is detective; the second is preventive. Run together, they form the continuous hygiene loop the Center for Internet Security ranks among the most impactful controls an organization can implement — the unglamorous, never-finished work that determines whether any of the more sophisticated controls ever get a chance to function.
That's the domain at the heart of Vulnerability and Configuration Management — and it's where the companion labs do some of their most honest work.
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.
The printed second edition runs to nearly 700 pages. That's the framework: how to think about vulnerability and configuration management as a continuous program rather than a quarterly fire drill, why the scan is only the engine and not the discipline, and how the detective and preventive halves fit into a coherent whole.
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. For this domain alone, that means standing up a real vulnerability scanner, hardening a host with code and watching it heal itself, and running a Windows patch-distribution server through its full lifecycle.
Concepts you can read about in an afternoon. Muscle memory you can only build by typing the commands and watching the system push back.
What the Labs Actually Build
The labs in this domain are deliberately sequenced into a single scan-harden-patch-verify loop, but each stands on its own if you only need one piece.
Greenbone / OpenVAS — finding what's wrong. The first lab deploys the Greenbone Community Edition as a Docker stack on Debian 13, synchronizes the vulnerability feeds, defines a scan target, and runs both authenticated and unauthenticated scans against a deliberately under-patched VM. You interpret the CVSS-scored findings, export a report for the people who actually have to fix things, remediate, and rescan to prove you closed the gap. Here's the point I want every reader to internalize: OpenVAS was forked from the last open-source release of Nessus, which makes it the literal architectural ancestor of Tenable, Qualys, and Rapid7. The target/credential/task/report cycle and the CVSS prioritization you just practiced are identical in all three. The console changes. The discipline does not. (There's a second build of the same lab on Kali for anyone who wants a single, portable, multifunction box instead of a separate scanner host.)
Ansible — making systems right, and keeping them that way. The second lab stands up a control node and a managed node, establishes key-based SSH, and applies a real hardening playbook — firewall on, root SSH login off, password authentication disabled, automatic security updates in place. Then comes the part that teaches the actual lesson: you run it twice to prove idempotence, deliberately drift the configuration by hand, and watch Ansible detect and correct the drift automatically. That self-healing behavior is configuration management; everything else is commentary. The playbook you write here is the same artifact a platform team commits to Git and runs through Red Hat's commercial Ansible Automation Platform — inventory, idempotence, and roles are identical.
WSUS — the approval gate. The third lab installs the Windows Server Update Services role on Windows Server 2025, synchronizes from Microsoft Update, points a client at it through Group Policy, and approves and deploys an update through a computer group. Yes, WSUS is deprecated — and the lab says so plainly. You learn it anyway, because the durable concepts (a managed update catalog, an approval gate, targeted deployment rings) are exactly what Windows Autopatch, Intune, and Azure Update Manager automate. WSUS just exposes those concepts most plainly.
OpenSCAP — where the two halves become one. The final lab is the one that ties the whole domain together on a single host. OpenSCAP is both an Authenticated Configuration Scanner (it evaluates XCCDF profiles — CIS Benchmarks, DISA STIGs, ANSSI, PCI-DSS) and an Authenticated Vulnerability Scanner (it evaluates OVAL definitions against your installed packages to surface CVEs). One tool, one content standard, both the preventive and detective sides of this domain meeting on the same machine. Better still, it can emit an Ansible remediation playbook straight from its findings — which feeds directly back into the Ansible lab and closes the scan-to-harden loop entirely with open-source tooling.
The Architect's-Eye Throughline
What I wanted these labs to teach isn't "how to run Greenbone" or "how to write a playbook." 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:
You cannot fix what you cannot see. Vulnerability management is the detective half, and it only works if scanning is continuous rather than a one-time snapshot. The Greenbone lab is the CVE-and-CVSS vocabulary, the authenticated-scan technique, and the scan-remediate-rescan loop made tangible — the exact workflow every commercial scanner runs.
Drift is the enemy, and code is the answer. Configuration management declares the hardened, known-good state as code and corrects deviation automatically, against the constant entropy of manual changes. The Ansible lab is that idea you can hold in your hand: write the baseline once, enforce it everywhere, let the engine quietly repair anything that drifts.
Closing the loop is the whole job. Finding a weakness is half the work; closing it and keeping it closed is the other half. WSUS gives you the catalog-approve-deploy gate; OpenSCAP measures you against a recognized benchmark and the current CVE list at the same time. Together they turn "we ran a scan once" into a program.
Every one of these maps directly onto the enterprise. OpenVAS's NVT model is the architectural ancestor of Tenable and Qualys. Your Ansible playbook is what Red Hat's commercial platform runs at scale, and the same declarative model underlies Puppet and Chef. WSUS's workflow transfers straight to its cloud successors. And the XCCDF and OVAL content OpenSCAP consumes is the very same standardized content ingested by Red Hat Insights and Satellite, by Tenable, and by Qualys Policy Compliance. You learn the discipline on tooling you can run for free, and you carry that fluency into whatever your organization standardized on.
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" and Windows Server 2025 hosts: the patience the first Greenbone feed sync demands before a scan returns anything meaningful, the nginx binding you flip to 0.0.0.0 to reach the console from your LAN, the SCAP Security Guide datastream that still targets an earlier Debian than Trixie and runs anyway, the libopenscap25 library that replaced the libopenscap8 older guides reference, and the OpenSCAP exit code 2 that means "scan succeeded, findings present" rather than "tool broke." When something breaks in the real environment, the lab tells you so and tells you why. 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 run the full loop — find the weaknesses with Greenbone, enforce a hardened baseline with Ansible, manage patching with WSUS, and watch both halves of the domain meet on one host with OpenSCAP — 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 break it in an interesting way — I'd genuinely like to hear about it. You can find me at secdoc.tech. The series continues with the next domain soon.
