Security Policy

How to report vulnerabilities and what to expect from our incident response process for all MeVTC open source projects.

Scope

This policy covers all MeVTC open source projects, including:

• pki-core — X.509 certificate utilities
• pki-federal — DoD CAC / Federal PIV / ECA provider pack

Vulnerabilities in upstream dependencies (OpenSSL, the cryptography library, Python itself) should be reported to their respective maintainers. If you are unsure whether a vulnerability is in our code or an upstream dependency, report it to us and we will triage.

Reporting a Vulnerability

Email info.security@mevtc.com with:

• The affected project and version
• A description of the vulnerability
• Steps to reproduce
• Potential impact
• Any suggested fixes (optional)

Encrypt sensitive reports with our PGP key if desired (available on request).

Alternative reporting mechanisms are available for US Government agencies and federal contractors. Contact info.security@mevtc.com for details.

Severity Classification

Severity	Definition	Examples
Critical	Remote exploitation without authentication; bypass of certificate validation	Chain validation bypass, CRL signature verification skip, header injection enabling authentication bypass
High	Significant security control weakened or bypassed with some preconditions	Revocation check bypass, identity extraction returning wrong identity, algorithm policy circumvention
Medium	Security control weakened but exploitation requires significant preconditions	CRL cache poisoning via local file access, timing side channels in certificate parsing
Low	Minor security concern with limited practical impact	Information disclosure in error messages, non-security-relevant crashes from malformed input

Response Timeline

Phase	Critical / High	Medium / Low
Acknowledgment	24 hours	48 hours
Severity assessment	48 hours	5 business days
Fix developed	7 days	30 days
Patched release	Within 48 hours of fix	Next scheduled release

Disclosure Policy

We follow coordinated disclosure with a 90-day disclosure window:

1. Reporter sends vulnerability details to info.security@mevtc.com.
2. We acknowledge receipt and begin assessment.
3. We develop and test a fix in a private branch.
4. We coordinate a release date with the reporter.
5. On release day: patched version published, security advisory issued (GitHub Security Advisory or equivalent), CVE requested if applicable.
6. If no fix is available within 90 days, we work with the reporter on an appropriate disclosure timeline.

After a Fix

• Patched release published to PyPI / GitLab Package Registry
• Security advisory published via GitHub Security Advisories
• CVE requested for Critical and High severity vulnerabilities
• CHANGELOG updated with the fix description
• Regression test added to prevent reintroduction

Security Testing

All projects in this ecosystem undergo:

• Static analysis — linting (ruff), type checking (mypy), security scanning (bandit) on every commit
• Dependency scanning — pip-audit checks for known vulnerabilities in dependencies
• Fuzz testing — Hypothesis property-based testing with 500+ examples per test in CI, 50,000+ per test in stress runs
• SBOM generation — CycloneDX Software Bills of Materials published as CI artifacts

Each project's SECURITY.md documents project-specific static analysis suppressions with justifications.

Contact

Security issues: info.security@mevtc.com
General inquiries: info@mevtc.com