fix-security-issue

name: fix-security-issue description: Handle CVE/vulnerability reports from security linters (trivy, osv-scanner, etc.). Tries to upgrade first; ignores only when safe and justified. allowed-tools: Read Grep Glob Edit Write Bash WebFetch WebSearch argument-hint: "[CVE-ID or vulnerability description]" model: sonnet

Investigate and fix the security issue $ARGUMENTS reported by trivy, osv-scanner, or another security linter.

Step 1 — Research the CVE

Browse the internet to gather full context:

Visit the CVE URL from the scan output (e.g. https://avd.aquasec.com/nvd/<cve-id>)
Check the fixed version, affected component, and attack vector
Understand the exploit mechanism: what input/behavior triggers the vulnerability?

Step 2 — Locate the vulnerable dependency

Find where the vulnerable package comes from:

Go binary (e.g. stdlib): check which linter binary embeds it — the scan output names the file (e.g. usr/bin/actionlint). Find the linter's descriptor in megalinter/descriptors/ and its pinned version.
Python package: check pyproject.toml, uv.lock, .config/python/dev/requirements.txt, server/requirements.txt.
npm package (direct): search descriptors for npm: blocks containing the package name.
npm package (transitive): identify the top-level npm package that brings it in, then check its upstream changelog/release notes.
OS package (Alpine apk): find the descriptor that installs it.

Step 3 — Try to upgrade

Check whether a fixed version is available and reachable:

For linter binary CVEs (Go stdlib, etc.): check if a newer release of the linter exists that was compiled with a fixed runtime. Look at GitHub releases.
For Python packages: update the version pin in pyproject.toml / requirements files, then run uv lock --python 3.12 to regenerate uv.lock.
For npm packages (direct descriptor): bump the ARG ..._VERSION= line in the descriptor, then run make megalinter-build.
For npm packages (transitive): upgrade the parent package to a version whose package.json lists a fixed transitive version.
For OS packages: bump the apk package version in the descriptor if pinned.

If an upgrade is possible and available: do it, then stop here. No ignore entry needed.

Step 4 — Assess impact when upgrade is not possible

If no fixed version exists yet (latest release is still affected), analyze whether the vulnerability is exploitable in MegaLinter's context:

Ask:

How is the vulnerable code path triggered? (e.g. parsing attacker-controlled input, making network requests, running a server)
Does MegaLinter invoke that code path? Linters run as static analysis tools — they read source files, they do not serve HTTP, process untrusted templates, or accept external network connections.
What is the actual impact? Consider:
- DoS / resource exhaustion → generally not exploitable in a one-shot CI linter
- Credential theft / data exfiltration → only relevant if the linter makes outbound connections or reads secrets from env
- Arbitrary code execution → serious; check if the attack vector reaches the linter's execution environment

Step 5 — Decide: block or ignore

Stop and warn the user if:

The vulnerability involves credential theft, secret exposure, or supply-chain compromise
The attack vector is reachable (e.g. a linter that fetches remote configs or calls an external API)
The severity is CRITICAL and the exploit mechanism is not ruled out

Add an exception only when the CVE is genuinely not exploitable in MegaLinter's context. Acceptable reasons:

DoS via crafted input that the linter never receives (e.g. crypto/tls in a tool that makes no TLS calls)
Template/injection attack requiring untrusted user-controlled input that MegaLinter never passes
Server-side vulnerability in a tool used only as a CLI client
Debug/tooling CVE (e.g. cilium-bugtool) in a package imported only for its data types

Step 6 — Add the exception

`.trivyignore` (for trivy findings)

Append to the appropriate section (or create a new one):

# <linter/package>: <one-line explanation of why not exploitable in MegaLinter>
CVE-XXXX-XXXXX

`osv-scanner` config (for osv-scanner findings)

Check for an osv-scanner config file (e.g. .osv-scanner.toml or osv-scanner.toml) and add an ignore entry following its schema.

General rule

Always include:

The CVE ID
A comment naming the affected package and the specific reason it is not exploitable
A note if the ignore should be revisited (e.g. "remove when releases a version compiled with Go X.Y.Z")

Step 7 — Update CHANGELOG

Do not update CHANGELOG.md for:

CVE ignore entries — not user-facing
Linter version bumps — the auto-upgrade workflow owns Linter versions upgrades

If you made a real behavior change (e.g. a linter disabled due to a security incident, a config workaround added), add one line under Fixes in the beta section:

- Fix <linter/component>: <what changed and why, one sentence for users>