Skip to content

chore: INFRA-312 unblock the Security + compliance CI gate (npm audit endpoint) #222

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

Closed
MP2EZ wants to merge 1 commit into from
Closed

chore: INFRA-312 unblock the Security + compliance CI gate (npm audit endpoint) #222

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
24 changes: 23 additions & 1 deletion .github/workflows/ci.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -266,7 +266,29 @@ jobs:
# transitive chain; threshold was raised to `high` as an interim
# measure pending the Expo upgrade. audit-ci with an explicit
# allowlist replaces that interim.
run: cd app && npx audit-ci --config .audit-ci.json
#
# INFRA-312 (2026-07-26): pinned to npm >=11 for this step only.
# The job's Node 20 ships npm 10, whose audit uses the LEGACY
# `/-/npm/v1/security/audits/quick` endpoint. That endpoint is being
# retired and now rejects a tree this size with
# `400 Bad Request — Invalid package tree`, which audit-ci surfaces
# only as the useless `code undefined:`. It broke every PR in the
# repo without a single line of app code changing.
# Diagnosis (see INFRA-312 for the full matrix): npm 10 audits a
# ~20-package tree fine and Being's 1,185-package tree not at all;
# npm 11 uses the newer `security/advisories/bulk` endpoint instead.
# The package-lock is NOT stale — `npm install` leaves it
# byte-identical, so npm's "rebuild your package-lock.json" hint is
# a red herring.
# Scoped to this one step deliberately: bumping NODE_VERSION would
# change the toolchain for all 12 jobs to fix one endpoint call.
# Remove this pin once NODE_VERSION moves to a release shipping
# npm >=11 (Node 24+).
run: |
cd app
npm i -g npm@11
npm --version
npx audit-ci --config .audit-ci.json

