Transparent Vulnerability Management
Official VMT Goals
- receive potential vulnerability reports in confidence
- assist in documenting and assessing impact
- help developers track and resolve vulnerabilities
- aid downstreams in coordinating disclosure
- get information into the hands of impacted users
Actual VMT Goal
- conserve our most valuable project resources
- maintainers: don't overburden unnecessarily
- users: keep them safe and well-informed
Public Process
- confirm impact and draft description
- help review proposed solutions for backport acceptability
- request CVE identifier(s)
- review and publish security advisory
Embargoes
- receipt of suspected vulnerability report
- identify first-tier subject matter experts and make them aware
- confirm impact and draft description
- help review proposed solutions for backport acceptability
- request CVE identifier(s)
Yet Still More
- schedule coordinated disclosure date and (approximate) time
- notify downstream stakeholders
- assist in pushing pre-approved fixes into public code review
- review and publish security advisory
Challenges
- bugs across software handled by different teams
- limited group of subscribers reduces the amount of review
- incomplete testing performed manually in private
- inefficiency of private coordination
- delay accommodating advance notification to stakeholders
- USA EAR/OFAC sanctions and export controls
Embargo = Pain
Only embargo when it makes sense, and limit your embargo
durations.
When not to...
It is now time for the security process to change and become more
open.
For the majority of lower severity issues [...] the cost of
embargoes really makes no sense.
Why not treat most security bugs like normal bugs and get them
fixed quickly and properly the first time around?
--Kurt Seifried, The Hidden Costs of Embargoes, 2015: https://access.redhat.com/blogs/766093/posts/1976653
Severity?
Remember this is open source, we do NOT dictate use, NOR do we
know how our software is being used. Because of that we can not know if
a specific bug we fix really is a "major" issue for you or not.
--Greg Kroah-Hartman, OSS Security ML, 2025 https://www.openwall.com/lists/oss-security/2025/10/03/1
Transparency
Trust dies in darkness. Secrecy breeds suspicion. This is open
source... so where's the open?
Nothing to Hide
At some point, everything becomes public...
- all details and discussions
- even proof-of-concept exploits
Recommendations
- clearly document who to contact and how
- follow a published process (feel free to reuse ours!)
- publish security advisories
- include links to patches and bug reports
- always credit people who report vulnerabilities
- send copies to oss-security@lists.openwall.com
- cryptographically sign public communications
- see baseline.openssf.org for additional suggestions