fix-cve

name	fix-cve
description	Fixes a CVE in nrdot distributions by looking up the CVE details, finding the installed vulnerable version in the generated go.sum files, adding a Go module replace directive to all affected manifest.yaml files, then regenerating licenses and committing the fix.
trigger	/fix-cve
type	agent
parameters	[{"name":"cve_id","description":"CVE identifier (e.g., CVE-2026-42154)","required":true}]
permissions	["Read","Edit","Bash"]

Fix CVE Skill

Given a CVE ID, looks up the vulnerability details, finds the vulnerable version in the generated go.sum files, adds replace directives to all distribution manifests, regenerates licenses, and commits the fix.

Steps

1. Look up the CVE

Use a web search or the OSV/NVD API to find:

• The affected Go module path (e.g., github.com/prometheus/prometheus)
• The fixed version (e.g., v0.311.3)

Useful sources:

• https://osv.dev/vulnerability/<CVE_ID> — structured JSON with package and fixed version
• https://nvd.nist.gov/vuln/detail/<CVE_ID>
• Web search: <CVE_ID> golang fix version

2. Find the installed vulnerable version

The installed version comes from the go.sum files generated by OCB. Run generate-sources first if the go.sum files don't exist yet:

make generate-sources

Then grep the go.sum files for the affected module:

grep "<module_path>" distributions/*/_build/go.sum | head -5

The version in go.sum is the exact string to use in the replace directive (it may be a pseudo-version like v0.311.2-0.20260409145810-72293ff1d2e0).

Only distributions whose go.sum contains the module need the replace. To be safe, add the replace to all manifests that include it.

3. Check if upstream has already fixed the dependency

Before adding a replace directive, check whether the upstream components that pull in the vulnerable package have already bumped it in their latest release. If they have, a NRDOT version bump would be a cleaner fix.

3a. Find which components directly depend on the vulnerable package

In the _build directory of any affected distribution, use go mod graph to find the direct dependents:

cd distributions/nrdot-collector/_build
go mod graph | grep "@<installed_version>" | grep "<module_path>"

This lists edges in the form parent@version <module_path>@version. Extract the unique parent modules — these are the direct dependents. Focus on any that are opentelemetry-collector-contrib components (e.g., github.com/open-telemetry/opentelemetry-collector-contrib/receiver/prometheusreceiver).

3b. Get the latest upstream release tag

gh release list --repo open-telemetry/opentelemetry-collector-contrib --limit 1 --json tagName --jq '.[0].tagName'

3c. Check each dependent component's go.mod in the latest release

For each contrib component identified in step 3a, fetch its go.mod from the latest tag and check whether it still uses the vulnerable version:

# e.g. for receiver/prometheusreceiver:
curl -s "https://raw.githubusercontent.com/open-telemetry/opentelemetry-collector-contrib/<latest_tag>/receiver/prometheusreceiver/go.mod" | grep "<module_path>"

Decision:

• If all dependent components in the latest release have bumped to >= fixed_version: Inform the user that the vulnerability is already fixed upstream in <latest_tag> and that a NRDOT version bump would resolve it without needing a replace directive. Ask if they want to proceed with the replace anyway as a short-term fix, or stop here. Exit without changes if they choose to stop.
• If any dependent component still uses the vulnerable version in the latest release: Proceed directly to step 4.

4. Add the replace directive

In each affected distributions/*/manifest.yaml, append under replaces::

  # Why: Fixes <CVE_ID>; can be removed when <upstream component> pulls in >= <fixed_version>
  - <module_path> <installed_version> => <module_path> <fixed_version>

Rules:

• Comment immediately before the replace line
• No severity label in the comment (e.g., don't write "HIGH severity")
• Use the exact pseudo-version string from go.sum as installed_version
• Ensure fixed_version has a v prefix

Example result:

replaces:
  # Why: Fixes CVE-2026-42154; can be removed when prometheusreceiver pulls in >= v0.311.3
  - github.com/prometheus/prometheus v0.311.2-0.20260409145810-72293ff1d2e0 => github.com/prometheus/prometheus v0.311.3

5. Regenerate licenses

Per project instructions, always run this after editing any manifest:

make licenses

This also regenerates sources as a prerequisite. Wait for it to complete successfully.

6. Commit on a branch

Follow project git conventions:

• Branch: $developer/fix-<cve_id_lowercase> where $developer is the current git user (e.g., $(git config user.name)/fix-cve-2026-42154)
• Message: fix: <CVE_ID> (conventional commit, single line)
• Stage: both manifest files and THIRD_PARTY_NOTICES.md

git checkout -b "$(git config user.name)/fix-<cve_id_lowercase>"
git add distributions/*/manifest.yaml THIRD_PARTY_NOTICES.md
git commit -m "fix: <CVE_ID>"

Notes

• Previous CVE fixes: git log --oneline | grep -i cve
• Replace directives can be removed in a future version bump once the upstream component has updated its own dependency to >= fixed_version.
• If installed_version is a pseudo-version (contains a date like 0.20260409), use the full pseudo-version string — Go resolves it correctly.