# Dependency vulnerability ignore list for AiSOC CI.
#
# Format: tool|ID|reason|YYYY-MM-DD
#   tool   — pnpm, python, or go
#   ID     — CVE-YYYY-NNNNN, GHSA-xxxx-xxxx-xxxx, GO-YYYY-NNNN, or PYSEC-YYYY-N
#   reason — why this ignore is acceptable (required, no blanks)
#   expiry — date this ignore expires (max 90 days from today)
#
# Example:
# python|CVE-2026-12345|Upstream fix not released; tracked in issue #123|2026-07-15

# ── 2026-09-23 re-triage — the list is now empty ─────────────────────────────
# All 42 entries that stood here were re-verified against OSV and against the
# versions the repo actually resolves, rather than against the claims in their
# own reason strings. Every one of them was resolvable, so none was carried
# forward. Nothing is suppressed today.
#
# The entries were re-checked ahead of the 2026-10-05 ecdsa expiry because
# `load_ignores` fails closed: a lapsed entry aborts `validate-ignores` before
# any ecosystem is scanned, which reds every open PR and leaves `main`
# stale-green. That has happened here before (twelve expired suppressions,
# #650), so the list is re-read on a schedule rather than on a failure.
#
# Recording what was measured, because most of these reason strings had
# quietly stopped being true and re-reading them would have produced another
# round of date bumps rather than fixes:
#
#   • starlette (9 entries) claimed "slack-bot and teams-bot still cap fastapi
#     <0.137, which resolves fastapi 0.136.1 / starlette 1.0.0". Neither cap
#     exists: both pyproject files read fastapi >=0.111,<0.142 and both locks
#     resolve fastapi 0.141.1 with starlette 1.6.0. services/agents resolves
#     starlette 1.3.1. The highest fix among the nine is 1.3.1, so every
#     service was already clean.
#
#   • idna CVE-2026-45409 claimed "only services/slack-bot still resolves
#     3.13". slack-bot resolves 3.20, teams-bot 3.15, agents 3.18; the fix is
#     3.15. (The CVE id is also not a resolvable OSV record — OSV carries this
#     as GHSA-65pc-fj4g-8rjx / PYSEC-2026-215 with the CVE as an alias.)
#
#   • langchain / langgraph (9 entries) claimed pins of langchain <0.4.0,
#     langchain-openai <0.4.0 and langgraph <1.1.0 blocking a "0.3 to 1.x
#     migration". That migration has already happened: the pins read
#     langchain >=1.3.9, langchain-core >=1.2.22, langgraph >=1.0.10,
#     langgraph-checkpoint >=4.1.1, langgraph-sdk >=0.3.15, and the lock
#     resolves 1.4.2 / 1.6.4 / 1.2.12 / 4.2.0 / 0.4.5 respectively.
#     langchain-text-splitters (PYSEC-2026-77) is not in the tree at all.
#
#   • langchain-core (4 entries) claimed the same blocked major bump. The lock
#     resolves 1.6.4; the fixes are 1.2.11 and 1.2.22.
#
#   • weasyprint (3) and anyio (5) claimed they were "pinned by the committed
#     services/agents lock, needs a lock refresh". That lock already carries
#     weasyprint 70.0 and anyio 4.15.1, which are the fixed versions.
#
#   • pydantic-settings claimed "slack-bot/teams-bot still resolve 2.14.1".
#     Both resolve 2.15.0; the fix is 2.14.2.
#
#   • cryptography (3 entries) claimed the fix was "held by the <50 and <49
#     version caps". No such cap exists anywhere — every pin reads <51 — and
#     services/agents resolves 50.0.1, which is the fixed line.
#
#   • aiohttp (3 entries) claimed 3.14.1 awaiting a lock refresh; the locks
#     resolve 3.14.3, which is the fix. h2 claimed 4.3.0; agents resolves
#     4.4.1, which is the fix.
#
#   • image-size (2 pnpm entries) claimed the advisory "reports no patched
#     release (patched_versions "<0.0.0"), so an override has no clean
#     target". GHSA-5p2g-fcmc-qvqq and GHSA-w3rx-r6r6-pgpr both record a
#     vulnerable range of "<= 2.0.2", and npm has published 2.0.3 and 2.0.4;
#     OSV reports both as unaffected. `first_patched_version` being null in
#     the GitHub advisory is not the same claim as no fix existing, and
#     reading it as such kept two high-severity advisories suppressed for a
#     fix that was already on the registry. A pnpm override now pins
#     >=2.0.4 <3, which @docusaurus/mdx-loader's ^2.0.2 range accepts.
#
#   • ecdsa PYSEC-2026-1325 (CVE-2024-23342, Minerva timing attack on P-256)
#     was the one entry whose "no patched version available" was true: OSV
#     records the affected range as introduced at 0 with no fixed event,
#     because upstream states python-ecdsa offers no side-channel resistance
#     and will not fix it. It was also true that ecdsa was unconditional under
#     python-jose. So the dependency was removed instead of re-suppressed:
#     services/api now uses PyJWT, which it already depended on for the OIDC
#     and SAML paths, and python-jose, ecdsa and rsa all leave the tree.
#
# Verification for the empty list: all 20 Python targets were exported exactly
# as `run_pip_audit` does and every resolved pin checked against OSV — zero
# advisories, zero unscanned. `pnpm audit` reports zero advisories with the
# image-size override (two high without it). `govulncheck` reports zero
# findings across all six Go modules.
#
# Add entries back only with a justification that names the version actually
# resolved and the fix that is genuinely out of reach. An expiry is a
# re-review date, not a snooze.

