Article 14 Gatekeeper

Since 11 September 2026, every manufacturer selling software with digital elements in the EU must report actively exploited vulnerabilities under Article 14 of the Cyber Resilience Act. The deadlines are fixed: an early warning within 24 hours, a notification within 72 hours, and a final report within 14 days of a fix being available. Getting it wrong costs up to €15 million or 2.5% of global turnover. Today this is a manual release chore spread across tools. Someone runs a scanner and gets dozens of advisories. They read each one to guess whether the product is really affected, and paste the findings into a spreadsheet. Then they draft reports in a Word template, while tracking the legal deadlines in a calendar. In our demo product (fattura-lite), 12 advisories came back before the fix and 5 touched code the product actually runs. Both CVE-2020-14343 (CRITICAL, pyyaml 5.3.1, reachable at config.py:8) and CVE-2018-18074 (HIGH, requests 2.19.1, reachable at gateway_client.py:9) were blocking. Every false alarm costs reviewer time, and every missed dependency or deadline is a compliance failure. Article 14 Gatekeeper turns that chore into a release gate: 1. A deterministic core builds a CycloneDX SBOM, pulls advisories from OSV.dev, and merges duplicate GHSA and PYSEC records by CVE. 2. It statically proves reachability, giving file:line evidence for every vulnerable symbol the product uses. 3. It emits OpenVEX: every "not affected" carries a justification. 4. Signals of exploitation, from CISA KEV or the manufacturer's own intake, start the Article 14 clocks and generate draft reports that follow the fields of Art. 14(2). 5. The gate returns PASS or BLOCK as an exit code, so it works in CI, in git hooks and inside the IDE. IBM Bob 2.0 is the operator. In the custom CRA Release Officer mode, Bob runs three subagents in parallel: one fixes the vulnerable code and dependencies, one maps advisories nobody has mapped yet to vulnerable symbols and writes a reviewed VEX justification, and one completes the regulatory drafts. A Bob hook refuses git tag while the gate says BLOCK. A Lessons Ledger records every gate run, and Bob turns causes that recur into rules, so the same class of mistake is not repeated. Impact on the demo product: - The release went from BLOCK to PASS: before the fix, 5 advisories were affected; after, the gate reports 6 advisories and 0 affected. - Time to resolution: about 5 minutes from Bob's first gate run to PASS and the release tag (timed run, bob_sessions/dabii_task05c_timed_take2.md). - Both due Article 14 drafts (early warning and notification) were completed with deadlines computed to the minute, and the 14-day final-report clock started at the fix. By hand, all 12 advisories must be read and every report typed. Limits: Python/pip only; static reachability; the drafts are for a responsible person to submit, not legal advice.