Vulnerability Management

A scan report is the start of a decision. It identifies possible weaknesses on particular assets; an analyst checks those findings, puts them in context, and follows the work until the result is verified. This repeating process is vulnerability management.

Name the problem precisely

A vulnerability is a weakness in software, hardware, settings, or a process. A threat is a person, group, or event that could cause harm. An exploit is code or a technique that takes advantage of a weakness. Risk combines the likelihood of harm with its impact on confidentiality, integrity, or availability. A missing update is a vulnerability; attackers using it to steal records are the threat acting through an exploit.

Findings also include default passwords, public storage, obsolete encryption settings, and end-of-life products that no longer receive security updates. A zero-day vulnerability has no fix yet because the vendor has had no time to respond. A zero-day attack uses that flaw; disclosure alone does not establish that attacks have occurred. Until checks and fixes exist, mitigations and detection help protect the affected systems.

Move from discovery to closure

1. Identify assets: establish what exists and who owns it.
2. Discover weaknesses: scan the assets and collect other reports.
3. Analyze and validate: check that each finding applies.
4. Prioritize: combine technical severity, threat evidence, and business context.
5. Treat: remove the weakness, reduce its risk, or obtain formal risk acceptance.
6. Verify and report: confirm the result, record closure evidence, and measure the work.

Suppose a scanner flags an outdated service on an employee portal. The analyst checks the installed build and vendor advisory. The portal owner explains its business role. A developer updates the service through change management. A fresh check confirms the fixed build and the portal's operation. If new servers keep restoring the old build, that evidence sends the program back to its deployment inventory and templates.

Read the identifiers

CVE Numbering Authorities assign IDs such as CVE-2014-0160, the Heartbleed flaw in OpenSSL. The year is part of the identifier, not a dependable discovery or fix date. In-house flaws and misconfigurations can need action without a CVE.

Give each role a clear job

The security team discovers, validates, prioritizes, and tracks. Administrators and developers apply changes; asset owners are accountable for system risk. Change authorities approve production changes, while authorized risk owners approve exceptions. A broad vulnerability assessment, an authorized penetration test that demonstrates impact, and valid bug-bounty reports all feed this same treatment process. A clean scan only describes the checks that ran successfully; missed assets and unknown flaws still need attention.

An inventory tells the program what to assess and gives coverage figures their meaning. Include servers, laptops, network equipment, applications, cloud resources, and internet-facing domains and certificates. Software and libraries matter as well as machines.

Record identity and business meaning

Each record needs a stable identifier, hostname, addresses, owner, support team, location or cloud account, operating system and software versions, business function, data classification, criticality, exposure, and lifecycle status. Use a cloud instance ID or agent ID to follow a machine through address changes. An IP address alone can point to a different device after a DHCP lease changes.

Assign a criticality tier with the owner. In one example scheme, Tier 1 covers payment services and identity systems, Tier 2 covers important internal services, and Tier 3 covers low-impact labs. The tier describes the harm from loss of confidentiality, integrity, or availability. A hard-to-patch system does not become less critical because fixing it is inconvenient.

Reconcile several sources

A configuration management database (CMDB) records managed assets, but discovery often reveals resources it lacks. Compare it with endpoint agents, directory services, DNS and DHCP, purchasing records, passive network observations, and cloud APIs. Match individual records before interpreting differences between totals. Investigate an asset seen in only one source: it may be new, retired, duplicated, or unknown to IT.

Active discovery sends probes to find responsive hosts. For an authorized network, nmap -sn 10.20.0.0/24 performs host discovery across a range containing 256 addresses. Fingerprinting infers device or operating-system details from responses; Nmap's -O requests OS detection. Treat an inferred identity as evidence to confirm. Passive discovery observes existing traffic and helps find fragile devices without probing them, though silent devices can be missed.

Work out the actual gap

A discovery run finds 212 live hosts. The CMDB contains 195 records, and host-by-host matching confirms that all 195 are in the discovered set. There are therefore 17 unrecorded live hosts. Assign each an owner and a record, or remove it through the appropriate process.

The vulnerability scan checks 180 of those 212 live hosts in the same week:

The 32 unchecked hosts remain a coverage gap. If some CMDB hosts had been absent from discovery, simply subtracting the totals would have hidden part of the mismatch. Keep the time period and population consistent when comparing coverage.

Catch resources that come and go

Shadow IT is technology established without IT's knowledge. It can sit outside normal patching and scanning. Cloud instances and containers may exist for minutes, so a monthly network scan can miss their entire lifetime. Feed the inventory from provider APIs and require useful resource tags, including owner, environment, and data classification. Assess the images and templates used to launch them.

For an application, a software bill of materials (SBOM) lists its components and libraries. When a library flaw is disclosed, connect affected component versions to the applications that contain them. Keep inventory updates running as resources are created, moved, and retired; a one-time spreadsheet cannot describe a changing estate for long.

A useful policy tells teams what must happen, who decides, and when work is due. It joins security findings to the organization's business priorities. Management approves it, and the program measures whether people follow it.

Distinguish the risk terms

Inherent risk is the risk before controls. Residual risk remains after controls. Risk appetite is the amount and kind of risk leadership is willing to accept while pursuing its goals. Decisions about an exception use the remaining risk, not just the original severity score.