# ── 2026-09-24 — apps/mobile, a second install root the audit never saw ──────
# The two image-size entries below look like the pair dismissed above and are a
# different case. That one was @docusaurus/mdx-loader holding ^2.0.2 in the root
# workspace, where 2.0.4 is a drop-in. This one is metro, and the fix really is
# out of reach:
#
#   • apps/mobile resolves image-size 1.2.1, pulled only by metro 0.83.3.
#   • No patched 1.x exists — 1.2.1 is the last 1.x and the fix landed in 2.0.3.
#   • Every metro release through the current latest (0.87.1) still declares
#     image-size ^1.0.2.
#   • metro/src/Assets.js calls the callable default export at lines 68 and 173
#     — `(0, _imageSize.default)(content)` — which image-size 2.x replaced with
#     named exports. An override here does not bump a version, it breaks asset
#     resolution at bundle time.
#   • Dependabot's own updater reaches the same verdict independently:
#     security_update_not_possible, latest-resolvable 1.2.1,
#     lowest-non-vulnerable 2.0.3, conflicting-dependencies [].
#
# Both advisories are denial of service only (CVSS A:H, C:N/I:N) via infinite
# loops in the JXL/HEIF and ICNS parsers. Reaching them needs a malicious image
# inside this repository's own asset tree, which presupposes commit access, and
# the impact is a hung developer bundler. No runtime, server or user-input path
# reaches this code.
#
# Why they were invisible rather than accepted is the part worth keeping:
# `pnpm audit` ran only at the repo root, and apps/mobile is a deliberately
# separate install root, so this arm reported a clean workspace while two high
# advisories stood open. run_pnpm_audit now discovers every directory holding a
# pnpm-lock.yaml, so a third install root is covered the day it appears rather
# than the day someone remembers it exists.
#
# Retire these when metro adopts image-size >= 2.0.3.
pnpm|GHSA-5p2g-fcmc-qvqq|apps/mobile resolves image-size 1.2.1 through metro 0.83.3; no 1.x fix exists, metro through 0.87.1 still requires ^1.0.2, and image-size 2.x drops the callable default export metro calls in Assets.js. DoS-only and build-time, reachable only from an image already committed to this repo|2026-12-23
pnpm|GHSA-w3rx-r6r6-pgpr|apps/mobile resolves image-size 1.2.1 through metro 0.83.3; no 1.x fix exists, metro through 0.87.1 still requires ^1.0.2, and image-size 2.x drops the callable default export metro calls in Assets.js. DoS-only and build-time, reachable only from an image already committed to this repo|2026-12-23

