Expert Briefing: Building an Exposure-Led Security Program

A briefing on moving from counting vulnerabilities to prioritizing and closing real exposure.

Briefing at a glance	Details
Focus	Moving from counting vulnerabilities to prioritizing and closing real exposure
Audience	CISOs and security leaders, vulnerability and exposure management teams, infrastructure and application owners, risk and audit stakeholders
Scope	Cross-industry / Enterprise

About this briefing

A scan returns a very large list of open findings. The dashboard sorts it by severity, the remediation queue grows, and the number reported upward goes in whichever direction the last patch cycle pushed it. Meanwhile the flaw that matters is a medium-rated issue on an appliance facing the internet, and it is sitting in the middle of the list.

Exploitation of vulnerabilities is where a large share of intrusions begin. Mandiant’s latest M-Trends report puts exploits at 32% of initial infection vectors, the most common for the sixth consecutive year. Verizon’s latest Data Breach Investigations Report puts vulnerability exploitation at 31% of initial access, ahead of stolen credentials. Two independent datasets, built differently, point the same way. The question for a program is no longer whether to manage vulnerabilities. It is whether the work is aimed at what attackers can actually reach and use.

This briefing sets out what an exposure-led program decides, what evidence feeds each decision, and how to show leadership that exposure is falling rather than that tickets are closing.

What you will leave with

A working definition of exposure that your teams and your board can both use

The five questions every prioritization decision should answer, and the evidence behind each

How KEV, EPSS and SSVC fit together, and where each one stops

A short set of measures that show whether risk is going down

Briefing flow

Segment	Focus	Question it answers
1	Why counts and scores mislead	What does a severity-sorted list leave out?
2	What an exposure decision needs	Which evidence turns a finding into a decision?
3	Three findings, three decisions	How does the ranking change when exposure leads?
4	Building the program	What has to exist for prioritization to matter?
5	Measures that show progress	How do we know exposure is falling?
6	Where programs stall	Why do good ranking models still fail?

Why counts and scores mislead

The Common Vulnerability Scoring System was built to describe how severe a vulnerability is. Its own user guide says Base scores are designed to measure severity and should not be used alone to assess risk, and that they should be supplemented with an analysis of the environment and with attributes that change over time. A critical score tells you what could happen if the flaw is exploited. It does not tell you whether anyone is exploiting it, whether it can be reached, or what it sits on.

A raw count adds a second problem. It blends findings that are exploitable today with findings that will never matter, and it moves with scanner coverage and patch cycles as much as with risk. A count that falls because a scanner lost access to a network segment looks like progress. A count that rises because discovery improved looks like failure.

What an exposure decision needs

Our working definition: an exposure is a weakness that an attacker can reach, that can be exploited, that sits somewhere that matters, and that has no effective control in front of it. Each clause corresponds to a question, and each question has evidence behind it.

Question	Evidence	Limit to keep in mind
Is it being exploited?	CISA’s Known Exploited Vulnerabilities (KEV) catalog. Entries need an assigned CVE, reliable evidence of exploitation in the wild, and clear remediation guidance.	A floor, not a ceiling. A vulnerability can be dangerous and absent from KEV because it has not met all three criteria.
How likely is exploitation soon?	EPSS, which estimates the probability that exploitation activity will be observed in the next 30 days	It predicts activity, not success, and says nothing about impact. FIRST publishes no universal threshold, so the cutoff is your decision.
Can an attacker reach it?	External attack surface discovery, network paths, authentication requirements	Only as good as the asset inventory. Assets nobody registered are the ones discovery has to find.
What does it sit on?	Asset criticality, data held, identity privileges, business dependency	Needs business input. It is the step most often skipped.
What stands in front of it?	Segmentation, filtering, endpoint controls, configuration	Compensating controls have to be verified. Assumed controls are the common failure.

CISA’s Stakeholder-Specific Vulnerability Categorization (SSVC) turns inputs like these into a decision with an owner. It uses decision points such as exploitation status, technical impact, whether exploitation is automatable, mission prevalence and public well-being impact, and it ends in four outcomes: Track, Track*, Attend and Act. The outcomes matter more than the scores. Act means leadership attention and the fastest feasible remediation. Track means normal patch cycles. CISA recommends that organizations outside the federal civilian agencies treat KEV as a priority in their vulnerability management plans and use it as an input to frameworks like SSVC.

Three findings, three decisions

The following is an illustration, not data. It shows how the ranking moves when exposure leads.