A simple qualitative model multiplies likelihood and impact, each rated from 1 to 5:

An internet-facing service with a remote code execution flaw receives likelihood 4 and impact 5, giving 20 out of 25. A tested web application firewall rule lowers the assessed likelihood to 2 while impact stays 5, giving residual risk 10. Under an example policy requiring remediation within 30 days when residual risk exceeds 8, the service still needs a fix within 30 days. The control reduced risk without meeting that policy's acceptance threshold.

These ratings organize judgments; they are not measured probabilities. Record the reasons behind the likelihood and impact ratings so a later reviewer can understand the decision.

Write measurable rules

The policy defines asset scope, scanning frequency, responsibilities, severity and priority rules, remediation deadlines, exceptions, escalation, and reporting. Standards specify technical requirements, and procedures describe how teams carry them out. Governance means enforcing, measuring, and reviewing these rules.

An illustrative SLO schedule is Critical 15 days, High 30, Medium 90, and Low 180. State when the clock begins. Contracts and applicable requirements may set stricter deadlines. Add exploitation and exposure rules so a known exploited gateway flaw can trigger emergency work instead of waiting for the routine High deadline.

Plan for work that gets stuck

A fix may interrupt a business process, break a dependency, or require vendor certification. Legacy products may have no patch, while an SLA or memorandum of understanding may limit when changes occur. The policy needs routes for extra maintenance windows, verified compensating controls, and time-limited exceptions. A missed deadline goes to the asset owner, then the owner's manager, and then the risk committee according to the defined escalation path.

Connect policy to established frameworks

ISO/IEC 27001:2022 Annex A control 8.8 addresses technical vulnerability management. CIS Critical Security Controls v8.1 Control 7 covers continuous vulnerability management; Controls 1 and 2 support asset and software inventories. PCI DSS v4.0.1 requirement 11.3 addresses vulnerability scans in the payment-card environment, and NIST SP 800-40 Rev. 4 guides enterprise patch planning. Track deadline compliance and overdue risks so policy review is based on actual performance.

A scan type describes a different part of the assessment. Location, access, deployment, and activity are separate choices: an internal scan can be credentialed and agentless, while an agent can assess a laptop away from the office. Select a combination that fits the asset and the information needed.

Decide where and how to look

Use both internal and external views. An outside scan shows initial exposure; internal assessment helps find paths available after compromise or to an insider. Credentialed checks generally reduce false positives and false negatives because they inspect package builds and settings directly. Use dedicated scanning accounts with the least privileges that still allow a thorough assessment. Store credentials in the scanner's vault, monitor them, and rotate them.

Fit deployment to the asset

Agents report locally collected information to a console. They suit laptops that rarely connect to the corporate network and supported cloud hosts. Deploying, updating, and monitoring the agents remains part of the program.

Agentless network scans need no installed software and suit devices such as printers and switches. They need network reach and, for local evidence, credentials. Some cloud tools also assess disk snapshots through provider APIs without host agents. Check the access actually achieved, not just the chosen scan label.

Distinguish activity and purpose

Active scans send probes and analyze replies. Passive assessment watches existing traffic through a mirror port or network tap. Passive observation avoids probe load on fragile systems but misses services that stay silent during the observation period.

A discovery scan maps hosts, ports, services, and likely operating systems. A vulnerability scan checks for known weaknesses. A baseline scan compares settings with a requirement such as a CIS Benchmark or an internal hardening standard. For example, it may report that a minimum password length is 8 while the approved baseline requires 14. Finding an open port alone does not establish a vulnerability.

For software, static analysis inspects source code or binaries without running them. Dynamic analysis observes a running program. Web scanning and fuzzing are dynamic; fuzzing feeds malformed or random input and looks for failures such as crashes. Static reverse engineering can use a disassembler to examine compiled code.

Apply the choices

A public website needs an external network view plus authenticated web testing of its user functions. Frequently off-site laptops suit agents. Data-center Linux servers suit internal credentialed checks. For factory controllers, begin with passive monitoring and coordinate any tested active checks with engineering. The shortest report may simply come from the least visibility: compare reach and authentication before interpreting its size as good news.

A scan plan must produce useful evidence without interrupting the systems it assesses. Scope, timing, access, and workload limits belong in the plan before the scanner runs. Test only systems and accounts covered by written authorization, and follow the hosting provider's testing rules.

Establish scope and operating limits

Record address ranges, hostnames, cloud accounts, applications, contacts, approved windows, and excluded dangerous checks. Coordinate with system operators and the security operations team so scan alerts are expected. Restrict access to the scanner and its reports: they hold credentials and a detailed map of weaknesses.

Update the vulnerability feed or plugins before each run. Limit concurrent targets and checks to avoid overwhelming links or CPUs. Wrong credentials can lock accounts, probes fill logs and trigger defenses, and intrusive checks can crash fragile services. Use production-safe profiles, disable denial-of-service checks, and stagger heavy work outside peak periods.

Scan depth is a choice. A discovery profile has less operational impact than a deep intrusive profile, but it also answers fewer questions. Test a new profile on representative systems before increasing its reach. Frequency should reflect change and exposure: monthly internal scanning is a common minimum program choice, while weekly or continuous assessment gives fresher evidence. Significant changes and urgent advisories can require extra runs.

