How to Report a Vulnerability

Report vulnerabilities privately through GitHub Security Advisories. Open the Security tab of the DTVSS repository and choose Report a vulnerability. Only repository maintainers will see the report.

Please do not open public GitHub issues, post on social media, or share proof-of-concept code publicly until a fix has shipped and we have agreed on a disclosure date.

What to Include in a Report

• A clear description of the issue and the security impact.
• Steps to reproduce, ideally with a minimal proof of concept.
• The affected commit, deployed URL, or version.
• Your name or handle if you want to be credited.

A working exploit is not required. A credible explanation of impact is enough to start triage.

Scope

IN SCOPE

• The DTVSS web application at https://dtvss.io and any subdomains we operate.
• The Flask application (app.py), security-hardening module (security.py), scoring engine (dtvss_engine.py), API clients, and index loader.
• The deployment configuration (railway.toml, Procfile, requirements.txt).

OUT OF SCOPE

• Vulnerabilities in upstream data sources we consume but do not control: NVD, EPSS / FIRST.org, the CISA KEV catalogue, and CISA CSAF / ICSMA feeds. Report those upstream.
• Vulnerabilities in third-party Python packages. Report to the package maintainer; we will pick up the fix on release.
• Missing best-practice headers without demonstrable impact - a hardened header set is already applied in security.py.
• Rate-limit bypasses that only achieve what a regular user could already do.
• Volumetric denial of service. The production deployment sits behind Railway's edge and application-level rate limiting; please do not load-test it.
• Social engineering of project maintainers.

Safe Harbour

We will not pursue legal action against researchers who:

• Make a good-faith effort to avoid privacy violations, data destruction, service degradation, or disruption to other users.
• Test only against accounts and data they own, or against scoped test accounts we provide on request.
• Report the issue privately and allow a reasonable window for a fix before public disclosure.
• Do not exploit the issue beyond the minimum needed to demonstrate it.

If in doubt, ask first via a private advisory.

Coordinated Disclosure Timeline

If we go quiet for more than 14 days without explanation, you may escalate by re-pinging the advisory or, as a last resort, disclosing publicly with reasonable notice.

Acknowledgements

Researchers who report valid issues and want public credit are listed in the closed advisories on the GitHub Security tab.

Self-audit history

We periodically run automated security scanners against the production site and remediate findings. Scan reports and remediation evidence are retained in a private audit repository.

Next scheduled review: November 2026, or sooner if significant changes ship.

Policy Metadata

Last updated: 9 May 2026
Policy expires: 9 May 2027
Machine-readable: /.well-known/security.txt
Standard: RFC 9116
Preferred languages: English