Security vulnerabilities should be handled quickly and sometimes privately. The primary goal of this process is to reduce the total time users are vulnerable to publicly known exploits.
The relevant OTel repository maintainers, supported by the Security SIG and OpenTelemetry Technical Committee (OTel TC), are responsible for responding to the incident including internal communication and external disclosure.
The OTel project provides community support only for the last overall minor
version: bug fixes are released either as part of the next minor version or as
an on-demand patch version. Independent of which version is next, all patch
versions are cumulative, meaning that they represent the state of our main
branch at the moment of the release. For instance, if the latest version is
0.10.0, bug fixes are released either as part of 0.11.0 or 0.10.1.
Security fixes are given priority and might be enough to cause a new version to be released. Each repository is entitled to establish their own complementary processes. SIG-Security in conjunction with the TC can advise in case clarifications are required.
In order for the vulnerability reports to reach maintainers as soon as possible,
the preferred way is to use the Report a vulnerability button on the
Security tab in the respective GitHub repository. It creates a private
communication channel between the reporter and the maintainers.
If you are unable to or have strong reasons not to use the GitHub reporting workflow, please reach out to security@opentelemetry.io and we will provide instruction on how to report the vulnerability.
Reports should be acknowledged within 3 working days.
Please avoid reporting any vulnerabilities as a generic public "Issue" in GitHub.
Given the public visibility of GitHub issues, reporting a vulnerability as a GitHub issue would be public disclosure. If this is done accidentally or if you notice a vulnerability reported this way, please immediately re-report the vulnerability using "Report a vulnerability" and note the public disclosure as part of that report. You can ask GitHub to delete the issue but this shouldn't be considered a sufficient mitigation and the vulnerability should be considered publicly disclosed.
If a vulnerability appears to be not publicly known or disclosed, the repository maintainers will engage and the reporter is requested to honor an embargo period in which the vulnerability is keep private until a fix can be released and disclosed in an orderly manner. If the reporter has a need to disclose the vulnerability further, perhaps for a security conference or other obligation, they are asked to negotiate the disclosure date with the maintainers fixing the vulnerability. The repository maintainers will in any case do their best to move swiftly with the fix and release process.
If you discover an unreported publicly disclosed/known vulnerability please IMMEDIATELY use the reporting methods above to inform the team about the vulnerability so they may start the patch, release and communication process. Please include any relevant information about current public exploitations of this vulnerability, if known, to help with scoring and prioritization.
Maintainers of OTel projects have the role of being the primary responders and managers of vulnerabilities reported in their respective repos.
Maintainers should familiarize themselves with the above guidance for Reporters and encourage any potential Reporters to follow that guidance.
Vulnerabilities reported via the Report a vulnerability button will appear
for Maintainers as a Security Advisory under the Security tab under
the Advisories side bar option.
Maintainers can also create their own draft Security Advisory here using the
New draft security advisory button if they discover an unreported issue or
need to report for someone who is unwilling or unable to use the
Report a vulnerability button.
Note that for a specific OTel repo, only that repo's Maintainers and Security SIG Maintainers (which have been granted the Security Manager role) will have access to the full Advisories data and functionality.
For more detailed GitHub documentation on this feature, see this link
Vulnerability reports should be acknowledged by Maintainers within 3 working days. This acknowledgment should include a brief confirmation that the report has been received and that Maintainers are evaluating the issue.
When processing a vulnerability report, Maintainers should:
- Acknowledge receipt of the report within 3 working days
- Invite Collaborators as needed
- Verify if the reported issue is actually a vulnerability
- Assess the severity and impact of the vulnerability
- Determine if the vulnerability is already publicly known or disclosed
- Negotiate an embargo period, if needed
- Request a CVE, if needed
- Create a Temporary Private Fork, if needed
- Ensure work is progressing on a resolution in accordance with severity and embargo timeline
- When a fix is ready, Publish the Advisory
When working on security advisories in GitHub:
- Maintainers can add Collaborators to assist with investigation and fixing by using the "Add users or teams" edit box in the Collaborators section in the GitHub Security Advisory interface.
- Try to keep the number of Collaborators small to limit the exposure of the vulnerability details before a fix is available.
- Only add Collaborators who are necessary for investigating or fixing the issue.
- Consider adding Collaborators who:
- Understand the affected code
- Can assist with implementing or reviewing fixes
- Have expertise in the specific security domain
GitHub provides temporary private forks as a secure environment to fix vulnerabilities without exposing them to the public. These forks allow you to collaborate with others on fixing security issues before making the fixes public.
- Navigate to the main page of the repository
- Click on the "Security" tab
- In the left sidebar under "Reporting", click "Advisories"
- Select the security advisory you're working on
- Scroll to the bottom of the advisory form and click "Start a temporary private fork"
The temporary private fork will be created with a name in the format:
repo-ghsa-xxxx-xxxx-xxxx, where repo is your repository name (truncated to
80 characters if needed) and xxxx-xxxx-xxxx is the unique identifier of the
security advisory.
You can make changes to the private fork either on GitHub or locally:
-
On GitHub: Navigate to the temporary private fork from the advisory page, create a new branch, and edit the files as needed
-
Locally: Clone the temporary private fork, create a branch, make your changes, and push them back to the fork
-
From the security advisory page, click "Compare & pull request" to create a pull request for your changes
-
When all necessary changes are ready, scroll to the bottom of the advisory page and click "Merge pull request(s)" to merge all open pull requests in the temporary private fork
Important notes about temporary private forks:
- CI/CD integrations do not run in temporary private forks to maintain security
- You cannot merge individual pull requests; all open PRs are merged together
- Status checks will not run on PRs in temporary private forks
- After merging changes, you can publish the advisory to alert the community
For more details, see the GitHub documentation on private forks.
If Maintainers need assistance with how to handle a security vulnerability:
-
For general guidance of a non sensitive nature, Contact the Security SIG through the #otel-sig-security channel in the CNCF Slack workspace. Do not expose sensitive information in this channel as it isn't a secure communication mechanism.
-
For sensitive guidance specific to an Advisory, reach out to Security SIG Maintainers as they have access to all Advisories and can comment directly in them. For complex or high impact issues, the Security SIG may also involve the TC and/or GC.
When determining whether to request a CVE identifier, Maintainers should consider the type of OTel deliverables affected (executable vs. library) and the source of the vulnerability (direct vs. dependency):
-
Direct Vulnerabilities: Always request a CVE when a vulnerability exists in OTel's own code that could expose users to security risks.
-
Dependency Vulnerabilities: Request a CVE if these are all true:
- The executable uses the vulnerable part of the dependency
- The vulnerability can be exploited through the executable's usage patterns
- The vulnerability creates a security impact for users of the executable
Do not request a CVE if the vulnerability in the dependency cannot be triggered through normal usage of the executable.
Note that the vulnerability impact for the OTel executable may be different than for the dependency that caused it, depending on how it is used. Do not assume that the OTel CVE must have the same score as the dependency's CVE.
-
Direct Vulnerabilities: Request a CVE if the vulnerability exists in OTel's own library code.
-
Dependency References: Request a CVE if these are all true:
- The vulnerable dependency is transitively included in the runtime environment, even when users of the OTel library do not explicitly include the vulnerable dependency themselves (this is likely true in most cases for library code)
- The library uses the vulnerable part of the dependency
- The vulnerability can be exploited through the library's usage patterns
- The vulnerability creates a security impact for users of the library
Note that the vulnerability impact for the OTel library may be different than for the dependency that caused it, depending on how it is used. Do not assume that the OTel CVE must have the same score as the dependency's CVE.
- The vulnerability must affect released versions of OTel
- The vulnerability must have security impact (confidentiality, integrity, or availability)
- The vulnerability must not already have a CVE assigned to the specific OTel component
GitHub provides a streamlined process for requesting CVE identifiers:
- Within the Security Advisory interface, scroll to the bottom of the form
- Click the "Request CVE" button
- GitHub will review the request (typically within 72 hours)
- Once approved, GitHub will assign a CVE ID to the advisory
If you already have a CVE ID from another CVE Numbering Authority (CNA), you can add this to the Security Advisory form instead of requesting a new one through GitHub.
For more information on requesting CVEs through GitHub, see the GitHub documentation on requesting CVE identification numbers.
A: Use the Common Vulnerability Scoring System (CVSS) to assess severity. GitHub provides a CVSS calculator in the Security Advisory interface, or you can use the CVSS Calculator.
A: Whenever possible, include a fix version in the advisory before publishing. This allows users to update to a secure version immediately upon full disclosure. For vulnerabilities that are not publicly known, this is the entire point of embargo periods before disclosure.
A: Consider involving them for critical or high-severity issues that can't be fixed promptly, vulnerabilities affecting multiple repositories, or if you need guidance on handling a security related issue. If in doubt, feel free to reach out. Just be careful to avoid disclosing non-public vulnerability information in non-secure communication channels.
A: For non-public vulnerabilities, coordinate with the reporter to determine if they have a need for public disclosure, for example an upcoming security conference at which they want to present. Politely negotiate a timeline for disclosure as best you can, but understand that Reporters are under no obligation to OTel. In general, ask that the Reporter not disclose the vulnerability beyond the conversation in the Advisory until a fix is made and the Advisory has been published.
A: For publicly known vulnerabilities, prioritize creating an advisory and releasing a fix as quickly as possible. Note in the advisory that the vulnerability is already publicly known. If there is a known work-around or mitigation that users can implement, consider publishing an advisory with the work-around info until a fix can be made. This option should be balanced with how useful the work-around would be to users vs further advertising the vulnerability. If a vulnerability is so well known that multiple reports are being made, it can be advantageous to publish to avoid the reporting noise.
A: Similar to a reported vulnerability that was already publicly known: Continue your efforts to fix the vulnerability with urgency appropriate to its severity. Document the change in status in the Advisory so that the Collaborators and Reporter are aware that the vulnerability is openly known. However, continue to avoid spreading information about the vulnerability unless it significantly helps with the speed of the fix or users need to be informed of a work-around or mitigation steps.
A: If a fix will take a long time, particularly if the vulnerability is high or critical severity, you should bring this up with the Security SIG and/or TC to determine if there is any public messaging or other actions that need to be taken.