Reach every network segment

A central scanner behind a firewall may reach almost none of an isolated subnet. Put distributed scanners or agents in the relevant segments, or use narrowly scoped, time-limited scan access. Preserve the segmentation outside the approved need. Check host reach and successful authentication after the run so blocked probes do not become apparent clean results.

Apply payment-card scan requirements

For the cardholder data environment, PCI DSS v4.0.1 requires internal scans at least once every three months. High-risk and critical findings, as ranked by the entity, must be resolved and checked by rescanning; the scan tool must use current vulnerability information. Internal scans also follow significant changes.

Authenticated internal scanning under requirement 11.3.1.2 has been mandatory since March 31, 2025. Use sufficient scan privileges; document systems unable to accept credentials. The authenticated-scan requirement does not apply to the separate significant-change scans under 11.3.1.3. External scans occur at least once every three months through a PCI SSC Approved Scanning Vendor (ASV), with rescans as needed to achieve passing results. Significant changes also require external assessment under the standard's separate change-scan provision.

Protect physical processes

Operational technology (OT) includes systems controlling physical equipment. Industrial control systems (ICS) and SCADA, supervisory control and data acquisition, often prioritize safety and availability over scan depth. Old controllers can respond badly to unfamiliar packets. Prefer passive monitoring and vendor-approved tools; test in a replica and obtain engineering approval for active work during planned outages.

An example plan scans 10.20.0.0/24 with credentials on Saturdays from 01:00 to 05:00, limits concurrency to 10 hosts, updates feeds on Friday, and exports findings to tickets. It adds weekly external scanning and passive factory monitoring. The operator contacts and stop conditions make the plan usable when performance changes during a run.

Start with the question, then select the tool. Mapping an address range, assessing a dependency, and checking whether a defense detects an attack are different jobs. A tool's output needs validation even when its product name is familiar.

Find hosts, services, and known weaknesses

Nmap maps ports and services; -sV requests service-version detection, -O requests OS detection, and the Nmap Scripting Engine supports additional checks. Angry IP Scanner offers simple host and port discovery. Masscan scans large address ranges quickly for open ports, with little service detail.

Nessus uses plugin checks to assess known vulnerabilities. Greenbone's OpenVAS reports weaknesses with a Quality of Detection rating. Nuclei runs YAML templates for targeted checks, including web-service and CVE checks. Template selection matters because checks differ in purpose and operational impact.

Assess web behavior

A network scanner can find a web server and known component issues, while authenticated web testing examines application behavior. Business-logic problems still need careful validation of the actual workflow.

Inspect cloud resources and software artifacts

Prowler and ScoutSuite query cloud configuration through APIs and report posture issues. Checkov analyzes infrastructure-as-code, such as Terraform or Kubernetes definitions. Trivy assesses artifacts including container images and repositories for vulnerable components, misconfigurations, and exposed secrets, and can generate SBOMs.

For example, an open management port in a Terraform rule calls for Checkov or Trivy before deployment. A public storage bucket already deployed calls for a cloud posture assessment. A library bundled inside a container calls for image or composition scanning. These findings may share an owner, but they need different evidence.

Recognize specialist testing roles

Maltego builds relationship graphs from open-source data using transforms; Recon-ng organizes modular reconnaissance. Both support external attack-surface discovery. Metasploit Framework includes exploitation and auxiliary assessment modules; Pacu focuses on AWS attack testing. Authorized specialist testing can confirm exploitability, while routine analysts still need evidence and a treatment record.

GDB and Immunity Debugger inspect running programs, memory, and registers. They help explain crashes found by fuzzing. Atomic Red Team provides small tests mapped to MITRE ATT&CK, and MITRE Caldera automates adversary emulation. These breach and attack simulation tools test whether controls detect or block techniques. A successful detection test says something about that control; it does not establish that installed packages are up to date.

Severity helps sort a report, but the evidence explains why the scanner raised a finding. Read the affected asset and the detected version, setting, or response before assigning work. A useful ticket must give its owner enough detail to reproduce and fix the problem.

Read the finding as a record

Look for the title, plugin or check ID, CVE references, severity, CVSS version and vector, asset, port, protocol, service, detection evidence, recommended solution, and first-seen and last-seen dates. A plugin ID identifies the scanner's check; it is not interchangeable with a CVE ID.

For a web issue, inspect the URL, parameter, request, response, and confidence. A report such as "Reflected cross-site scripting in parameter q of /search" identifies an application input to investigate. A cloud result needs account, region, resource ID, check ID, and PASS or FAIL, so the correct resource owner can act.

Interpret port states accurately

Consider these service-detection results:

22/tcp   open     ssh    OpenSSH 7.4
80/tcp   open     http   Apache httpd 2.4.6 ((CentOS))
443/tcp  closed   https
3306/tcp filtered mysql

SSH and HTTP are exposed to this scanner. Nothing is listening on 443 from this observation. Port 3306 remains uncertain because a filter blocks the needed evidence. The banners suggest an older CentOS environment; confirm the operating system and support status with authenticated data before recording an end-of-life finding. CentOS Linux 7 reached end of life on June 30, 2024; extended support arrangements also need checking.

