Repository navigation
The npm audit gate scans one of thirteen tracked package.json files, and an unaudited one pinned a vulnerable js-yaml #16131
Description
Activity
- changed the title
[-]The npm audit gate scans one of six workspaces, and an unaudited one pins a vulnerable js-yaml[/-][+]The npm audit gate scans one of thirteen tracked package.json files, and an unaudited one pinned a vulnerable js-yaml[/+]on Sep 9, 2026 Correcting my own count: I wrote "six workspaces". It is thirteen tracked
package.jsonfiles, one audited, twelve not. Title updated.git ls-tree -r --name-only origin/Dev_new_gui | grep -E '(^|/)package\.json$' -> 13 audited (security.yml:261, the only npm audit in the workflow) -> 1 unaudited -> 12I counted directories that looked like npm workspaces instead of enumerating the tracked files. Six is what you get by eye from the top-level layout; it misses both MCP tools directories,
context7, the vscode extension,autobot-infrastructure/shared/config, both plugins, andlibs/autobot-ui.That is this issue's own defect committed while filing it — a query narrower than the thing being counted, reported as if it were the count. The unaudited set is twice what I said, and the half I missed is the half nobody thinks of as a frontend, which is exactly where an unaudited dependency would sit longest.
It also propagated: #16132 inherited the number, corrected it to eleven/twelve, and is still off by one. Flagged there.
This strengthens the acceptance criteria rather than changing them. The criterion that the audited set be discovered rather than listed is now the whole point — a hand-maintained list was wrong on its first day, written by someone looking directly at the problem. Any fix that enumerates directories in the workflow will drift the same way; it has to walk tracked
package.jsonfiles and assert the audited set equals the discovered set, so that adding a workspace fails the gate rather than silently widening the blind spot.- added 17 commits that reference this issue
on Sep 9, 2026 Closing — fully delivered; never auto-closed because Dev_new_gui wasn't GitHub's configured default branch at merge time.
Verified against
origin/main:.github/workflows/security.ymlnow loops overgit ls-files '*package-lock.json'(discovery, not a hardcoded workspace), pinned bytest_the_audit_is_driven_by_discovery_not_a_hard_coded_workspace(repo_tests/npm_audit_covers_its_workspaces_test.py:111) andtest_the_discovery_expression_matches_what_this_test_discovers(:143).autobot-slm-frontend/package.json:39"js-yaml": "4.3.2"— off the advisory's 4.0.0-4.3.1 range, pinned bytest_js_yaml_is_off_the_advisory_range_in_every_lockfile(:187).security.yml:15-22names per-workspace scope explicitly ("All SEVEN with a lockfile are now scanned; one blocks, six report"), with per-workspace gate titles.UNTRIAGEDfrozenset (:35) is enforced shrink-only (test_the_untriaged_list_only_shrinks, :163).Delivered by merged PR #16169.
The gap
.github/workflows/security.yml:261runs the Node audit inside exactly one directory:( cd autobot-frontend && npm audit --audit-level=moderate --json > npm-audit.json ) || trueThe repository has at least six npm workspaces with their own
package.json:It is not hypothetical — there is a live instance
On current
Dev_new_gui:The advisory (GHSA-2883-xcg3-v3hh, high) covers
js-yaml 4.0.0 - 4.3.1.4.3.0is inside it, and it is an exact pin rather than a range, so nothing resolves it upward.We spent several hours today tracing that exact advisory through
autobot-frontend, merging a fix for it (#16129), and confirming it cleared a transitive redocly finding along the way. The same advisory has been sitting unaudited in a sibling workspace the whole time, and no gate reports it because no gate looks.Why it read as clean
Dependency Security Scangoing green means "autobot-frontendhas no unallowed findings". It is read as "the repository's npm dependencies are clean". Those are different claims, and nothing in the check's name, its summary line, or its failure text distinguishes them — the summary at:21even says "0 advisories at every severity across 1191 deps", which describes one workspace's dependency count as though it were the repository's.This is the same shape as #13044, where the duplication guard scanned two of five source trees and a PR touching an ungated tree produced no row rather than a green one. There the fix was to widen the trigger paths and give the newly-scanned trees their own measured threshold.
Acceptance criteria
package.jsonand a lockfile, discovered rather than listed — a hard-coded list is the defect one notch smallerpackage.jsonfiles, so a new workspace fails the check rather than joining the unaudited set silentlyautobot-slm-frontend'sjs-yamlpin is moved off4.3.0; the fix is verified against the advisory range, not against "it installs"security.yml:21should name the workspace it countedRelated
autobot-frontend