This series takes the vulnerability management program built on security brutalism and survivability engineering and turns it into a working plan. It covers the order of setup, the categories of tooling involved, who owns each piece, and where developers and IT tend to push back, along with how to work through that friction.

There is not one size fits all here, so I tried to stay generic so a team reading this should come away able to open a project tracker and start assigning tasks.

Two rules need to be followed for every part of the series, 1) everything gets recorded somewhere the whole team can reach, never held in one person's head, since a security control that only one engineer understands disappears the day that engineer leaves. And 2) anything tagged existential gets fixed on a set, fast timeline, with no case by case negotiation. Outside that tier, security and the system owner work out timing together, and security's role stays calling out the risk clearly rather than dictating someone else's schedule.

Remember, security calls out the risk; it does not own it.

Reachability

A security team cannot judge urgency on a vulnerability without knowing two things about the system carrying it. What can reach that system from outside, and what that system can reach if someone gets inside it. Building an answer to both questions is the most important thing you need to do first, and it has to exist before any scoring can happen with real weight behind it.

Start by choosing one place for this record to live, maybe a configuration management database, if the organization already runs one, or a structured, shared record with fixed fields if it does not. The tool chosen is less important than the discipline of keeping one authoritative copy instead of letting three teams each keep their own version that drifts apart within a month. Once that record exists, pull real configuration data into it instead of filling it in from what people remember. Cloud provider consoles expose security groups, routing tables, and identity policies through an interface built for exactly this kind of export. Firewall management systems expose rule sets the same way. Pull from both sources on a recurring schedule, so the record reflects the configuration running today rather than the configuration someone set up eight months ago and never revisited.

With that data flowing in, run two forms of analysis against it. An external exposure scan checks public addresses and domain records against what should really sit open to the internet, and it tends to turn up things nobody expected like a staging environment someone spun up for a demo and never tore down, or a subdomain with no owner. An internal path analysis, built from the routing and firewall data already collected, traces what a system could reach if an attacker landed inside, which is how a system with no public exposure at all still turns out to sit one hop from a critical database. Attach both results to the asset record for good, so a new finding against that system carries its reachability status the instant it appears instead of forcing a fresh investigation every single time.

There are two things that tend to derail this part. Platform and infrastructure teams often push back on granting a scanning process broad read access to firewall and cloud configuration, wary of handing another system standing credentials into sensitive infrastructure. Ask for scoped, read only access to address that concern, since the process never needs write permission to complete this work and logging every query it runs gives the infrastructure team an audit trail they can inspect whenever they choose. Both sides win. The second failure shows up later, once the map that was accurate at launch has gone stale because nobody tied its upkeep to anything that happens naturally. Attach the update to a step that already exists in the normal flow of work, like a deployment pipeline stage or a required field on a firewall change request, so the record stays current as a side effect of work already underway. You can use an AI model or any other form of automation here to help monitor and update the data as changes happen.

Getting this part right will take a little bit, but it's key to the rest of the process. A vulnerability that lands on a system with an accurate, current reachability record gets triaged against real exposure instead of a guess, and that accuracy is the difference between a program that catches the finding that may cripple the business and one that drowns in findings that never posed a real threat to begin with. Once the reachability record exists and updates on its own, the next step is confirming which of the vulnerabilities sitting against these systems are even present in the code the application runs.

Go to Part 2: Susceptibility.