Use confidence to plan validation

Greenbone's Quality of Detection (QoD) rates the evidence behind a result. Examples include 97% for authenticated package checks, 80% for banners that report patch level, and 30% for banners that do not. Reports commonly hide results below 70% by default. Burp labels confidence as certain, firm, or tentative. A severe finding with weak evidence needs prompt validation; confidence and severity answer separate questions.

Turn repeated rows into useful work

One vendor update may fix many CVEs. If 900 of 1,240 finding rows are resolved by five updates, group tickets by update, owner, and affected host list. Retain the individual finding links so validation can confirm every affected instance.

Compare scans using states such as new, fixed, reopened, and persistent. Before accepting a large fall in findings, compare reachable hosts, successful authentication, and scan duration. A password rotation that breaks scanner login can remove local findings from the report without removing any weakness. Informational results can also expose unknown services or expiring certificates, so keep them in the review.

A positive result and an actual vulnerability are two different things. Validation checks whether the finding applies to the asset. Reviewing scan health also helps find weaknesses the scanner failed to report.

Classify the four outcomes

False negatives leave real weaknesses out of the work queue. Common causes include failed authentication, blocked probes, offline hosts, missing scope, old feeds, unrecognized custom software, and flaws with no available check. Cross-check inventory, scan coverage, authentication logs, and independent sources when a report looks unexpectedly clean.

Validate from evidence to conclusion

1. Read the check's evidence and the condition it claims is vulnerable.
2. Obtain the real package build or configuration through authenticated access.
3. Compare it with the relevant vendor advisory and fixed build.
4. Check whether the affected feature and conditions are present.
5. Correlate agent or endpoint evidence and record the conclusion.

A banner can be stale or incomplete, and a proxy may answer for another machine. An incorrect OS fingerprint can lead to checks for the wrong product. Manual confirmation, when needed, belongs to authorized testing with an appropriate operational plan.

Recognize a backported fix

A distribution can patch an older software branch while preserving its upstream version number. This is a backport. Suppose a banner shows OpenSSH_7.4, while the upstream fix appeared in 7.7. That comparison alone misses distribution-specific fixes.

In an illustrative distribution, an authenticated check returns package build openssh-7.4p1-23, and the vendor's advisory lists openssh-7.4p1-21 as the fixed build for the same supported release. Build 23 contains the backported fix, so the specific CVE finding is false. If authenticated evidence also confirms an unsupported operating system, its end-of-life finding remains real. Closing one claim does not close every risk on the host.

Suppress narrowly and revisit

For a confirmed false positive, record the check, asset, reason, supporting evidence, and review date. Limit suppression to that specific check on that specific asset. A global disable could hide genuine findings elsewhere, and a later configuration change could make the old conclusion invalid.

A statement such as "we patched it" needs verification: a restart may be pending or a second installed copy may remain. Check the effective version or setting instead of accepting a remembered maintenance action.

Use the right denominator

If 6 of 50 reported findings are false, 12% of the reported sample is false. The statistical false-positive rate instead divides false positives by all actually negative cases:

The sample of positive reports supplies no true-negative count, so it cannot establish that rate. State exactly what a metric measures; improving credentials, scope, feeds, and scan placement improves the evidence behind both positive and negative results.

The Common Vulnerability Scoring System (CVSS) describes technical severity on a scale from 0.0 to 10.0. Record the score's source, version, and vector so its meaning is clear. FIRST maintains CVSS; business priority still needs exposure, exploitation evidence, and asset context.

Decode exploitability and impact

A virtual machine escape can cross from the guest's security authority to the hypervisor. Cross-site scripting can affect the victim's browser authority. Scope does not mean the number of machines in the scan.

Heartbleed's vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N. It describes network reach, low complexity, no required privileges or interaction, unchanged scope, and high confidentiality impact. Its base score is 7.5. AV:N describes the flaw's access method; it does not tell you whether your particular server is internet-facing.

Use the weights for unchanged scope

AV weights are N 0.85, A 0.62, L 0.55, P 0.20. AC is L 0.77 or H 0.44; UI is N 0.85 or R 0.62. PR is N 0.85, L 0.62, or H 0.27 for unchanged scope; changed scope uses 0.68 for L and 0.50 for H. Each impact weight is High 0.56, Low 0.22, or None 0.

When impact is positive, cap the sum at 10 and round upward to one decimal place. Zero impact gives a zero base score. For AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, ISS is 0.914816, impact is about 5.8731, and exploitability is about 3.8870. The sum is about 9.7602, so the base score is 9.8.

Changed scope uses a different impact expression and a 1.08 base-score multiplier:

Use the version-specific calculator to apply these rules without mixing formulas.

Interpret the result

Severity bands are None 0.0, Low 0.1–3.9, Medium 4.0–6.9, High 7.0–8.9, and Critical 9.0–10.0. Requiring low privileges changes the unchanged-scope 9.8 example to 8.8; adding local access gives 7.8; changing only attack complexity to High gives 8.1. These describe technical differences, not exploitation probabilities. If two sources disagree, compare the vectors and source judgments before choosing a score to record.

