Add vulnerability management recommendations for maintainers #156

reyang · 2025-07-30T08:19:06Z

No description provided.

…ners

arminru · 2025-08-06T10:04:49Z

docs/recommendations.md

+  - repository configurations - for example, a hotfix branch might not have the
+    proper branch protection rules, or the repository might not have the proper
+    security settings enabled.


This should be mostly covered by org-wide config-as-code tooling by now but we don't cover custom branches beyond main there usually, right?

Right.
This is more serving as a check list for the maintainers, while working on cleaning up the branch policies we have noticed several projects not protecting things correctly (couple of them were surprising).

arminru · 2025-08-06T10:05:32Z

docs/recommendations.md

+  - package dependencies - for example, a package might have a known
+    vulnerability, or a package might be using a deprecated version of a
+    library.


We might want to put that one to the top of the list as it's the most frequent concern that's brought up.

docs/recommendations.md

arminru · 2025-08-06T10:08:04Z

docs/recommendations.md

+- [ ] Critical and high severity vulnerabilities are patched within 2 weeks of
+  discovery.
+- [ ] Medium and low severity vulnerabilities are patched within 4 weeks of
+  discovery.


While it's good to document an SLA here, I think it should be defined more clearly rather than just in the checklist that's summarizing the above.
When this is done, we should likely point out that this is a best-effort guideline for the project itself but without any guarantees or legal implications.

We have the following wording in the Collector SIG in case it helps:

We aim to provide a release that fixes security-related issues in at most 30 days since they are publicly announced; with the current release schedule this means security issues will typically not warrant a bugfix release.

Co-authored-by: Armin Ruech <[email protected]>

mx-psi · 2025-08-13T15:39:34Z

docs/recommendations.md

+- [ ] Critical and high severity vulnerabilities are patched within 2 weeks of
+  discovery.
+- [ ] Medium and low severity vulnerabilities are patched within 4 weeks of
+  discovery.


We have the following wording in the Collector SIG in case it helps:

We aim to provide a release that fixes security-related issues in at most 30 days since they are publicly announced; with the current release schedule this means security issues will typically not warrant a bugfix release.

mx-psi · 2025-08-13T15:41:04Z

docs/recommendations.md

+- [ ] Critical and high severity vulnerabilities are patched within 2 weeks of
+  discovery.
+- [ ] Medium and low severity vulnerabilities are patched within 4 weeks of
+  discovery.


I think these are a bit too aggressive. You can see e.g. these ones from Gitlab: https://handbook.gitlab.com/handbook/security/product-security/vulnerability-management/sla/
where low and medium have a 90/180 day SLA. I think we should align to something like that

The OpenSSF questionnaire says

There MUST be no unpatched vulnerabilities of medium or higher severity that have been publicly known for more than 60 days.

I would go with that maybe at least for the core repos

The OpenSSF questionnaire says

There MUST be no unpatched vulnerabilities of medium or higher severity that have been publicly known for more than 60 days.

I would go with that maybe at least for the core repos

I feel this is a low bar and we should put a higher one. Here is my thinking: OpenTelemetry components are widely used by other OSS components, if our bar is to get the medium or higher CVEs patched in 60 days, we are not giving sufficient time for our users (including other OSS software that depend on us) to meet their 60 days time. That's the reason why I put 4 weeks.

I think a higher bar makes sense to some but not all OpenTelemetry components necessarily (e.g. I don't think a security vulnerability in, say, Weaver, is as problematic as one in opentelemetry-python: they have different use cases with different security implications and their usage is different). I am in favor of a stronger requirement in specific components, but since this is an universal standard I think we should put a lower bar here

Makes sense to me. Do you feel this is a good balance?

Core components: 30 days
Everything else: 60 days

Sounds reasonable to me

trask · 2025-08-18T16:18:23Z

docs/recommendations.md

+- [ ] False positives are documented (e.g., by commenting on the security
+  advisory, by providing the dismissal reason to a code scanning alert) and
+  dismissed.
+- [ ] Critical and high severity vulnerabilities are patched within 2 weeks of


not sure about wording

Suggested change

- [ ] Critical and high severity vulnerabilities are patched within 2 weeks of

- [ ] Critical and high severity vulnerabilities (after rescoring if needed?) are patched within 2 weeks of

trask · 2025-08-18T16:18:27Z

docs/recommendations.md

+  dismissed.
+- [ ] Critical and high severity vulnerabilities are patched within 2 weeks of
+  discovery.
+- [ ] Medium and low severity vulnerabilities are patched within 4 weeks of


not sure about wording

Suggested change

- [ ] Medium and low severity vulnerabilities are patched within 4 weeks of

- [ ] Medium and low severity vulnerabilities (regardless of rescoring) are patched within 4 weeks of

carlosalberto · 2025-08-25T22:44:39Z

IMHO this looks good.

trask · 2025-09-29T16:09:31Z

docs/recommendations.md

+  the worst case, this can be a potential end-of-life announcement of the
+  affected component or project.


"or project" made me think catastrophic end of OpenTelemetry

Suggested change

the worst case, this can be a potential end-of-life announcement of the

affected component or project.

the worst case, this can be a potential end-of-life announcement of the

affected component.

trask · 2025-09-29T16:11:16Z

docs/recommendations.md

+- [ ] Daily scan CI/CD environment for deprecations and vulnerabilities.
+- [ ] Daily scan container image dependencies for deprecations and
+  vulnerabilities.
+- [ ] Daily scan repository configurations for deprecations and vulnerabilities.


is this something maintainers can do?

trask · 2025-09-29T16:16:56Z

docs/recommendations.md

+- The maintainers of an OpenTelemetry project should establish a clear
+  accountability for security issues, including identifying the direct
+  responsible individual for security issues at a certain time, for
+  example, via a duty rotation. This should be
+  documented in the main README.md file of the project.


this feels a bit heavyweight for most of the repos to establish a DRI rotation where there are 2-3 maintainers

as long as the maintainers are meeting the bar we are setting for triage / fixing

if we want to keep this, maybe "... or some other process that ensures vulnerabilities are being triaged in a timely manner"

add vulnerability management recommendations/requirements for maintai…

bf7acb1

…ners

reyang requested a review from a team as a code owner July 30, 2025 08:19

arminru reviewed Aug 6, 2025

View reviewed changes

Update docs/recommendations.md

d822ef9

Co-authored-by: Armin Ruech <[email protected]>

mx-psi reviewed Aug 13, 2025

View reviewed changes

trask reviewed Aug 18, 2025

View reviewed changes

carlosalberto approved these changes Aug 25, 2025

View reviewed changes

trask reviewed Sep 29, 2025

View reviewed changes

	- [ ] Critical and high severity vulnerabilities are patched within 2 weeks of
	- [ ] Critical and high severity vulnerabilities (after rescoring if needed?) are patched within 2 weeks of

	- [ ] Medium and low severity vulnerabilities are patched within 4 weeks of
	- [ ] Medium and low severity vulnerabilities (regardless of rescoring) are patched within 4 weeks of

		the worst case, this can be a potential end-of-life announcement of the
		affected component or project.

Add vulnerability management recommendations for maintainers #156

Are you sure you want to change the base?

Add vulnerability management recommendations for maintainers #156

Uh oh!

Conversation

reyang commented Jul 30, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

reyang Aug 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

carlosalberto commented Aug 25, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

reyang Aug 14, 2025 •

edited

Loading