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:

1. How is the vulnerable code path triggered? (e.g. parsing attacker-controlled input, making network requests, running a server)
2. 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.
3. 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>