A base score describes the flaw's technical characteristics. Threat information changes over time, and the same flaw can matter differently in two deployments. CVSS provides separate metric groups for these adjustments, with different rules in versions 3.1 and 4.0.

Adjust v3.1 for time

The v3.1 Temporal group contains Exploit Code Maturity, Remediation Level, and Report Confidence. Their multipliers are:

Not Defined counts as 1. Multiply the base score by all three and round upward to one decimal place. For a 9.8 base score with E:U, RL:O, RC:C:

If exploit maturity becomes High while the official fix remains available, the product becomes 9.31 and rounds upward to 9.4. Temporal adjustments can lower the base score or leave it unchanged; their multipliers cannot raise it above the base.

Describe the local environment

v3.1 Environmental metrics include confidentiality, integrity, and availability requirements (CR, IR, AR), plus modified base metrics such as MAV and MPR. Requirement weights are High 1.5, Medium 1.0, Low 0.5, and Not Defined 1.0. Document the deployment evidence for every adjustment.

In the Heartbleed example, confidentiality requirement High gives an environmental score of 9.3, while Low gives 5.7. A 9.8 base flaw with modified Attack Vector Adjacent gives 8.8. Use the full environmental calculator; multiplying a base score by a requirement weight is not its calculation.

Read the changes in CVSS 4.0

Version 4.0 adds Attack Requirements (AT) for deployment or execution conditions, such as a race condition. User Interaction becomes None, Passive, or Active. Scope is replaced by separate confidentiality, integrity, and availability impacts on the vulnerable system (VC, VI, VA) and subsequent systems (SC, SI, SA).

The groups are Base, Threat, Environmental, and Supplemental. Threat Exploit Maturity can be Attacked, Proof-of-Concept, Unreported, or Not Defined; Not Defined is scored as Attacked. Environmental requirements default to High when Not Defined, and modified subsequent-system integrity and availability can identify safety impacts. Supplemental fields, including Safety, Automatable, Recovery, Value Density, Response Effort, and Provider Urgency, add context without changing the score.

Keep labels attached

Use CVSS-B, CVSS-BT, CVSS-BE, or CVSS-BTE to show the scoring groups used. Version 4.0 uses lookup-based scoring, so use FIRST's calculator. FIRST's Heartbleed example is 8.7 CVSS-BT, compared with 7.5 in v3.1; its Zimbra reflected-XSS example is 5.1 in v4.0 and 6.1 in v3.1. A version change can change the number without changing the software or its deployment.

Severity describes potential harm under technical conditions. Exploitation evidence tells you whether attackers are using a flaw or are likely to use it soon. These signals complement CVSS and business context; no single list describes every vulnerability.

Separate evidence from prediction

The US Cybersecurity and Infrastructure Security Agency (CISA) maintains the Known Exploited Vulnerabilities (KEV) catalog. Inclusion requires an assigned CVE, reliable evidence of exploitation in the wild, and clear remediation guidance. Entries also identify known ransomware use. Absence from KEV leaves exploitation status open; new attacks or non-CVE weaknesses may not appear there.

FIRST's Exploit Prediction Scoring System (EPSS) estimates the probability of observed exploitation activity for a published CVE in the next 30 days. Scores run from 0 to 1 and are updated daily. The percentile gives relative rank among scored CVEs.

For an illustrative daily record, EPSS 0.10 and percentile 0.88 mean an estimated 10% chance of exploitation activity and a score at or above 88% of scored CVEs. The percentile is not an 88% exploitation probability, and the score is not the chance that your own server will be compromised.

Assess the strength of the signal

A published proof of concept shows that an exploit approach exists. Weaponization turns an approach into reliable, usable tooling. Confirmed exploitation in the wild, including ransomware use, is stronger evidence that action is needed now. Follow vendor advisories, threat intelligence, information sharing and analysis centers, and catalog updates. A low EPSS score can change when new information arrives.

Suppose finding A is CVSS 9.8, EPSS 0.004, and absent from KEV on an internal test server. Finding B is CVSS 7.5, EPSS 0.94, and in KEV on an internet-facing VPN gateway. Prioritize B: confirmed attacks, direct reach, and a critical access role combine. Schedule A within policy instead of dropping it from the queue.

Use decision trees for action

Stakeholder-Specific Vulnerability Categorization (SSVC) comes from Carnegie Mellon University's Software Engineering Institute. CISA's tree considers exploitation, technical impact, automatability, mission prevalence, and public well-being impact. Its decisions are Track, Track, Attend, and Act*, moving from normal tracking toward urgent coordinated action. Apply the actual tree; knowing one input is not enough to invent its outcome.

CISA's Binding Operational Directive 26-04, issued June 10, 2026, replaced BOD 22-01. It binds Federal Civilian Executive Branch agencies for systems in scope and bases timelines on public exposure, KEV status, exploit automation, and partial or total technical control. Other organizations can use KEV voluntarily. The directive's transition requires agencies to begin applying its new evaluation and remediation timelines by December 7, 2026.

Respond when no patch exists

For a zero-day, apply vendor mitigations, restrict the affected service, and increase detection and monitoring. Once a fix appears, prioritize it using severity, exposure, and exploitation evidence. If attacks are reported, escalate promptly and investigate possible compromise through the incident response process. EPSS covers CVEs; assess in-house code flaws and misconfigurations through their own evidence.

