What This Site Cannot Prove

Do not let a useful signal become an unsupported claim.

Vuln Signal can organize public vulnerability intelligence and local workflow state. It cannot independently prove your assets, exposure, exploitation, attribution, remediation, or formal risk decisions.

Boundary rule: when a claim depends on your environment, use Vuln Signal to frame the question, then collect proof from asset inventory, telemetry, vendor guidance, change records, owners, and governance systems.

Cannot proveaffected

Product, version, configuration, reachability, and business ownership need inventory proof.

Cannot provecompromise

Exploitation claims need telemetry and incident-response review.

Cannot proveclosed

Remediation needs patch, control, exception, or not-affected evidence.

Cannot proveattribution

Actor and campaign links need corroborated threat-intel sources.

Claims that require outside evidence

Evidence Checklist

We run the affected product

The portal may show a product or CPE, but installed product and version proof must come from inventory, owner confirmation, endpoint data, cloud inventory, or vendor tooling.

Needed proof: asset, product, version, owner, and source of truth.

The vulnerable path is reachable

Internet-facing labels, exploitability, and attack-vector fields do not prove your network path or authentication state.

Needed proof: exposure scan, firewall path, cloud config, auth requirement, or owner validation.

Attackers exploited us

KEV, public PoC, exploit maturity, or threat reporting can show pressure elsewhere, but not compromise in your environment.

Needed proof: logs, alerts, EDR, SIEM, identity, network, application, or IR findings.

The issue is fully remediated

A fixed version or control recommendation is not closure. Closure needs evidence that the specific asset or scope was changed and validated.

Needed proof: patch evidence, fixed version, control test, owner signoff, or residual-risk record.

A vendor or actor is responsible

Campaign, actor, vendor, and product views can organize context, but they do not establish legal responsibility or definitive attribution.

Needed proof: vendor source, support case, contract context, threat-intel corroboration, or legal review.

Risk is accepted

A local note or exception suggestion is not formal governance approval.

Needed proof: named risk owner, approval, scope, expiry, compensating controls, and audit trail.

Replace overclaims with validation asks

Instead of

We are vulnerable

Say: This record may apply to us. Please confirm product, version, affected range, and exposure for the listed assets.

Instead of

We are under attack

Say: Public exploitation pressure exists. Please check telemetry for the relevant indicators, behaviors, and exposed services.

Instead of

This is fixed

Say: A fixed version or control is available. Please attach deployment proof and post-change validation before closure.

Instead of

Risk accepted

Say: This requires accepted-risk approval with owner, scope, residual risk, expiry, and review trigger.

Where the missing evidence usually lives

Inventory systems

CMDB, endpoint inventory, EASM, cloud inventory, package managers, container registries, and owner-managed asset lists.

Telemetry systems

SIEM, EDR, identity logs, firewall, proxy, DNS, WAF, application logs, and cloud audit trails.

Vendor and change systems

Vendor advisories, support cases, release notes, patch records, change tickets, rollback notes, and fixed-version evidence.

Governance systems

Risk registers, exception approvals, audit repositories, policy records, legal review, and executive acceptance workflows.