# 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.