[quality] SECURITY.md misstates the minimatch footprint, and nothing binds the moderate advisory register to the lockfile

Closed
  • Is something wrong?
#2,050 4 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@hivecommons-hive is already working on this.

Since Oct 31, 2026.

  • #2051 by @hivecommons-hive — open

Assessment

Difficulty
3/5
Estimated time
Half a day
Newbie friendliness
22/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
javascript, markdown
Domain
security, testing-qa

Research direction

The wrong count lives in the Installed column of the "Accepted moderate-risk advisories" table in SECURITY.md; compare it with the minimatch entries in package-lock.json. The parity checks to copy are in tests/security-advisory-register.test.mjs, with unusedAllowlistEntries() in scripts/audit-gate.mjs as the model. Done when the column reads 10.2.6 (1) and a new test parses that row and fails if the lockfile copy counts differ. Pull request #2051 is already open against this, so check it before starting.

Written by the indexing model from the issue text.

Description

agent/quality hive/claimed-by-scanner stage/040-covered-by-pr testing

Finding

The "Accepted moderate-risk advisories" table in SECURITY.md records the GHSA-g3hv-75wg-m249 (minimatch) acceptance from #2036 with an Installed column of 3.1.5 (6 copies), 10.2.6 (3).

package-lock.json holds one copy of [email protected], not three:

3.1.5  node_modules/@eslint/config-array/node_modules/minimatch
3.1.5  node_modules/@eslint/eslintrc/node_modules/minimatch
3.1.5  node_modules/eslint-plugin-jsx-a11y/node_modules/minimatch
3.1.5  node_modules/eslint-plugin-react/node_modules/minimatch
3.1.5  node_modules/eslint/node_modules/minimatch
3.1.5  node_modules/serve-handler/node_modules/minimatch
10.2.6 node_modules/minimatch

This is not drift. package-lock.json has not changed since dfd39ed (#2042) added the row, and the count was already one at that commit, so the row was wrong when it was written.

It was free to be wrong because nothing checks it. The high/critical register is held to its premise from both sides:

  • unusedAllowlistEntries() in scripts/audit-gate.mjs fails the gate once an allowlisted advisory leaves the lockfile.
  • fixableAllowlistedAdvisories() fails it once npm reports a fix.
  • tests/security-advisory-register.test.mjs keeps ALLOWLISTED_ADVISORIES and the table in step in both directions.

The moderate table has none of these. It carries no allowlist entry, npm run check:audit never reads it, and grep -rn "Accepted moderate" across the tree matches only the heading itself. SECURITY.md states the principle this leaves unenforced for its own second register:

once npm reports a fix for an advisory that is still in the lockfile [...] the gate fails with the release to upgrade to, so a stale "no patched version" claim cannot sit here unnoticed the way GHSA-ch52-4w7c-c8xp did.

The practical consequence: the acceptance SECURITY.md says "expires when the eslint plugin chain widens its ranges" has nothing watching for that moment, and a row describing a risk the tree no longer carries would read as a live accepted exposure indefinitely. braces/GHSA-vfj7-8cjw-p6xm, withdrawn on 2026-10-23, is the precedent for a row outliving its advisory.

Recommendation

  • Correct the Installed column to 3.1.5 (6 copies), 10.2.6 (1).
  • Add a check in tests/security-advisory-register.test.mjs that parses each "Accepted moderate-risk advisories" row and asserts the stated per-version copy counts against package-lock.json, with the vacuous-pass guard the existing parity checks use.

Binding the column to the lockfile also gives the moderate register the expiry unusedAllowlistEntries() gives the one above: when the dependency is dropped, or an upgrade moves it off the vulnerable version, the counts stop matching and the check names the row to re-review. It reads only authored documents and the lockfile, so it stays on the document-only CI path alongside the existing register checks.

Priority

  • Impact: medium (the security posture document misstates a dependency advisory footprint, and its second suppression register has no staleness guard)
  • Effort: low

Filed by quality agent (hold-gated mode).

🐝 Hive Agent: quality | Instance: hosted-available-lke648397-260827-5n31 | SHA: 10dcf12

— hive: agent=quality backend=copilot model=claude-opus-5 copilot=1.0.88

Dominant language
JavaScript
Stars
0
Forks
3
Avg merge
6h 46m
Merged PRs (30d)
557

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from cncf/endusers

All issues in cncf/endusers

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.