Security matters, especially when the product helps teams make vulnerability risk decisions.
This page describes the security posture, data-handling boundaries, responsible disclosure expectations and vulnerability-management principles behind the CVSS Business Risk Prioritizer. The goal is to support safer remediation decisions without encouraging users to store confidential operational data in the MVP.
Translate public CVE intelligence and business context into remediation priority.
Reports are generated for the current session and are not saved as report history.
The MVP should not require secrets, customer data or private infrastructure details.
Security-focused by design
The application is built to support vulnerability triage and remediation prioritization without requiring users to store sensitive report history in the MVP.
Session-only report model
Reports are generated for the active browser session. They should be downloaded or printed by the user before refreshing, closing the page or generating a new report.
Public intelligence boundary
The cache is intended for public CVE intelligence such as NVD, EPSS and CISA KEV data. It is not intended to store private asset inventory or confidential findings.
Security posture for a vulnerability-management utility
A vulnerability prioritization tool must be careful about the data it encourages users to enter. The application is designed to work primarily with public CVE intelligence and selectable business context, rather than requiring users to upload confidential inventories, internal hostnames or incident details. That is intentional: the MVP should be useful without becoming a repository of sensitive security information.
The tool supports the vulnerability-management workflow by separating source metrics from business interpretation. CVSS remains the technical severity baseline. EPSS supports likelihood estimation. CISA KEV indicates known exploitation when listed. Business context explains why a vulnerability may be urgent for one organization and less urgent for another.
Vulnerability-management operating model
The application is aligned with a practical operating model used by security teams, infrastructure teams and business owners when converting a technical finding into an actionable remediation decision.
Identify and validate
The process starts with a CVE, scanner finding or manual security observation. The finding should be validated against the affected product, version, asset scope and available vendor advisory.
Enrich with source intelligence
Public intelligence such as CVSS, EPSS, CISA KEV, NVD references and vendor advisories helps determine technical severity, exploit likelihood and whether exploitation is already known in the wild.
Add business context
Security teams must understand whether the affected asset is internet-facing, production, identity-related, data-sensitive, regulated, customer-facing or protected by compensating controls.
Choose a treatment path
The treatment decision can be emergency patching, scheduled remediation, temporary mitigation, isolation, monitoring, escalation or documented risk acceptance.
Decision boundaries
The output should improve prioritization and communication, but it must not replace professional validation, change governance or risk ownership.
- The Business Risk Score is a prioritization aid, not an official replacement for CVSS, vendor guidance or organizational risk governance.
- EPSS is treated as probability of exploitation, not proof that exploitation has occurred.
- Known exploitation should only be asserted when a trusted source such as CISA KEV confirms it or when internal threat intelligence validates it.
- Compensating controls can reduce practical exposure, but they do not remove the underlying vulnerability.
- Generated reports should support remediation decisions, not automatically approve, delay or reject security work.
Data users should not enter
Public utility workflows should avoid collecting sensitive operational data unless a future version explicitly supports secure accounts, authorization, retention rules and protected storage.
- passwords, API keys, tokens or private keys
- customer names or regulated personal data
- real internal hostnames, IP plans or network diagrams
- confidential incident-response details
- unredacted screenshots containing sensitive infrastructure
- proprietary architecture or business-sensitive remediation notes
Responsible disclosure
If you believe you have found a security issue in the application, report it responsibly with enough technical detail for validation. This is not a public bug bounty program unless one is explicitly announced, but responsible reports are welcome.
Disclosure route
The project exposes /.well-known/security.txt so a production deployment can publish a security contact and disclosure policy location.
No destructive testing
Do not perform denial-of-service testing, scanning beyond the application boundary, credential attacks, social engineering, data extraction attempts or any test that could harm service availability or other users.
Production security checklist
How this supports safer vulnerability prioritization
A prioritization system is valuable only when its boundaries are clear. This application helps teams explain why a finding is urgent, why it can be scheduled, or why temporary controls are needed while remediation is pending. The final decision should remain owned by the responsible security, IT and business stakeholders.