|
|
|
@@ -43,10 +43,10 @@ You must not edit files anywhere else. In particular, do not touch `.woodpecker/
|
|
|
|
|
1. **IaC misconfigurations** — apply the smallest config change that resolves the
|
|
|
|
|
misconfiguration. Examples: setting `securityContext.runAsNonRoot: true`,
|
|
|
|
|
pinning an image to a digest, restricting an overly broad NetworkPolicy.
|
|
|
|
|
2. **Image vulnerabilities** — bump the image reference *only* if the finding's
|
|
|
|
|
`FixedVersion` field is populated AND the new version is a clear in-place
|
|
|
|
|
upgrade (same major). If `FixedVersion` is empty or only a moving tag like
|
|
|
|
|
`latest` is available, skip the finding.
|
|
|
|
|
2. **Image vulnerabilities** — these are package-level CVEs *inside* an upstream
|
|
|
|
|
image (Go stdlib, OS libs, app deps). The fix is almost never editing our
|
|
|
|
|
code; it's bumping the image **tag** to a newer release that ships the
|
|
|
|
|
patched packages. Use the procedure under `## Image tag bumps` below.
|
|
|
|
|
3. **Never silence a finding.** Do not add Trivy ignore directives, lower severity
|
|
|
|
|
thresholds, or exclude scan paths to make findings disappear. Fix the root
|
|
|
|
|
cause or skip and document the skip.
|
|
|
|
@@ -60,6 +60,58 @@ You must not edit files anywhere else. In particular, do not touch `.woodpecker/
|
|
|
|
|
that needs the privilege), prefer to skip and document — the reviewer can
|
|
|
|
|
decide.
|
|
|
|
|
|
|
|
|
|
## Image tag bumps
|
|
|
|
|
|
|
|
|
|
Image vulns are noisy — most upstream images carry dozens of unfixed CVEs at
|
|
|
|
|
any time, and the right action is rarely "do nothing" but is also rarely
|
|
|
|
|
"jump to the newest major". Follow this procedure for every image in the scan
|
|
|
|
|
results:
|
|
|
|
|
|
|
|
|
|
1. **Group findings by image.** Each `trivy-image-*.json` has an `ArtifactName`
|
|
|
|
|
field at the top — that's the image being scanned (e.g.
|
|
|
|
|
`docker.io/library/postgres:15.17`). Process one image at a time.
|
|
|
|
|
|
|
|
|
|
2. **Parse the current tag.** Only proceed if the tag matches semver:
|
|
|
|
|
`vMAJOR.MINOR.PATCH` or `MAJOR.MINOR.PATCH` (with or without a leading `v`).
|
|
|
|
|
Skip and document for:
|
|
|
|
|
- Moving tags: `latest`, `release`, `stable`, `edge`, `main`, etc.
|
|
|
|
|
- Date tags: `2026-01-15`, `2026.05`.
|
|
|
|
|
- Hash / digest tags.
|
|
|
|
|
- Tags without a clear patch component: `15`, `15.17` (only major.minor — no patch to bump).
|
|
|
|
|
|
|
|
|
|
3. **List available tags.** Use `Bash(crane ls <repository>)` to fetch the tag
|
|
|
|
|
list from the registry. The repository is the image without the tag, e.g.
|
|
|
|
|
`docker.io/library/postgres`. Some registries need a registry prefix
|
|
|
|
|
(`ghcr.io/...`) — pass it through unchanged.
|
|
|
|
|
|
|
|
|
|
4. **Pick the highest patch on the same major.minor.** Example:
|
|
|
|
|
- Current: `postgres:15.17`. Candidate: highest `15.X` where X > 17.
|
|
|
|
|
- **Never** propose a minor bump (`15.17` → `15.18` is OK; `15.17` → `16.0` is NOT).
|
|
|
|
|
- **Never** propose a major bump (`v2.3.0` → `v3.0.0` is NOT).
|
|
|
|
|
If no higher patch exists, skip with reason "already on highest patch".
|
|
|
|
|
|
|
|
|
|
5. **Verify the candidate tag exists and is pullable.** Use
|
|
|
|
|
`Bash(crane manifest <repository>:<new-tag>)` — if it errors, skip with
|
|
|
|
|
reason "candidate tag not resolvable". Do not infer existence.
|
|
|
|
|
|
|
|
|
|
6. **Find every reference in the repo.** A given image (e.g. `postgres:15.17`)
|
|
|
|
|
may be referenced from multiple files (Helm values, raw manifests, ansible
|
|
|
|
|
tasks, docker-compose templates). Use Grep to find ALL of them under the
|
|
|
|
|
edit-scope paths and bump them in lockstep — partial bumps create
|
|
|
|
|
compatibility drift between callers of the same image.
|
|
|
|
|
|
|
|
|
|
7. **Compatibility caveats — surface, don't decide.** Even patch bumps can
|
|
|
|
|
carry side effects: a Postgres patch may pull in a libc that breaks an
|
|
|
|
|
operator's preflight; a Redis patch may change a default that another
|
|
|
|
|
client doesn't expect. You are NOT expected to verify upstream changelogs.
|
|
|
|
|
Just call out for each bump in the summary:
|
|
|
|
|
- The image and version delta.
|
|
|
|
|
- Other images in the repo that pair with it (e.g. if `postgres:15.17` is
|
|
|
|
|
bumped, mention any `cnpg/postgresql:15.17`-style siblings or anything
|
|
|
|
|
that depends on it).
|
|
|
|
|
The PR reviewer is the human compatibility check — your job is to be
|
|
|
|
|
transparent about what could be at risk.
|
|
|
|
|
|
|
|
|
|
## Output
|
|
|
|
|
|
|
|
|
|
When you are done editing, write a Markdown file to `/tmp/security-fix-summary.md`
|
|
|
|
|