T-24: Prove It Before the CRA Clock Runs Out

The problem. Since 11 September 2026, the EU Cyber Resilience Act (Article 14) requires every manufacturer selling software in the EU to send ENISA an early warning within 24 hours of learning that a vulnerability in their product is actively exploited, a notification within 72 hours, and a final report within 14 days. Missing these duties can cost €15 million or 2.5% of worldwide turnover. The clock starts before the hard question is answered: are we even affected? Dependency alerts name a library, not a code path. Engineers grep, read advisories, and argue for hours, and most alerts turn out to concern functions the product never calls. The result is either wasted emergency releases or, worse, a confident "not affected" that is wrong. The solution. T-24 turns that triage into minutes of evidence. An LLM reads the published advisory and extracts the vulnerable symbols. It never decides anything: any symbol not found word for word in the advisory is dropped, and version ranges always come from the published record. A deterministic engine decides the verdict. It checks the installed version, builds an AST call graph of the product from its real entry points, and scans the library's own source for internal callers. The output is an OpenVEX verdict per advisory, with the exact evidence path (file, line, function) or the exact reason it cannot be proven. For an actively exploited finding, T-24 starts the CRA clock and drafts the ENISA early warning and notification, citing file:line evidence in every claim, marked for human review. An IBM Bob custom mode and skill then write a failing regression test, apply the fix, prove the test passes, and rescan to mark the finding fixed, while the reporting clock keeps running, because the Act still requires the reports after a patch. Demo results. On a Flask service pinned to four real vulnerable libraries, one scan with a live model took 16 seconds (about 1 second replayed from cache): PyYAML CVE-2020-14343: affected, via app.py:14 upload_config to config.py:5 yaml.full_load. The regression test sends a real exploit payload; the vulnerable app returns "EXPLOITED-42", the fixed app rejects it. Pillow CVE-2023-50447 and Jinja2 CVE-2024-22195: not affected, proven. Two emergency releases avoided. requests CVE-2023-32681: under investigation, because requests calls the vulnerable function internally (sessions.py:245). Simply trusting the code path would have produced a false "not affected" here; the deterministic library-caller check caught it. Why it is trustworthy. "Not affected" requires every file to parse, no dynamic access such as getattr or importlib, no product path to the symbol, and no internal caller in the library. Otherwise T-24 says "under investigation" and shows why. We attacked our own engine with 19 adversarial projects; every false "not reached" became a test (166 tests in total). Impact. Security teams answer "are we affected?" with proof in seconds instead of hours, avoid needless emergency releases, and meet a legal 24-hour deadline with regulator-ready drafts backed by code evidence.