cve-check

name	cve-check
description	Assess a single CVE for busola. Given a CVE id, package, and artefact from a compliance report, identify the affected Dockerfile and determine whether the affected functionality is reachable from busola's code. Produces one risk-accept-or-fix verdict per invocation. Read-only — does not mutate state.

CVE check

A user invokes this skill while reading a CVE compliance report. They give you a CVE id and artefact name, and want you to answer "is this CVE actually a threat to busola's code?" with a concrete verdict and action.

Workflow

1. Confirm you have all inputs

You need the CVE id and the artefact name to start. Look at $ARGUMENTS and the conversation context. If either is missing, ask the user before continuing. Do not ask for or require the affected package — you will identify it from the CVE lookup in step 3.

Do not invent details and do not rely on training data for the CVE description — step 3 covers how to look that up from authoritative sources.

2. Identify the affected Dockerfile

Strip the version tag from the artefact (e.g. busola-fips-image:1.0.32 → busola-fips-image), then look it up:

Artefact name prefix	Dockerfile	Base image	OS family
busola-busola-image	Dockerfile	node:24.15-alpine3.23	Alpine / musl
busola-busola-web-image	Dockerfile.web	node:24.15-alpine3.23	Alpine / musl
busola-busola-backend-image	backend/Dockerfile	node:24.15-alpine3.23	Alpine / musl
busola-fips-image	Dockerfile.fips	europe-docker.pkg.dev/kyma-project/restricted-prod/sap.com/node-fips:24.15-slim	Debian-slim / glibc

Read the relevant Dockerfile to confirm the base image — the mapping above can drift.

3. Look up the CVE to scope the affected surface

WebSearch for the CVE id and then WebFetch an authoritative source from the results. Good sources include NVD, GitHub Security Advisories, vendor advisories (e.g. openssl.org, nodejs.org), and distro security trackers (Debian, Alpine, Red Hat, Ubuntu). Skip aggregator blogs and summary sites — go to the source. If the first source is thin (NVD entries are often skeletal for fresh CVEs), follow links or run a second search to find one that names the affected functionality of the package — e.g. "TLS certificate parsing in openssl", "malloc boundary check in glibc". That narrows the next step: you're checking reachability to that specific surface, not the whole package.

Do not rely on training data alone. Recent CVEs may not be in your knowledge cutoff, and descriptions get amended by vendors. If no useful source turns up, say so explicitly in your reasoning and assess at the package level with a caveat (e.g. "affected functionality unknown without CVE description; defaulting to Fix required").

4. Assess reachability

• OS-package findings (glibc, openssl, busybox, tre, v8, libaom, expat, picomatch, brace-expansion, util-linux, yarn, …): the surface is via the Node.js runtime in the base image, not via application code. Use the CVE description from step 3 to identify the affected package and the specific functionality it targets (e.g. BusyBox tar extraction, glibc malloc, OpenSSL TLS parsing). Then check whether busola's workload ever invokes that specific functionality — if the vulnerable feature (e.g. archive extraction, a specific syscall) is simply never called by the application, that is Not applicable, not just a risk-accept. Only use Risk-accept candidate when the package and feature are present and called, but the exploit conditions (e.g. attacker-controlled input reaching that path) cannot be met. If the artefact's base image doesn't ship the affected package at all (e.g. a glibc CVE against an Alpine/musl image), that is also Not applicable.
• npm-package findings: Use the package name from the CVE description. Grep package.json and backend/package.json for the package. If it's a direct dependency, Grep src/ and backend/ for import sites of the affected entry point identified in step 3.

5. Emit one triage block

### CVE-YYYY-NNNN — <package from CVE lookup> — <artefact>
- Verdict: **Not applicable** | **Risk-accept candidate** | **Fix required**
- Reasoning: <one or two sentences. Always include the artefact name explicitly so the user can paste this into the compliance dashboard.>
- Action: <either a one-line justification, or a concrete remediation step (e.g. "Bump `node-fips:24.15-slim` to a version with patched glibc in `Dockerfile.fips`. No application code changes.").>

Risk policy

• Use Not applicable when the CVE is structurally unrelated to the artefact — either the affected software is not present in the image (e.g. Chrome, a Windows driver), or the affected functionality of a present package is never invoked by the application (e.g. BusyBox tar extraction in a backend that never extracts archives). The vulnerability cannot exist in this artefact regardless of configuration.
• Use Risk-accept candidate when the package and the specific vulnerable feature are both present and exercised, but the exploit conditions cannot be met from busola's workload (e.g. attacker-controlled input cannot reach that code path).
• If reachability is unclear, default to Fix required. Pushing the decision to a human is safer than under-calling severity.
• Justifications for Not applicable and Risk-accept candidate must include the artefact name and a brief reason. Reviewers paste these into the compliance dashboard, so they need to read clean.

Safety rule

The assessment is read-only — you investigate the codebase but do not edit it. If the user asks to apply a fix after the verdict (e.g. "bump the base image"), stop and confirm explicitly before editing any Dockerfile.

Out of scope

• Batch mode / triaging a whole report at once — one CVE per invocation. If the user wants to triage several, run the skill multiple times.
• Auto-applying fixes.

Triage analysis is advisory. The human owner of the finding is responsible for the final risk decision in the compliance dashboard.