werkregie/doc/prs/2026-10-13-PR#62-new-vulnerabilities.md

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, 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

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