werkator build succeeded after 01:47
Co-authored-by: claude-code <claude-code@javagil.de>
96 lines
4.4 KiB
Markdown
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.
|