cve-validate

Files (1)

• SKILL.md

SKILL.md (first lines)

# CVE Validation

Validate whether a reported CVE Jira ticket actually affects the current operator codebase, assess how the affected code is used, and recommend the appropriate action.

When invoked (`/cve-validate OSPRH-28972`), run the full workflow below and produce a structured report.

## Prerequisites

**You must run this skill from within the operator repository that the CVE is filed against.** The skill analyzes the code in the current working directory — if you are in the wrong repo, the results will be meaningless.

Before invoking, ensure:

1. **Correct repository** — `cd` into the operator repo that matches the `pscomponent:` label on the CVE ticket (e.g., `osp-director-operator`, `glance-operator`).
2. **Correct branch** — check out the branch the CVE applies to (typically the release branch, e.g., `v1.3.x`, or `main`). The Go version and dependency versions vary between branches, so the assessment depends on which branch you are on.
3. **Up-to-date code** — run `git pull` or `git fetch` to ensure you are analyzing current code, not a stale checkout.
4. **Go module present** — the directory must contain a `go.mod` file.
5. **Jira MCP available** — the Jira MCP server must be configured to fetch ticket details.

### Pre-flight check

Before starting the workflow, verify the environment:

```bash
# Confirm go.mod exists
test -f go.mod || echo "ERROR: no go.mod — are you in the right directory?"

# Show current repo and branch
git remote get-url origin
git branch --show-current
head -3 go.mod
```

Report the repository name, current branch, and Go version to the user at the top of the output so they can confirm they are analyzing the right target:

```
Analyzing: github.com/openstack-k8s-operators/osp-director-operator
Branch:    v1.3.x
Go:        1.24.4
```

If `go.mod` is missing, stop and ask the user to navigate to the correct directory.

## Workflow

### Step 1: Fetch CVE context from Jira

Use Jira MCP (`jira_get_issue`) to fetch the ticket with `fields: *all`.

Extract:

- **CVE ID**: from the `labels` field — look for labels matching `CVE-*`
- **Summary**: the ticket summary
- **Description**: the flaw description — this describes the vulnerable behavior
- **Component**: from labels matching `pscomponent:*`
- **Flaw reference**: from labels matching `flaw:bz#*` or `flawuuid:*`

From the description, identify the **affected Go package or module** (e.g., `crypto/x509`, `golang.org/x/net/http2`, `github.com/golang-jwt/jwt/v5`).

If the ticket is not a Vulnerability type or has no CVE label, stop and report:

```
This ticket is not a CVE vulnerability tracker. Type: <actual type>, Labels: <labels>
```

### Step 2: Classify the affected package

Determine whether the CVE affects:

1. **Go stdlib** — package path has no dots (e.g., `crypto/tls`, `net/http`, `encoding/xml`). Fix comes with a Go toolchain bump.
2. **Direct dependency** — listed in `go.mod` under `require`. Fix requires bumping the dependency version.
3. **Transitive dependency** — not in `go.mod` directly but pulled in via another dependency. Check `go.sum` or run `grep` in `go.mod` for indirect dependencies.
4. **Not present** — the module is not in `go.mod` or `go.sum` at all. The CVE does not apply.

For **Go stdlib** CVEs, read the `go` directive from `go.mod` to get the current Go version.

For **dependency** CVEs, find the current version from `go.mod`:

```bash
grep '<module-path>' go.mod
```

### Step 3: Look up CVE details and fix versions

Use `WebSearch` to search for the CVE ID. Gather:

- **What the vulnerability is** — a plain-language description of the flaw
- **How an attacker exploits it** — what input or action triggers the vulnerability (e.g., "send a TLS ClientHello with a crafted certificate chain containing thousands of intermediate certificates")
- **What the impact is** — DoS, RCE, information disclosure, privilege escalation, etc.
- **Which versions contain the fix** — for Go stdlib: which Go release(s) include the patch; for dependencies: the minimum fixed version

Compare the fix version against the current version from Step 2.

If the current version already includes the fix, stop and report:

```
CVE-YYYY-NNNNN is already fixed in the current version (<current>) which is >= fix version (<fix>).
No action required.
```

### Step 4: Discover all build targets in the repository

A single repository can produce multiple container images, each built from different source directories. The CVE ticket's `pscomponent:` label refers to a specific image, but **all images built from this repo share the same go.mod and must all be checked**.

Discover all build targets:

```bash
# Find all Dockerfiles (excluding CI tooling and .git)
find . -name 'Dockerfile*' -not -path '*/CI_TOOLS_REPO/*' -not -path '*/.git/*'
```

For each Dockerfile found, identify:

1. **What Go source it builds** — look for `go build` commands and their target path (e.g., `go build -o manager main.go`, `go build -o agent ./containers/agent`).
2. **Whether it builds Go code at all** — some images are shell-script-only or use pre-built binaries (e.g., an image downloader that just installs `qemu-img`). Skip non-Go images.

Report all discovered build targets in the output. Example for a repo that builds multiple images:

```
### Build Targets

From openstack-k8s-operators/devskills, MIT.

More from openstack-k8s-operators/devskills