What the CVE list does not show
A program organized around CVE identifiers has a clear unit of work: a software version with a known defect, a patch, and a record that the version changed. Much of what actually puts an organization at risk does not fit that unit.
An administrative interface reachable from the internet. A storage bucket or cloud role with broader permission than any caller needs. A device still using its shipped password. An expired certificate on an internal service. A database listening on all interfaces that only the local application should reach. A test host stood up for a week in 2024 and never removed.
These conditions can require remediation without a corresponding CVE. The software may be fully patched; the problem is a condition in the environment.
Vulnerability and exposure
Vulnerabilities include weaknesses in systems, controls and configurations, not only software defects; NIST’s glossary defines a vulnerability as a “Weakness in an information system, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat source.” Here, ‘exposure without a CVE’ means an actionable deployment or access condition tracked without a CVE identifier. A program that tracks only CVE items under-counts.
The under-counting is structural. Scanners emit configuration checks as “informational” or at low severity because the scan engine cannot know whether an open management port is intended. Cloud posture tools report into a separate console. External attack-surface discovery produces a list that is read once and filed. A test host nobody declared is found, if at all, by a person. Each produces findings with no home.
Neutral guidance treats configuration as part of the same discipline. CIS Controls v8.1 places inventory first; Safeguard 1.1 asks enterprises to “Establish and maintain an accurate, detailed, and up-to-date inventory of all enterprise assets with the potential to store or process data.” Control 4 covers secure configuration, including Safeguard 4.8, “Uninstall or disable unnecessary services on enterprise assets and software,” and Control 7 asks for scans of externally exposed assets on “a monthly, or more frequent, basis.” The NIST Cybersecurity Framework 2.0 states the outcome in one line: “Vulnerabilities in assets are identified, validated, and recorded” (ID.RA-01).
One finding, whatever the source
The remedy is not another console. It is to define a finding independently of its source and require every source to produce that shape.
A finding needs an affected asset, resolved to an inventory entry rather than a bare IP address. It needs evidence: what was observed, when, and from where, because “port 8443 answered with a login page from the internet” is a different fact from “port 8443 was open on an internal scan.” It needs a severity judgment that is written down and explained: reachability, data at stake, and exploit preconditions. It needs an owner and a deadline. And it needs a lifecycle in which “resolved” is a conclusion drawn from reassessment evidence, not from the item no longer appearing in a report. The reasoning in not checked is not the same as clean applies without change: an exposure no longer reported because the discovery job lost its target range has not been fixed.
Severity is where exposures differ most from CVEs. There is no vendor score to inherit. A finding that says “high” with no reasoning will be argued about; one that says “high: reachable from any source address, no second factor, write access to production configuration” will be acted on.
The ownership problem
An established patching process may provide a default owner for CVE findings. Deployment and permission changes can span teams; assign accountability according to who can authorize and implement the change. An exposed interface belongs to the owner of the service behind it, who may not know it is reachable. A forgotten test host belongs to nobody until someone is assigned, and “nobody” is where findings go to age.
The workable pattern is rule-based ownership with a person-level override. Rules map assets to a team by site, network range, cloud account, tag or service name, so a new finding arrives with a default owner and the rule that assigned it. An analyst overrides the assignment when the rule is wrong, and the override is recorded. Unmatched findings expose an inventory, ownership-mapping or assignment gap. CISA’s Binding Operational Directive 23-01, which applies to federal civilian executive branch agencies, requires automated asset discovery “every 7 days” for a related reason: an unenumerated asset cannot be assigned.
Validate from where the attacker stands
An exposure should be confirmed before it is escalated, and confirmed the same way when it is closed. If external discovery reports an admin interface on the internet, a person or an automated check should reach it from outside the network and record the response. A captured banner with a timestamp and source address is evidence. A line in a tool export is a claim.
The same applies to resolution. The owner says the firewall rule was changed. For a finding whose resolution criterion is removal of external access, close it only after a successful external reassessment verifies that restriction; distinguish enforcement from an unavailable target or failed test. A recheck from inside has not tested what mattered.
A worked case
Suppose external discovery reports a web interface on port 8443 in a range registered to the company. The banner identifies a network appliance management console.
The security operations analyst sees it first, as a new finding with provisional severity high: internet-reachable, administrative, authentication unknown. The analyst validates from an external vantage point and records the login page, timestamp and source address. The ownership rule for that range maps to the branch network team, and the finding arrives assigned to them with an illustrative fourteen-day deadline under the organization’s remediation policy. The team confirms the interface was bound to the wrong VLAN during a replacement and restricts it to the management network.
The finding is closed only after a successful external reassessment from the same vantage point verifies that port 8443 is no longer reachable, and that reassessment is recorded as the supporting evidence; an unavailable target or a failed test is not verification. If the team instead decides the exposure is intended, because a vendor manages the device over the internet, the finding is not resolved; it is risk accepted, with the reasoning, the accepting person and a review date recorded.
In practice
Checks to run this week:
- Take the last external discovery report and count how many items became tracked findings with an owner. The gap is the under-count.
- Pick an open exposure finding and read its severity. If it does not state reachability, data at stake and preconditions, it will not survive the first conversation with the owner.
- Look for findings with no owner older than thirty days. Each one exposes an inventory, ownership-mapping or assignment gap.
- Take an exposure marked resolved last quarter and confirm it was rechecked from the vantage point where it was first seen.
Sectie’s Exposure & Vulnerability Management product gives every finding the same owner, evidence and lifecycle, whatever reported it.
