Add vulnerability management recommendations for maintainers by reyang · Pull Request #156 · open-telemetry/sig-security

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

No description provided.

…ners

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

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

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

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

+- [ ] 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 <7052238+arminru@users.noreply.github.com>

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

+- [ ] 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

+- [ ] 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

Time to revisit this topic.

Personally, I would like us to set a higher bar.
Having that said, the current state is that we have no bar set for OpenTelemetry, so I think we should move ahead with some bar, learn from it, and decide if we want to raise or lower the bar.

I suggest that we stick to this bar at least for now:

Core components: 30 days
Everything else: 60 days

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

+  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

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

Or maybe change to "repository"?

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

+- [ ] 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

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

jmacd

As we know, there is a rise in security advisories. It is time to assert these recommendations.

Kielek · 2026-04-24T05:34:49Z

+There are several aspects of vulnerability management that the Security SIG
+recommends to the OpenTelemetry project maintainers:
+
+- The maintainers of an OpenTelemetry project should establish a clear


Is this document follow OTel spec style?

if so, should ---> SHOULD. It is applicable to whole file.

Nope. This is a recommendation instead of a spec or enforcement, at least for now.

Kielek · 2026-04-24T05:39:06Z

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


4 weeks seems to be pretty optimistic. I think that we should make first scan of all otel-repositories against potential vectors, prioritize it and then, follow this practice.

Lets consider Codex with security plugin. It can provide 40-80 findings per pretty small repository. Reviewing, deciding if it is a security issue/bug/etc takes time.

I would also consider splitting the timeline for medium and low.

Kielek · 2026-04-24T05:45:10Z

+- [ ] 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


Comment generally related to the "contrib" repositories where maintainers mostly are responsible for the release processs/merging/keeping code quality guard.

What is the recommendation for the vulnerabilities in abandoned/high difficutlies to contact with codewoners?
Should we follow this SLA? Should maintainers be responsible for fixing it, or we should just announce GHSA after ~2/4 weeks from findings?

It is not artificial question, I am affected exactly by this, example can be shared in the private channel.

martincostello · 2026-04-24T10:31:08Z

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


Unless it's covered elsewhere, maybe add a recommendation to use dependabot or renovate?

martincostello · 2026-04-24T10:32:00Z

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


Or maybe change to "repository"?

martincostello · 2026-04-24T10:32:13Z

+
+Here is a check list for the maintainers:
+
+- [ ] Identify the direct responsible individual for security issues and


Suggested change

- [ ] Identify the direct responsible individual for security issues and

- [ ] Identify the directly responsible individual(s) for security issues and

martincostello · 2026-04-24T10:34:05Z

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


Maybe add some suggested tooling?

Things like renovate and dependabot probably remove the need to explicitly do some of these as they will indirectly do it and propose patches (e.g. bumping a container's version/SHA).

martincostello · 2026-04-24T10:36:47Z

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


I would also consider splitting the timeline for medium and low.

martincostello · 2026-04-24T10:39:41Z

Would it make sense to add some guidance about when to use private fork branches for working on patches for vulnerabilities?

Private avoids the possibility of leaking details in advance, but the current lack of CI for private forks makes this problematic to verify a patch, particularly when there's many different unrelated patches queued up to go out in the same release due to the possibility of merge conflicts etc.

Co-authored-by: Trask Stalnaker <trask.stalnaker@gmail.com>

Co-authored-by: Martin Costello <martin@martincostello.com>

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 <7052238+arminru@users.noreply.github.com>

mx-psi reviewed Aug 13, 2025

View reviewed changes

trask reviewed Aug 18, 2025

View reviewed changes

Comment thread docs/recommendations.md Outdated

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

jmacd approved these changes Apr 23, 2026

View reviewed changes

Kielek reviewed Apr 24, 2026

View reviewed changes

martincostello reviewed Apr 24, 2026

View reviewed changes

jmacd mentioned this pull request Apr 24, 2026

New security advisory tools #254

Closed

reyang and others added 2 commits April 24, 2026 09:58

Update docs/recommendations.md

abfade9

Co-authored-by: Trask Stalnaker <trask.stalnaker@gmail.com>

Update docs/recommendations.md

8ed071b

Co-authored-by: Martin Costello <martin@martincostello.com>

	- [ ] 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.


		Here is a check list for the maintainers:

		- [ ] Identify the direct responsible individual for security issues and

	- [ ] Identify the direct responsible individual for security issues and
	- [ ] Identify the directly responsible individual(s) for security issues and

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!

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!

Choose a reason for hiding this comment

Uh oh!

jmacd left a comment

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!

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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

reyang Aug 14, 2025 •

edited

Loading