Security Policy
November 28, 2025 ยท View on GitHub
Security bulletins
For requesting any information regarding the security of this project please join:
Reporting a vulnerability
GitHub is the preferred method for privately reporting a security vulnerability.
-
File the report on the appropriate github repository
This is necessary because it allows us to use temporary private forks.
This table should help you, but in doubt please ask the maintainers for help.Project Name GitHub Repository Create Report Umbrella openebs/openebs Create Report Mayastor openebs/mayastor Create Report openebs/mayastor-control-plane Create Report openebs/mayastor-extensions Create Report LVM LocalPV openebs/lvm-localpv Create Report ZFS LocalPV openebs/zfs-localpv Create Report Rawfile LocalPV openebs/rawfile-localpv Create Report HostPath LocalPV openebs/dynamic-localpv-provisioner Create Report CSI Go library openebs/lib-csi Create Report Linux Utils openebs/linux-utils Create Report You will receive a confirmation email upon submission.
-
You may be contacted by the maintainers to further discuss the reported item.
Please bear with us as we seek to understand the breadth and scope of the reported problem, recreate it, and confirm if there is a vulnerability present.
Public Disclosure Timing
We prefer to fully disclose the bug as soon as possible once a user mitigation is available.
The Fix Lead drives the schedule using their best judgment based on severity, development time, and release manager feedback.
If the Fix Lead is dealing with a Public Disclosure all timelines become ASAP.
Supported Versions
OpenEBS releases follow the semver specification.
Security fixes are typically merged to the HEAD branch and due for release on the next minor version.
Upon request or if deemed necessary as part of a critical security fix we may backport the changes as a patch release.
Security Team Membership
The security team is made up of a subset of the project maintainers who are willing and able to respond to vulnerability reports.