A priority tells an owner how soon to act and why. Start with a validated finding, then combine technical severity, exploitation evidence, reach, asset value, existing controls, and treatment availability. A score alone cannot describe the business consequences of a failure.

Evaluate the asset and its attack path

External assets can be reached from the internet. Internal assets can be reached after an attacker enters the network or by an insider. Isolated assets have fewer paths, but maintenance devices and support links can still bridge the separation.

Asset value includes the criticality tier, data classification, regulatory scope, and dependencies. An identity provider may hold little customer data directly but control access to many other systems. Review the effects on services that depend on the vulnerable asset, not only the host itself.

Credit a compensating control only when it blocks the relevant path and has been tested. A web application firewall in detection-only mode records attacks but does not stop them. A segmentation rule that still allows the vulnerable service from user networks leaves that path open.

Apply a policy in order

Consider this example policy, applied from P1 downward:

F1 is a 9.8 flaw on an isolated lab VM, no known exploit, EPSS 0.02. It meets neither P1 nor P2, so it is P3. F2 is a 7.5 flaw on an external web server and is in KEV: P1. F3 is a 6.5 injection flaw on an external Tier 1 portal, with a public proof of concept and EPSS 0.20: P2 through the EPSS threshold. F4 is 8.8 on an internal file server with EPSS 0.15 and a patch: P2 through EPSS as well.

Work F2 first. Within P2, F3's external customer exposure puts it ahead of F4 in this example. F1 stays scheduled. A numerical sort by CVSS would have selected the low-exposure lab flaw first and delayed a known exploited public service.

Choose an action that is available

A patch permits scheduled remediation. If no fix exists, reduce exposure and monitor while tracking the pending fix. End-of-life products need replacement planning and interim protection. Lack of a patch changes the treatment; it does not erase the priority.

Consider combinations on the same asset. An information leak exposing usernames, weak login controls, and an old plugin can form a path more serious than any row viewed alone. Review related findings together before setting the work order.

Explain the decision in the ticket

Include asset identity, owner, finding evidence, recommended treatment, priority, deadline, and the reason. For example: "P1: the confirmed flaw is known exploited and the portal is internet-facing; complete remediation within the example policy's 3-day window." Keep the rationale attached when work is grouped across hosts. A likely false positive goes through prompt validation before a firm treatment decision is based on it.

A treatment changes the weakness, the exposure, or the business decision about the risk. Choose the treatment that addresses the actual finding, then plan who will implement it and how its effect will be checked. Remediation is the default when feasible.

Distinguish the treatment options

A compensating control meets the intent of a required control when that control cannot be applied. It must address the same risk, be documented, and be verified. A segmentation allowlist may protect an unpatchable legacy service; a web application firewall rule can provide virtual patching against a known exploit pattern. Detection alone still leaves the attack path open.

Classify controls in two ways

Control type describes implementation: administrative or managerial controls include policies and risk decisions; operational controls are daily human processes such as change management; technical controls include MFA and firewalls; physical controls include locks and badge readers.

Control function describes the job: preventive controls stop events, detective controls find them, corrective controls remove weaknesses or repair damage, and responsive controls contain an incident while it happens. A vulnerability scan is detective. A patch is corrective. Automated endpoint isolation can be responsive. One measure may serve more than one function; type and function are separate classifications.

Plan the change as a sequence

1. Test the update or configuration in an environment resembling production.
2. Implement through an approved change and maintenance window.
3. Prepare rollback evidence and steps, such as a backup or snapshot, before changing production.
4. Validate that the service works and the original weakness is gone.

An actively exploited flaw may need emergency change approval. A quarterly maintenance window cannot silently replace a 15-day policy deadline. Negotiate an extra window, use rolling updates where redundancy permits, or obtain a time-limited exception with verified controls.

Work through a blocked update

A web module has a critical remote code execution flaw. The patch is available, but application certification will take three weeks and the deadline is 15 days. Disable the module if unused. Otherwise, test a virtual patch, restrict access to necessary partner networks, and increase monitoring. Record the remaining risk and obtain the required exception, then install the certified update and rescan.

Also reduce the attack surface: discover external assets through edge scanning, DNS, and certificate records; remove unused services and retired systems. Security control testing, penetration testing, adversary emulation, and bug-bounty reports can reveal paths that need attention. Removing an unnecessary component prevents future findings from accumulating on it.

Some real findings cannot be fixed within policy. An exception makes the resulting risk visible and assigns an authorized owner to the decision. It is a controlled decision with an end date, not a way to remove difficult work from the dashboard.

Choose the risk strategy

Acceptance knowingly retains risk when the business needs the activity or treatment costs outweigh the expected benefit. Mitigation lowers likelihood or impact. Avoidance ends the risky activity. Transfer shifts some financial consequences through a contract or insurance, while accountability stays with the organization.

A contract or insurance policy does not stop an exploit from reaching an unpatched service. Review its scope separately from technical controls. A denied exception still leaves a decision to make: strengthen controls, remediate, or stop the activity.

Write the exception record