Finding	Severity-sorted view	Exposure view	Decision
A. Critical-rated flaw on an internal test server. Not in KEV, low EPSS, isolated segment.	Top of the queue	No evidence of exploitation, not reachable, low business value	Track. Fix in the normal cycle.
B. Medium-rated flaw in an internet-facing VPN appliance. Listed in KEV.	Middle of the queue	Actively exploited, reachable by anyone, and a gateway to the internal network	Act. Patch or mitigate immediately, then check for signs of prior compromise.
C. High-rated flaw in a library used by an internal batch job that handles finance data. No known exploitation, authenticated access required.	Upper queue	Not exploited yet, reachable only after other access, but the data is valuable	Attend. Schedule within a defined window, and review who can reach the job.

The order flips: B first, then C, then A. Nothing about the scanner changed. The questions asked of each finding did.

Building the program

Ranking is the visible part. Five things sit underneath it, and a program that skips one tends to stall there.

1. Assets and owners. Prioritization needs an inventory that includes what nobody registered, which is why external attack surface discovery belongs in the program rather than beside it. Every internet-facing asset needs an owner who can change it.

2. One record per exposure. Scanners, cloud posture tools, penetration tests and threat intelligence each describe the same weakness differently. Without deduplication, the queue measures how many tools you own.

3. Written decision rules. For example, exploited and reachable means Act. The thresholds and time targets are choices for the organization to make and defend. What matters is that they exist before the next urgent advisory.

4. Remediation capacity. Ranking is useless if the teams that change systems cannot absorb the work. Remediation is an engineering throughput problem. Mitigation, such as disabling a feature or restricting access, is a legitimate way to close an exposure when patching has to wait, as long as it is recorded and revisited.

5. Verification. Closing a ticket does not prove the exposure is gone. Re-test, and let exceptions expire with a named owner.

Measures that show progress

Counts still have operational uses. They are a poor headline. These measures tell leadership more:

Measure	What it shows	Watch for
Time to remediate exposures that are exploited and reachable	How fast the highest-risk items close	The slowest items matter more than the median. Report the tail.
Share of internet-facing assets with a named owner	Whether findings have somewhere to go	Ownership recorded in a spreadsheet nobody maintains
Asset coverage and new-asset discovery rate	How much of the estate the program can see	A rising discovery rate can mean a better program, not a worse one. Explain it before it is misread.
Open exceptions, their age and expired count	Accepted risk and how long it has been carried	Exceptions that renew automatically
Share of fixes that fail verification	Quality of remediation	Closing on patch deployment without re-testing

Where programs stall

Treating KEV as the whole list. The catalog is an excellent starting filter. It is also a lagging one, so a program built only on KEV waits for the evidence that others have already been hit.

Ranking without capacity. A beautifully prioritized list that the infrastructure team cannot act on produces the same backlog with better labels.

Skipping business context. Technical teams can rank by exploitability. Only the business can say which systems it cannot do without, and that conversation tends to be postponed.

Findings thrown over the wall. An exposure with no owner and no deadline is a report, not a program.

Questions on the table

How do we set an EPSS or severity threshold we can defend to audit and the board?

Who decides the business criticality of an asset, and how often is it revisited?

How should exposure management work with cyber risk assessments?

How do we handle exposures we cannot patch, such as end-of-life systems?

What do we report when the discovery of new assets makes the numbers look worse?

What to do next

1. List your internet-facing assets from outside your own inventory, and compare. Every gap is an ownership question.

2. Cross-check your current backlog against KEV and sort the matches to the top. It needs no new tooling.

3. Write down the decision rules in one page: what combination of evidence means Act, Attend or Track, and the time target for each.

4. Choose three measures from the table above, replace the open-findings count on the leadership report, and explain the change once.

5. Find the exposures that no one can patch, and decide on a mitigation and a review date for each.

Putting this to work

Cybrilliant’s Vulnerability & Exposure Management service is built around this approach, and it connects to External Attack Surface Management, Security Remediation and Cyber Risk Assessments for teams that need support on discovery, delivery or risk context.

Sources

1. FIRST, Common Vulnerability Scoring System v4.0 User Guide. Forum of Incident Response and Security Teams.

2. CISA, Known Exploited Vulnerabilities Catalog and the binding operational directive on reducing the risk of known exploited vulnerabilities. Cybersecurity and Infrastructure Security Agency.

3. FIRST, Exploit Prediction Scoring System (EPSS) model documentation. Forum of Incident Response and Security Teams.

4. CISA, Stakeholder-Specific Vulnerability Categorization (SSVC). Cybersecurity and Infrastructure Security Agency.

5. Google Cloud, M-Trends report (latest edition). Mandiant / Google Threat Intelligence Group.

6. Verizon Business, Data Breach Investigations Report (latest edition). Verizon.