Files
werkregie/doc/prs/2026-10-13-PR#62-new-vulnerabilities.md
2026-10-13 19:51:35 +02:00

96 lines
4.4 KiB
Markdown

# PR#62: A Pull Request Fails Only on the Vulnerabilities It Brings
> **WARNING:** This document describes only the change applied in this PR.
> It may already be outdated once the next PR is merged.
> Historic PR documentation is not maintained along with new PRs; treat it as a snapshot.
## Related Links
- [PR#61](https://git.javagil.de/mi/werkregie/pulls/61), which checks each pull request for vulnerable dependencies.
## Problem
Since PR#61, the check `werkator/dependencies` of a pull request fails on each known vulnerability from CVSS 4.
A vulnerability found anew in a dependency that main already has would fail every pull request,
also one that does not touch the dependencies.
As a required check, it would stop all work until the dependency is updated.
## Non-Goals
- No notification in werkregie of a vulnerability on main; it follows in a PR of its own.
- No dependency locking of the build scripts' own classpath.
## Specification
### Feature: a pull request fails only on the vulnerabilities it brings
#### Scenario#62.01: a pull request that brings a vulnerable dependency fails
… so that no vulnerable dependency reaches main through a pull request.
- **Given** a pull request that adds a dependency with a known vulnerability of CVSS 4 or more
- **When** Werkator checks the pull request for vulnerabilities
- **Then** the check fails and names the dependency and the vulnerability
##### Verified by
- Manual: `checkNewVulnerabilities` with `commons-collections` 3.2.1 added against a base without it:
failed on CVE-2015-6420, CVSS 9.8.
#### Scenario#62.02: a vulnerability already on main does not fail a pull request
… so that a vulnerability found anew stops no unrelated work.
- **Given** a dependency of main with a vulnerability found after the pull request branched off
- **When** Werkator checks the pull request for vulnerabilities
- **Then** the check passes and names the vulnerability as one of main
##### Verified by
- Manual: the same against a base that has it: passed, and named it as already on main.
#### Scenario#62.03: main is checked each night
… so that a vulnerability found anew on main shows within a day.
- **Given** a dependency of main with a known vulnerability of CVSS 4 or more
- **When** Werkator's nightly build checks main
- **Then** the build fails and names the vulnerability
##### Verified by
- Manual: `dependencyCheckAnalyze` without a baseline failed on the same vulnerability.
- Werkator's build `vulnerability-data` on main.
## Solution
- Dependency locking: `dashboard/gradle.lockfile` holds the exact versions of all dependencies;
`./gradlew dependencies --configuration runtimeClasspath --write-locks` writes it after a change of the dependencies.
- The task `checkNewVulnerabilities` reads the report of `dependencyCheckAnalyze`
and fails only on a vulnerability from CVSS 4 in a dependency
that the lockfile of the merge base with main lacks.
It names the others as vulnerabilities of main.
- With the Gradle property `vulnerabilityBaseline`, e.g. `origin/main`, `dependencyCheckAnalyze` reports without failing,
and `checkNewVulnerabilities` decides; without it, `dependencyCheckAnalyze` fails on each vulnerability, as before.
- `.werkator.yml`:
- the build `dependencies` runs for each branch but main, with `-PvulnerabilityBaseline=origin/main`;
- the nightly build `vulnerability-data` loads the NVD data and then checks main in full.
- `doc/agentic-workflow.md`, the master copy: a pull request fails on the vulnerabilities it brings;
main is checked each night, and a vulnerability there is fixed in a pull request of its own.
- `doc/risk-analysis.md` and `AGENTS.md` follow.
- `dependencyCheckAnalyze` always runs: its inputs are neither the resolved dependencies nor the NVD data,
so Gradle took an old report as up to date after a dependency change.
- Version 0.39.0.
## Open Questions
- [x] Shall a vulnerability already on main fail each pull request?
No, chosen by the human: a pull request fails only on the vulnerabilities it brings; main is checked each night.
## Follow-up PRs
- werkregie shows a vulnerability found on main in "Du bist dran".
- The human adds `werkator/dependencies` to the required status checks of the branch protection of `main`.
Gitea requires them of each pull request into main, on the pull request's head, not of commits on main;
main itself is checked by `werkator/vulnerability-data`, which is no required check, since it runs at night.