======================================
 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
--------------

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
- 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

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/2025ato