Skip to content

chore(security): review the pip-audit baseline on its due date #421

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
keilynrp merged 1 commit into from
Sep 30, 2026
Merged

chore(security): review the pip-audit baseline on its due date #421

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 7 additions & 7 deletions .github/workflows/security.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -59,10 +59,10 @@ jobs:
# could do two flags' worth of work without anyone noticing: an
# alias that stops matching fails silently, and a flag that matches
# nothing looks identical to a flag that is still holding something
# back. For chromadb's three 2026-08-24 GHSA advisories (aliased to
# CVE-2026-45830/45831/45833), pip-audit's own canonical ID *is* the
# CVE — the PyPA advisory DB has no PYSEC entry for them yet — so
# these three are pip-audit's real output, not an alias regression.
# back. chromadb's three 2026-08-24 advisories were first emitted as
# CVE-2026-45830/45831/45833, before the PyPA DB had PYSEC entries;
# since then pip-audit emits PYSEC-2026-3813/3815/3814, so the flags
# were matching through aliases. Switched at the 2026-09-30 review.
# CVE-2026-49265 (oauthlib, 2026-09-29) arrives only through
# chromadb -> kubernetes -> requests-oauthlib, none of which the
# backend image installs, and it sits in oauthlib's OAuth *server*
Expand All @@ -72,9 +72,9 @@ jobs:
pip-audit -r requirements.lock --disable-pip --no-deps
--ignore-vuln PYSEC-2026-311
--ignore-vuln PYSEC-2026-1325
--ignore-vuln CVE-2026-45830
--ignore-vuln CVE-2026-45831
--ignore-vuln CVE-2026-45833
--ignore-vuln PYSEC-2026-3813
--ignore-vuln PYSEC-2026-3814
--ignore-vuln PYSEC-2026-3815
--ignore-vuln CVE-2026-49265

# ── Frontend dependency audit (blocking; allowlist via wrapper) ─────────
Expand Down
38 changes: 32 additions & 6 deletions docs/operating/SECURITY_GATES.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -313,7 +313,8 @@ per-advisory disposition.
### 7e. pip-audit baseline (`--ignore-vuln` flags in `.github/workflows/security.yml`)

**6 vulnerability IDs ignored** (down from 33 at gate introduction). Owner:
platform owner. SLA: next dependency-upgrade window (review by 2026-09-30).
platform owner. SLA: reviewed quarterly, or sooner when an entry's review date
comes first (last review 2026-09-30; next by 2026-12-31).

@chatgpt-codex-connector chatgpt-codex-connector Bot Sep 30, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Set the next review to the earliest entry deadline

The stated next review date skips the oauthlib exception, whose table row and new review note retain a 2026-10-31 deadline. If operators follow this section-level SLA, that exception will go unreviewed for two months past its deadline; the next review should be 2026-10-31, with 2026-12-31 applying only to the other five entries.

Useful? React with 👍 / 👎.


The previous baseline deferred most entries to "the upgrade sprint", noting in
particular that the starlette CVEs needed a major 0.52 -> 1.x bump. That bump
Expand Down Expand Up @@ -342,13 +343,38 @@ re-verified by running the tool rather than assumed.

| ID | Package (pinned) | Fix version if known | Review date |
| --- | --- | --- | --- |
| PYSEC-2026-311 | chromadb==1.5.2 | none published | 2026-09-30 |
| PYSEC-2026-1325 | ecdsa==0.19.2 | none published | 2026-09-30 |
| CVE-2026-45830 | chromadb==1.5.2 | none published | 2026-09-30 |
| CVE-2026-45831 | chromadb==1.5.2 | none published | 2026-09-30 |
| CVE-2026-45833 | chromadb==1.5.2 | none published | 2026-09-30 |
| PYSEC-2026-311 | chromadb==1.5.2 | none published (1.5.9 still affected) | 2026-12-31 |
| PYSEC-2026-1325 | ecdsa==0.19.2 | none, by upstream policy | 2026-12-31 |
| PYSEC-2026-3813 (CVE-2026-45830) | chromadb==1.5.2 | none published (1.5.9 still affected) | 2026-12-31 |
| PYSEC-2026-3815 (CVE-2026-45831) | chromadb==1.5.2 | none published (1.5.9 still affected) | 2026-12-31 |
| PYSEC-2026-3814 (CVE-2026-45833) | chromadb==1.5.2 | none published (1.5.9 still affected) | 2026-12-31 |
| CVE-2026-49265 | oauthlib==3.3.1 | 4.0.0 (major) | 2026-10-31 |

**2026-09-30 review (the baseline's due date).** Every entry re-checked with
pip-audit 2.10.1, OSV.dev and PyPI:

- **Canonical IDs.** pip-audit now emits the three 2026-08-24 chromadb
advisories as `PYSEC-2026-3813` (CVE-2026-45830), `PYSEC-2026-3815`
(CVE-2026-45831) and `PYSEC-2026-3814` (CVE-2026-45833). The CVE flags were
still holding them, but only through aliases, the failure mode this section
warns about; the flags now use the PYSEC IDs. With them, the audit reports
`No known vulnerabilities found, 8 ignored`, the same as before the switch.
- **chromadb.** The latest release, 1.5.9, is still inside all four advisories'
affected range (`last_affected: 1.5.9`), so no upgrade helps. Still lock-only:
a dry-run install of `requirements.txt` with the lock on 2026-09-29 resolved
97 packages without it.
- **ecdsa: shipped, not reachable.** This entry had a row but no written
disposition. `ecdsa` 0.19.2 *is* in the backend image, pulled in by
`python-jose` 3.5.0. PYSEC-2026-1325 (CVE-2024-23342, GHSA-wj6h-64fc-37mp) is
the Minerva timing attack on ECDSA signing, affecting every version; the
maintainers do not fix side channels in pure-Python code. UKIP never signs or
verifies with an EC key: JWTs are HS256 (`backend/auth.py`, `ALGORITHM`),
`jwt.decode` pins `algorithms=[ALGORITHM]` so an ES* token is refused, and
nothing in `backend/` imports `ecdsa`. Removing it for good means replacing
`python-jose` (for example with PyJWT); that is a dependency change worth its
own issue, not a baseline edit.
- **oauthlib** (below): unchanged, review by 2026-10-31.

**2026-09-29 review: oauthlib, CVE-2026-49265 (GHSA-xpv3-w29h-x7cv).** A
timing side channel in `oauthlib`'s PKCE `code_verifier` comparison
(`oauth2/rfc6749/grant_types/authorization_code.py`, CWE-208), fixed in 4.0.0.
Expand Down
Loading