# Accessibility — WCAG AA validation + a11y test suite. Strict gate
# as of Phase B+C paydown. Root causes addressed:
Expand Down
2 changes: 1 addition & 1 deletion app/.audit-ci.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -13,5 +13,5 @@
"GHSA-v245-v573-v5vm",
"GHSA-mh99-v99m-4gvg"
],
"$comment": "MAINT-182. First three CVEs are transitive through @expo/config-plugins@56.0.8 (build-time only, no patched stable available as of 2026-05-27). GHSA-ph9p (tmp path traversal) and GHSA-6vfc (markdown-it ReDoS) only run during prebuild/codegen. GHSA-w5hq (uuid buffer bounds) is in dev tooling. Review when Expo ships @expo/config-plugins >=56.0.9 stable: drop these GHSAs and verify `npm audit --audit-level moderate` passes. --- MAINT-281 (2026-06-15) added the last two (both quadratic-complexity DoS, no fix in range, require attacker-controlled input which Being has no path for): GHSA-h67p (js-yaml) is dev/build-time ONLY — transitive via ts-jest, @expo/cli/@expo/xcpretty, and babel-jest; fix is a breaking ts-jest major bump. GHSA-6v5v (markdown-it) is runtime via react-native-markdown-display@7, but its ONLY call site renders bundled first-party legal docs (LegalDocumentScreen <- legalContent.generated.ts <- docs/legal/*.md) — no remote/user markdown, so the DoS is unreachable; no patched markdown-it in react-native-markdown-display@7's range. Drop GHSA-6v5v if react-native-markdown-display upgrades markdown-it; drop GHSA-h67p on the next ts-jest major. The high-severity form-data CVE (GHSA-hmw2-7cc7-3qxx) disclosed the same day was FIXED via lockfile (npm audit fix), not allowlisted. --- MAINT-294 (2026-07-08) added GHSA-22p9-wv53-3rq4 (linkify-it 'LinkifyIt#match' scan loop, quadratic-complexity ReDoS, high; range <=5.0.0, fixAvailable:false). Direct twin of GHSA-6v5v: transitive via react-native-markdown-display@7 -> markdown-it@10 -> linkify-it@2.2.0, and its ONLY call site is LegalDocumentScreen rendering bundled first-party legal docs (legalContent.generated.ts <- docs/legal/*.md) — no remote/user markdown, so the quadratic blow-up needs attacker-controlled input Being has no path to. No fix in range (would need breaking markdown-it/react-native-markdown-display majors, risking the expo-modules-jsi@56.0.7 patch pin). Drop GHSA-22p9 together with GHSA-6v5v when react-native-markdown-display upgrades markdown-it/linkify-it past the vulnerable range. --- INFRA-302 (2026-07-21) three new HIGH DoS advisories published to the GitHub DB. Two were FIXED via same-major overrides (not allowlisted): GHSA-395f-4hp3-45gv (shell-quote quadratic parse() DoS) -> shell-quote ^1.10.0 (was 1.8.4, single copy); GHSA-3jxr-9vmj-r5cp (brace-expansion exponential expansion DoS) -> version-keyed overrides pinning the 1.x eslint/jest tooling copies to 1.1.16 and the 5.x copy to 5.0.7. The THIRD, GHSA-52cp-r559-cp3m (js-yaml quadratic merge-key DoS; range <=3.14.2 || 4.0.0-4.2.0, fixAvailable but not in-range for the 3.x path), is allowlisted here as a direct sibling of the already-allowlisted GHSA-h67p (js-yaml, MAINT-281): the top-level js-yaml@3.14.2 consumer has NO same-major fix (all 3.x is vulnerable) and the single GHSA covers both the 3.x and 4.x paths, so a clean override is impossible without a breaking 3->4 major bump of a dev/build-time tooling dep (ts-jest, @expo/cli/@expo/xcpretty, eslintrc, babel-jest). Dev/build-time only, operates on trusted first-party source, no attacker-controlled-input path -> unreachable DoS. Drop GHSA-52cp together with GHSA-h67p on the next ts-jest major (both js-yaml). Also allowlisted GHSA-v245-v573-v5vm (linkify-it, published same window) as a direct sibling of GHSA-22p9/GHSA-6v5v: transitive via react-native-markdown-display@7 -> markdown-it@10 -> linkify-it, whose ONLY call site renders bundled first-party legal docs (LegalDocumentScreen <- legalContent.generated.ts <- docs/legal/*.md) — no remote/user markdown, so unreachable; no fix in range without breaking markdown-it/react-native-markdown-display majors (risks the expo-modules-jsi@56.0.7 patch pin). Drop GHSA-v245 with GHSA-22p9/GHSA-6v5v when react-native-markdown-display upgrades markdown-it/linkify-it past the vulnerable range. --- FEAT-301 (2026-07-25) a NEW brace-expansion advisory GHSA-mh99-v99m-4gvg (unbounded-expansion OOM DoS; range <=5.0.7, HIGH) landed on the exact versions INFRA-302 pinned. The 5.x line (minimatch@10) is bumped to 5.0.8 via overrides (same-major fix). The 1.x line (minimatch@3 under eslint/jest tooling) has NO same-major fix — 1.1.16 is the newest 1.x and is still <=5.0.7, and npm's only offered 'fix' is a breaking jest major downgrade — and the single GHSA covers both the 1.x and 5.x paths, so it is allowlisted here. brace-expansion is transitive via minimatch/glob (Node filesystem tooling), NEVER bundled into the RN runtime, and operates on trusted first-party glob patterns during dev/build/lint/test — no attacker-controlled-input path, so the DoS is unreachable. Drop GHSA-mh99 when the eslint/jest tooling upgrades minimatch@3 -> a brace-expansion line with a >5.0.7 backport (or the 1.x consumers are gone)."
"$comment": "MAINT-182. First three CVEs are transitive through @expo/config-plugins@56.0.8 (build-time only, no patched stable available as of 2026-05-27). GHSA-ph9p (tmp path traversal) and GHSA-6vfc (markdown-it ReDoS) only run during prebuild/codegen. GHSA-w5hq (uuid buffer bounds) is in dev tooling. Review when Expo ships @expo/config-plugins >=56.0.9 stable: drop these GHSAs and verify `npm audit --audit-level moderate` passes. --- MAINT-281 (2026-06-15) added the last two (both quadratic-complexity DoS, no fix in range, require attacker-controlled input which Being has no path for): GHSA-h67p (js-yaml) is dev/build-time ONLY \u2014 transitive via ts-jest, @expo/cli/@expo/xcpretty, and babel-jest; fix is a breaking ts-jest major bump. GHSA-6v5v (markdown-it) is runtime via react-native-markdown-display@7, but its ONLY call site renders bundled first-party legal docs (LegalDocumentScreen <- legalContent.generated.ts <- docs/legal/*.md) \u2014 no remote/user markdown, so the DoS is unreachable; no patched markdown-it in react-native-markdown-display@7's range. Drop GHSA-6v5v if react-native-markdown-display upgrades markdown-it; drop GHSA-h67p on the next ts-jest major. The high-severity form-data CVE (GHSA-hmw2-7cc7-3qxx) disclosed the same day was FIXED via lockfile (npm audit fix), not allowlisted. --- MAINT-294 (2026-07-08) added GHSA-22p9-wv53-3rq4 (linkify-it 'LinkifyIt#match' scan loop, quadratic-complexity ReDoS, high; range <=5.0.0, fixAvailable:false). Direct twin of GHSA-6v5v: transitive via react-native-markdown-display@7 -> markdown-it@10 -> linkify-it@2.2.0, and its ONLY call site is LegalDocumentScreen rendering bundled first-party legal docs (legalContent.generated.ts <- docs/legal/*.md) \u2014 no remote/user markdown, so the quadratic blow-up needs attacker-controlled input Being has no path to. No fix in range (would need breaking markdown-it/react-native-markdown-display majors, risking the expo-modules-jsi@56.0.7 patch pin). Drop GHSA-22p9 together with GHSA-6v5v when react-native-markdown-display upgrades markdown-it/linkify-it past the vulnerable range. --- INFRA-302 (2026-07-21) three new HIGH DoS advisories published to the GitHub DB. Two were FIXED via same-major overrides (not allowlisted): GHSA-395f-4hp3-45gv (shell-quote quadratic parse() DoS) -> shell-quote ^1.10.0 (was 1.8.4, single copy); GHSA-3jxr-9vmj-r5cp (brace-expansion exponential expansion DoS) -> version-keyed overrides pinning the 1.x eslint/jest tooling copies to 1.1.16 and the 5.x copy to 5.0.7. The THIRD, GHSA-52cp-r559-cp3m (js-yaml quadratic merge-key DoS; range <=3.14.2 || 4.0.0-4.2.0, fixAvailable but not in-range for the 3.x path), is allowlisted here as a direct sibling of the already-allowlisted GHSA-h67p (js-yaml, MAINT-281): the top-level js-yaml@3.14.2 consumer has NO same-major fix (all 3.x is vulnerable) and the single GHSA covers both the 3.x and 4.x paths, so a clean override is impossible without a breaking 3->4 major bump of a dev/build-time tooling dep (ts-jest, @expo/cli/@expo/xcpretty, eslintrc, babel-jest). Dev/build-time only, operates on trusted first-party source, no attacker-controlled-input path -> unreachable DoS. Drop GHSA-52cp together with GHSA-h67p on the next ts-jest major (both js-yaml). Also allowlisted GHSA-v245-v573-v5vm (linkify-it, published same window) as a direct sibling of GHSA-22p9/GHSA-6v5v: transitive via react-native-markdown-display@7 -> markdown-it@10 -> linkify-it, whose ONLY call site renders bundled first-party legal docs (LegalDocumentScreen <- legalContent.generated.ts <- docs/legal/*.md) \u2014 no remote/user markdown, so unreachable; no fix in range without breaking markdown-it/react-native-markdown-display majors (risks the expo-modules-jsi@56.0.7 patch pin). Drop GHSA-v245 with GHSA-22p9/GHSA-6v5v when react-native-markdown-display upgrades markdown-it/linkify-it past the vulnerable range. --- FEAT-301 (2026-07-25) a NEW brace-expansion advisory GHSA-mh99-v99m-4gvg (unbounded-expansion OOM DoS; range <=5.0.7, HIGH) landed on the exact versions INFRA-302 pinned. The 5.x line (minimatch@10) is bumped to 5.0.8 via overrides (same-major fix). The 1.x line (minimatch@3 under eslint/jest tooling) has NO same-major fix \u2014 1.1.16 is the newest 1.x and is still <=5.0.7, and npm's only offered 'fix' is a breaking jest major downgrade \u2014 and the single GHSA covers both the 1.x and 5.x paths, so it is allowlisted here. brace-expansion is transitive via minimatch/glob (Node filesystem tooling), NEVER bundled into the RN runtime, and operates on trusted first-party glob patterns during dev/build/lint/test \u2014 no attacker-controlled-input path, so the DoS is unreachable. Drop GHSA-mh99 when the eslint/jest tooling upgrades minimatch@3 -> a brace-expansion line with a >5.0.7 backport (or the 1.x consumers are gone). --- INFRA-312 (2026-07-26) DIAGNOSTIC NOTE, not an allowlist change: if this gate fails with the bare message `code undefined:` and nothing else, that is audit-ci failing to classify an error from npm, NOT a CVE finding \u2014 a real advisory always names its GHSA. Ask npm directly: `cd app && npm audit --audit-level moderate`. The first occurrence (2026-07-26) was npm 10's legacy `/-/npm/v1/security/audits/quick` endpoint returning `400 Invalid package tree` for this ~1,185-package tree while auditing a 20-package tree fine; it blocked every PR in the repo with no app-code change. Fixed by pinning npm>=11 (bulk advisory endpoint) in the CI step. Note npm's accompanying 'run npm install to rebuild your package-lock.json' hint is a RED HERRING \u2014 npm install left the lockfile byte-identical."
}
Loading