# ── 2026-10-01: a third apps/mobile entry, for an advisory with no fix ─────
#
# The two image-size entries above are the same shape and the same
# reasoning: a build-time dependency of the React Native app, excluded from
# the workspace, with no upstream fix. This is the third.
#
# GHSA-86w9-cpqp-85rv, node-forge RSA PKCS#1 v1.5 signature verification
# accepts extra nested DigestAlgorithm elements. High severity, published
# while this batch was in flight: the same branch passed `security-audit` at
# 23:49 and failed at 00:01 with no dependency change.
#
# Three facts, each checked rather than asserted:
#
#   1. **There is no patched version.** The advisory's
#      `first_patched_version` is null, so this cannot be resolved by a
#      bump. That is why it is suppressed rather than fixed.
#
#   2. **It is in no AiSOC service image.** `node-forge@1.4.0` is
#      transitive via `@expo/cli` and `@expo/code-signing-certificates`
#      inside `apps/mobile`, which `pnpm-workspace.yaml` excludes with
#      `"!apps/mobile"` and which appears in no Dockerfile. The root
#      lockfile does not contain it at all.
#
#   3. **`apps/mobile` releases through an app store**, not this
#      repository, and the Expo CLI is build-time tooling for that release.
#
# Deliberately NOT scoped out of the audit instead: `apps/mobile` is real
# released code and `pnpm_install_roots` scans every lockfile on purpose, so
# excluding it would hide every future advisory there.
pnpm|GHSA-86w9-cpqp-85rv|No patched version exists upstream. Transitive via @expo/cli in apps/mobile, which pnpm-workspace.yaml excludes and no Dockerfile builds; absent from the root lockfile and from every service image.|2026-12-29
pnpm|GHSA-ch52-4w7c-c8xp|No patched version exists: npm's latest http-cache-semantics is 4.2.0 and the advisory affects <=4.2.0. Reached only through the docs site's update check (@docusaurus/core -> update-notifier -> latest-version -> package-json -> got -> cacheable-request), which runs on the runner during a Pages build. No Dockerfile builds apps/docs and @docusaurus/core appears in no other package.json, so it is in no shipped image. The flaw is cross-user cache disclosure in a shared HTTP cache; this path makes one registry request in a single-tenant CI job.|2026-12-31
pnpm|GHSA-vfj7-8cjw-p6xm|No patched version exists: npm's latest braces is 3.0.3 and the advisory affects <=3.0.3. Stack-exhaustion DoS (CWE-674) triggered by expanding a deeply nested glob pattern. Reached only transitively through chokidar and micromatch, which are build tooling; neither is a direct dependency of any package here, and the patterns they expand come from this repository's own build configuration rather than from user input. No runtime route accepts a glob.|2026-12-31

# ── 2026-10-06 security-bump PR — unfixable-upstream carry-forward ──────────
# Verbatim from OSV on 2026-10-06: both advisories have NO first_patched_version.
# braces is a transitive dev/test-tree dep (jest/micromatch lineage); the repo
# pins overrides but there is nothing to override TO yet.
pnpm|CVE-2026-93687|braces <=3.0.3; OSV GHSA-vfj7-8cjw-p6xm shows no patched release (current is newest); transitive test-tree dep; re-check monthly|2027-01-04
pnpm|CVE-2026-97058|sprintf-js <=1.1.3; OSV GHSA-hp3w-g68c-fv3c shows no patched release (current 1.0.3 is newest); transitive via js-yaml in jest tooling; re-check monthly|2027-01-04
# apps/mobile workspace (its own lockfile): node-forge is expo tooling transitive;
# OSV shows no patched release for all three as of 2026-10-06.
pnpm|CVE-2026-85393|node-forge <=1.4.0 in apps/mobile; OSV GHSA-86w9-cpqp-85rv has no patched release; expo tooling transitive; re-check monthly|2027-01-04