Record the specific asset and finding, business justification, risk analysis, compensating controls, residual risk, authorized approver, expiry date, and early-review triggers. Link the record to the remediation work so the intended permanent fix remains visible.

A false positive means the reported weakness is absent and is closed with evidence. An exception means the weakness is real and its residual risk is being retained temporarily. Suppressing a true finding as false would erase the very risk that management needs to approve.

Match approval to the remaining risk

The risk owner approves at a level suited to the residual risk. A low-risk exception may be within an asset owner's authority, while high residual risk can require senior leadership or the chief information security officer. The administrator requesting delayed work does not approve that request alone. The security team assesses the evidence and recommends controls.

Compare the remaining risk with the organization's risk appetite. A decision beyond delegated authority must move upward or be refused. The fact that a system is hard to replace explains the request; it does not establish that its risk is acceptable.

Follow a legacy-system case

A laboratory instrument uses a Windows 7 controller whose vendor software cannot run on a newer system. Standard support ended January 14, 2020, and replacement is budgeted for next year. The team records the unsupported controller as a real finding and proposes an isolated network, disabled USB storage, application allowlisting, and additional monitoring.

The department head and security leadership review the assessed residual risk. The exception expires after six months or when the replacement is installed, whichever comes first. The replacement project still has an owner and milestones, even though the exception's review date comes sooner than its expected completion.

Reopen when conditions change

A new exploit, KEV entry, failed compensating control, or exposure change can invalidate the earlier assessment before expiry. Review the risk then, not only at the calendar date. Track the number and age of exceptions, approaching expirations, and outstanding permanent fixes. Avoid blanket exceptions for whole environments: different assets can have different attack paths, owners, and consequences.

An installed update is an action; verified remediation is an outcome. Close a finding only when evidence shows the original weakness is gone and the service still operates. Track the time and coverage behind that evidence so managers can see where risk remains.

Verify the original condition

Rescan affected assets with the same relevant scan type and working credentials, or directly inspect the effective package build or setting. Confirm that the check ran successfully. A failed login cannot establish a fixed local vulnerability. Validate compensating controls too: test that the new access rule or virtual patch actually blocks the relevant path.

A fix can fail because a restart is pending, only one cluster node was updated, an application carries its own older library, or a deployment overwrites the setting. If replacement instances repeatedly return the flaw, update the golden image or template that creates them. Treat repeated reopening as evidence of a root cause in the build or deployment process.

Use clear workflow states

Move work through states such as open, in progress, mitigated, risk accepted, resolved awaiting verification, and closed. "Mitigated" means a control reduced risk; "closed" needs the relevant closure evidence. Scanner-ticket integration can reduce duplicates, but automated state changes must still follow successful verification and exception rules.

Read metrics together

Five critical findings close after 4, 9, 12, 20, and 30 days:

With a 15-day SLO, only three were on time:

The average meets 15 days while 40% of these findings missed the target. Also report open overdue findings: an average of completed work says nothing about how old an unresolved item has become.

Escalate the work that needs a decision

Aging buckets such as 0–30, 31–60, 61–90, and over 90 days show stalled work. Compare each item's age with its own deadline, then follow policy from owner to manager to risk committee. A newly exploited flaw may need immediate escalation before any age threshold.

Technical teams need host lists, evidence, and fixes. Managers need trends, top risks, overdue work, and the resources or decisions required. A falling total can come from failed scanning or quick closure of low-impact items, so compare coverage and high-priority aging before treating it as progress.

Application findings describe failures in how software handles data, memory, identity, or errors. Match the fix to the mechanism. The OWASP Top 10:2025 is an awareness list: Broken Access Control, Security Misconfiguration, Software Supply Chain Failures, Cryptographic Failures, Injection, Insecure Design, Authentication Failures, Software or Data Integrity Failures, Security Logging and Alerting Failures, and Mishandling of Exceptional Conditions.

Keep data from becoming instructions

Injection occurs when untrusted input becomes part of a query or command. Use parameterized queries, allowlist validation, and least-privilege accounts; avoid shell calls built from user input. Cross-site scripting (XSS) runs attacker-supplied script in another user's browser. Reflected XSS comes back in an immediate response, stored XSS is saved for later viewers, and DOM-based XSS arises in client-side code. Use context-aware output encoding and safe templates, supported by Content Security Policy. HttpOnly cookies limit script access to cookies but do not repair unsafe output.

Distinguish requests and file access

SSRF can reach cloud metadata at 169.254.169.254. File inclusion can disclose contents or execute code depending on how the application handles the file.

Protect memory and permissions

A buffer overflow writes beyond allocated stack or heap memory. An integer overflow exceeds a type's range; unsigned 8-bit arithmetic can wrap from 255 plus 1 to 0. Use bounds checks, safe functions, and memory-safe languages. ASLR, DEP/NX, and stack canaries make exploitation harder while the coding flaw remains.

Broken access control lets users exceed permissions, such as reading another customer's invoice by changing its identifier. Check authorization server-side on every request and deny access by default. Vertical privilege escalation gains higher rights; horizontal escalation reaches another user's rights. Authentication and session fixes include MFA, random session IDs, renewal at login, and expiration.

Address design and supporting services

