Mostafa Negm
Selected work

CASE-01 / Framework

Threat-informed vulnerability prioritization framework

A scoring model that ranks findings by exposure, exploitation evidence and business criticality, so remediation effort goes where the risk is instead of where the CVSS score is highest.

Focus
Threat-informed prioritizationExposure managementRisk management
Tools and sources
CISA KEVEPSSTenableQualysWizPythonNIST CSF

The problem

CVSS measures how bad a vulnerability could be in the abstract. It does not know whether the affected system is reachable from the internet, whether anyone is exploiting the flaw right now, or whether the asset runs payroll or a test lab.

Sort a queue by CVSS alone and you get a long list of "criticals" that engineers learn to ignore, while a medium-severity bug on an exposed edge device that is being exploited this week sits in the middle of the pile. The scanner is doing its job. The ranking is the problem.

What I did

I built a prioritization model that scores each validated finding on three axes and lets the combination, not the base score, set the remediation tier.

  • Exposure. Is the asset internet-facing, reachable from a partner network, or internal only? Exposure comes from asset inventory and cloud posture data (Wiz, AWS, Azure), not from the scanner's guess.
  • Exploitability. Is the CVE in CISA's Known Exploited Vulnerabilities catalog? Is there a public exploit? Where there is no KEV listing yet, EPSS adds a probability of exploitation. CVSS still lives here, as the technical severity input.
  • Business criticality. What does the asset support, what data does it hold, and who owns it? This is where risk management meets the business: the same flaw is not the same risk on every server.

Each axis has a short, documented scale, and the combined score maps to a remediation tier: act now, this sprint, the next patch cycle, or accept with a documented exception. Every exception carries an owner, a compensating control and an expiry date, which keeps the GRC side honest and gives auditors a trail.

The logic lives in Python, so it runs the same way every time. Scanner exports from Tenable and Qualys are normalized, joined with KEV data and asset context, scored, and written back as a ranked queue. Each finding carries its reasoning with it: which factors pushed it up, and which evidence supports them.

The outcome

The queue engineers see is short, and every item explains itself: why it is first, what makes it exposed, what evidence of exploitation exists. The conversation with a system owner changes from "the scanner says critical" to "this is internet-facing and listed in KEV," which is a far easier case to make and a far harder one to argue with.

Reporting improves too. Aging is tracked by risk tier rather than raw severity, and it rolls up into NIST CSF terms that leadership already uses. The model also lines up with where the federal baseline went: CISA's BOD 26-04 now sets remediation windows from exposure, exploitation, automatability and impact, which is threat-informed prioritization written into policy.