VMT Goals

• receive potential vulnerability reports in confidence
• assist in documenting and assessing impact and relative severity
• help developers track and resolve vulnerabilities quickly
• aid downstream distributors coordinating disclosure of fixes
• get information into the hands of impacted users

Enablement

• stable maintenance process
• project governance
• defect tracker with configurable privacy and access controls
• mailing lists, both community-specific and wider-reaching
• groups of project domain experts and security liaisons

Tools

• detailed vulnerability management process
• report taxonomy
• templated communication
• structured data for advisories

Public Process

1. confirm impact and draft description
2. help review proposed solutions for backport acceptability
3. request CVE identifier(s)
4. review and publish security advisory

Embargoes

1. receipt of suspected vulnerability report
2. identify first-tier subject matter experts and make them aware
3. confirm impact and draft description
4. help review proposed solutions for backport acceptability
5. request CVE identifier(s)

Yet Still More

6. schedule coordinated disclosure date and (approximate) time
7. notify downstream stakeholders
8. assist in pushing pre-approved fixes into public code review
9. 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

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

Recommendations

• have clear documentation on how and who to contact
• follow a process and report taxonomy (feel free to reuse ours!)
• publish advisories, at least to oss-security@lists.openwall.com
• always credit people who report vulnerabilities to you
• cryptographically sign your public communications

Publication Pipeline

1. YAML (reviewable)
2. rST (E-mailable)
3. HTML (browseable)

Thanks and Links

• OpenStack Security: https://security.openstack.org
• Author: Jeremy Stanley
• License: https://creativecommons.org/licenses/by/4.0/legalcode
• Source: https://fungi.yuggoth.org/presentations/2024oidna