Cryptographic failures include unencrypted data, hard-coded keys, and fast password hashes. Use TLS 1.2 or later, managed keys, and slow password hashes such as Argon2 or bcrypt. Remove default accounts, unnecessary features, directory listing, and verbose errors. Validate specific component flaws separately from end-of-life support risk.

Insecure design needs design and implementation changes, with threat modeling to identify missing controls. Remote code execution lets an attacker cause chosen code to run remotely; local code execution has a different access requirement. Data poisoning corrupts trusted or training data: control sources and track provenance. When errors occur, fail closed so exceptional conditions do not grant access. A web application firewall can reduce exposure during a code fix, but the unsafe code still needs repair.

Secure software needs checks at several stages because no one test sees the whole system. Add security requirements, threat modeling, code review, automated tests, deployment checks, and maintenance to the software development life cycle (SDLC). Moving suitable checks earlier is called shifting left.

Compare the testing methods

SAST might flag a request value concatenated into a query. DAST can provide response evidence from the running test application. Validate the combined evidence before choosing the code fix. Fuzzing adds malformed-input testing to find crashes and other failures. Authentication and crawl coverage matter: a DAST run that never reaches an administrative page has not assessed its inputs.

Find affected dependencies

SCA reads package manifests, lock files, or binaries to identify bundled components. For example, log4j-core 2.14.1 is affected by Log4Shell, CVE-2021-44228, with CVSS v3.1 10.0. The fix requires a suitable fixed release and redeployment of every application carrying the component. The historical Java 8 remediation baseline 2.17.1 addresses that incident's related flaws; select a currently supported, vendor-recommended release for new work.

An SBOM records components, versions, suppliers, and dependency relationships in a machine-readable format such as SPDX or CycloneDX. It answers where a component is used. A supplier's VEX, Vulnerability Exploitability eXchange, states whether a product is Not affected, Affected, Fixed, or Under investigation for a vulnerability. Validate a VEX statement's product/version match and supporting reason before changing a finding's status.

Protect the supply chain

Compromised update channels, malicious packages with similar names, and abandoned dependencies can introduce risk through trusted suppliers. The 2020 SolarWinds Orion compromise illustrates an update-channel attack. Assess vendor practices; agree patch and disclosure expectations; request SBOMs; verify hashes or signatures; pin dependencies; and use approved internal registries. Version pinning makes changes controlled, but an outdated pinned dependency still needs review and updates.

Build security into the program

Threat modeling uses the design to ask what could go wrong. STRIDE covers Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege. Turn identified threats into controls and test cases.

OWASP's Software Assurance Maturity Model (SAMM) organizes program improvement across Governance, Design, Implementation, Verification, and Operations: three practices in each function, 15 total, with maturity levels 1–3. Use it to plan capabilities, while day-to-day secure coding keeps data separate from commands, encodes output, protects credentials and sessions, limits privileges, and handles errors without exposing internals.

Cloud security depends on both provider and customer work. Identify the service model before assigning a finding, then assess deployed settings as well as the images, code, and templates that create them. Cloud resources can change faster than a periodic network scan.

Assign responsibilities by service model

In every model, customers remain responsible for their data and who can access it. A managed database can remove OS-patching work while leaving excessive permissions or public exposure for the customer to fix.

Read posture findings by resource

Cloud security posture management (CSPM) checks configurations through provider APIs, commonly with read-only access. Prowler and ScoutSuite report findings against resources and benchmarks, such as CIS cloud foundations benchmarks. Repeat checks because account settings, identities, and network rules change frequently.

Common findings include public storage, overly broad identity permissions such as "Action": "*", unencrypted volumes or snapshots, disabled logging, committed access keys, privileged users without MFA, exposed management interfaces, and internet-wide SSH or RDP access. 0.0.0.0/0 covers all IPv4 addresses; a rule allowing it to port 22 or 3389 exposes the management service wherever the resource is reachable.

Repair the deployment source

Infrastructure as code (IaC) describes resources in templates. Checkov or Trivy can flag a Terraform rule containing cidr_blocks = ["0.0.0.0/0"] for SSH before deployment. Restrict access to the required administrative range or use an approved bastion or session management service.

Correct both the deployed setting and its template. Otherwise the next deployment can restore the exposure. Differences between declared and actual settings are configuration drift. A console-only repair can be temporary even when the immediate check passes.

Rebuild images and cover short-lived work

Scan container images for OS packages and libraries in the build pipeline and registry. Rebuild from an updated base image and redeploy; do not rely on patching individual running containers. Minimal base images reduce unnecessary components. Also inspect Kubernetes definitions for risky settings such as privileged execution.

Use provider APIs and resource tags to inventory short-lived instances. Assess their golden images, templates, and dependencies; use supported agents or snapshot assessment where suitable. With managed serverless runtimes, provider updates follow the service's update settings. Customers maintain function code and libraries, rebuild container-based functions, and update custom runtimes.

Work a posture finding to verification

An assessment finds public personal-data storage, root access without MFA, and internet-wide RDP. Restrict the exposed data immediately and urgently address the privileged identity and management path. Fix bucket and network rules in deployed resources and IaC. Enroll AWS root-user MFA through the Management Console; ordinary APIs and IaC do not enable it. Rerun the relevant checks, verify application access still works, and check that a later deployment preserves the correction.