Repository navigation
fix(deps): move pyjwt and brace-expansion off versions with new advisories - #686
Merged
Merged
Conversation
…ories Advisories published 2026-09-29 made main's own scan fail. Every open PR inherits the failure because none of their diffs touch these packages. pyjwt 2.13.0 -> 2.15.1 in uv.lock. It is transitive via mcp[crypto], whose range (>=2.10.1) already allows the fix, so this is a lock refresh plus a >=2.14 floor in pyproject.toml, matching how cryptography is floored. That clears ten advisories, GHSA-ffc3-869f-jxw9 (critical) among them; 2.14.0 is the first patched release for all ten. brace-expansion, via `npm update brace-expansion` in each tree. The parent ranges already allowed the patched releases, so no override was needed: deploy/cdk: 1.1.18 -> 1.1.21 deploy/cdk-constructs: 5.0.9 -> 5.0.12, test-exclude's copy 2.1.4 -> 2.1.7 That clears GHSA-6j4f-fj2g-mc7p, GHSA-qhr7-859c-m2p7 and GHSA-q2hr-2g5m-vwhr for those copies. npm also rewrote some lockfile metadata: it added `engines` from package.json and corrected `dev` flags on five deploy/cdk entries whose only dependents are dev dependencies. Not fixed: the brace-expansion 5.0.9 that aws-cdk-lib bundles in both trees. Every aws-cdk-lib release through 2.272.0 (the current latest) ships 5.0.9, and npm `overrides` cannot rewrite a bundled dependency (tested). The upstream fix is aws/aws-cdk#38929.
Contributor
ASH Security Scan Report
Scan Metadata
SummaryScanner ResultsThe table below shows findings by scanner, with status based on severity thresholds and dependencies:
Report generated by Automated Security Helper (ASH) at 2026-09-30T15:18:15+00:00 |
…aws-cdk-lib aws-cdk-lib bundles brace-expansion 5.0.9 (GHSA-6j4f-fj2g-mc7p, GHSA-qhr7-859c-m2p7, GHSA-q2hr-2g5m-vwhr). No aws-cdk-lib release ships a fixed copy (2.272.0 checked), and npm overrides cannot rewrite a bundled dependency, so the repository cannot remove it. Upstream: aws/aws-cdk#38929 and aws/aws-cdk#38932. The maintainer approved accepting the risk until 2026-10-30. Every entry expires then. Entries, keyed the way each scanner reports the finding: - grype, in .ash/.ash.yaml: <GHSA>-brace-expansion on deploy/cdk/package-lock.json - npm-audit, in .ash/.ash.yaml: <GHSA> on node_modules/aws-cdk-lib/brace-expansion/package.json. That is the path npm-audit gives only the bundled copy. - trivy-repo, in .ash/.ash_community_plugins.yaml: the CVE aliases on deploy/cdk/package-lock.json Known limit: ASH matches on rule id, path and line range only. The grype and trivy entries therefore cover these three advisories for any brace-expansion copy in deploy/cdk/package-lock.json, not only the bundled one. Today the bundled copy is the only vulnerable one left there. The npm-audit entry has no such gap. These entries should be tightened once ASH can match on package and version.
awsmadi
marked this pull request as ready for review
September 30, 2026 15:49
awsmadi
added a commit
that referenced
this pull request
Sep 30, 2026
…ackage copy The nine time-boxed entries #686 added for the brace-expansion 5.0.9 that aws-cdk-lib bundles matched on rule id and path only. For grype and trivy-repo that covered the three advisories for any brace-expansion copy in deploy/cdk/package-lock.json, so a vulnerable copy reintroduced there before 2026-10-30 would have been hidden. Each entry now also sets package_name, package_version and package_path, so it matches only the bundled copy. grype and trivy-repo stay on deploy/cdk. npm-audit reports the same path for the bundled copy in both CDK trees, so its three entries become six, one per tree. Expiration and the risk-acceptance text are unchanged.
awsmadi
added a commit
that referenced
this pull request
Oct 1, 2026
* feat(suppressions): match a suppression to one package copy A suppression could match only rule ID, path and line range. For dependency findings that is not enough: grype puts every finding at line 1 of the lockfile, so brace-expansion 1.1.18 and the 5.0.9 bundled inside aws-cdk-lib were identical on every matchable field, and suppressing one copy hid the advisory for every copy in the lockfile. Suppressions gain three optional fields, package_name, package_version and package_path. Each one that is set must match; a finding that does not report it does not match, so a scanner that cannot identify the copy leaves the finding visible. Entries without the fields match exactly as before and keep their existing id. The identity was being lost in the converters, so they now write it into result.properties: - grype: name and version from grype's per-result message; package_path when the name and version occur once in an npm lockfile. Two entries with the same name and version get no path, because grype's output cannot say which one it found. - npm-audit: version from the lockfile (installed_version held the advisory range) and package_path from each node. Each lockfile's audit output is converted on its own; the merged dict was keyed by package name, so a package vulnerable in two lockfiles kept only the last lockfile's nodes. - trivy-repo: name and version from the message; a result that trivy merged across two copies of the same version is split into one result per copy, each with package_path resolved from the lockfile line. URIs are unchanged so existing path-based suppressions keep matching. The unused-suppressions report and the config linter include the package fields in the suppression id so two entries that differ only by package stay distinct. * fix(suppressions): scope the bundled brace-expansion entries to one package copy The nine time-boxed entries #686 added for the brace-expansion 5.0.9 that aws-cdk-lib bundles matched on rule id and path only. For grype and trivy-repo that covered the three advisories for any brace-expansion copy in deploy/cdk/package-lock.json, so a vulnerable copy reintroduced there before 2026-10-30 would have been hidden. Each entry now also sets package_name, package_version and package_path, so it matches only the bundled copy. grype and trivy-repo stay on deploy/cdk. npm-audit reports the same path for the bundled copy in both CDK trees, so its three entries become six, one per tree. Expiration and the risk-acceptance text are unchanged. * fix(suppressions): make package_path scan-root-relative POSIX on Windows On the Windows scan leg the three bundled brace-expansion grype findings stayed actionable while the same entries matched on Linux and macOS. grype on Windows reports a lockfile as the scan root followed by a backslashed relative path (D:/a/<repo>/<repo>/\deploy\cdk\package-lock.json). The grype converter built package_path from that URI before sanitize_sarif_paths relativized the location, and install_path only swapped backslashes and stripped a leading slash, so the SARIF carried D:/a/<repo>/<repo>/deploy/cdk/node_modules/aws-cdk-lib/node_modules/brace-expansion and no suppression written relative to the scan root could match it. - package_identity.scan_relative_path parses a scanner URI with the scan root's own path flavor (Windows rules for a Windows root, POSIX otherwise), makes it relative to the root, and returns POSIX form, or None when the location is outside the root so no path is claimed. grype and trivy-repo now go through it. install_path no longer rewrites backslashes; its input is already POSIX. - apply_suppressions_to_sarif strips an absolute source-dir prefix from package_path the same way it does for the location URI, so SARIF from an older converter still compares in relative form. - _path_pattern_matches, used for suppression path and package_path, treats a backslash as a separator on both sides and compares with fnmatchcase. fnmatch.fnmatch's normcase made "deploy\cdk\x" match "deploy/cdk/x" on Windows only. npm-audit was not affected: it relativizes its own lockfile Path with relative_to(...).as_posix() and never reads a scanner-reported URI.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
mainfails its own scan right now. Advisories published on 2026-09-29 (18:23Z to 23:45Z) cover pyjwt 2.13.0 inuv.lockand brace-expansion in both CDK lockfiles. Every open PR inherits that failure on itsscan (...)legs, because none of their diffs touch these packages. They will stay red until this lands, so merge this first and let the others rebase onto it.What changes
mcp[crypto])uv.lockdeploy/cdk/package-lock.jsondeploy/cdk-constructs/package-lock.jsondeploy/cdk-constructs/package-lock.jsonpyjwt:
mcpalready allows the fix (>=2.10.1), so this isuv lock --upgrade-package pyjwtplus apyjwt>=2.14,<3floor inpyproject.toml, the same waycryptographyis floored. brace-expansion:npm update brace-expansionin each tree. Every parent range already admits the patched release, so nooverridesare needed. npm also rewrote some lockfile metadata. It addedenginesfrompackage.jsonand correcteddevflags on fivedeploy/cdkentries whose only dependents are dev dependencies.The first commit changes no suppression, ignore rule, threshold or scanner configuration. The second commit adds only the time-boxed suppressions described below.
What this does not fix
aws-cdk-libbundles brace-expansion 5.0.9 (node_modules/aws-cdk-lib/node_modules/brace-expansion,inBundle: true) in both trees. Every release through 2.272.0, the current latest, ships 5.0.9; I checked by unpacking the 2.272.0 tarball. npmoverridescannot rewrite a bundled dependency. I tested that on a copy of the lockfile, and the bundled entry stayed at 5.0.9. The upstream fix is aws/aws-cdk#38929 (tracking issue aws/aws-cdk#38932). Without a suppression, grype, npm-audit and trivy-repo each report 3 findings (2 high, 1 medium) against that bundled copy.Time-boxed risk acceptance: expires 2026-10-30
The maintainer approved accepting the bundled copy's three advisories until 2026-10-30. The second commit adds nine suppressions, all with
expiration: "2026-10-30". Each one is keyed the way its scanner reports the finding:.ash/.ash.yamlGHSA-6j4f-fj2g-mc7p-brace-expansion,GHSA-qhr7-859c-m2p7-brace-expansion,GHSA-q2hr-2g5m-vwhr-brace-expansiondeploy/cdk/package-lock.json.ash/.ash.yamlGHSA-6j4f-fj2g-mc7p,GHSA-qhr7-859c-m2p7,GHSA-q2hr-2g5m-vwhrnode_modules/aws-cdk-lib/brace-expansion/package.json.ash/.ash_community_plugins.yamlCVE-2026-102276,CVE-2026-102278,CVE-2026-102277deploy/cdk/package-lock.jsonGrype and trivy report the bundled copy only in
deploy/cdk, because indeploy/cdk-constructsit is a dev dependency and neither scanner catalogs dev dependencies there. npm-audit reports it in both trees, at the path above.Known limit. ASH's suppression matcher compares only rule id, path and line range. It cannot match on package version. Grype reports the bundled 5.0.9 and any other brace-expansion copy with the same rule id, the same lockfile path and line 1. So the grype and trivy entries cover these three advisories for any brace-expansion copy in
deploy/cdk/package-lock.json. Today the bundled copy is the only vulnerable one left there. A vulnerable copy reintroduced into that lockfile before 2026-10-30 would be hidden from grype and trivy-repo. It would still fail npm-audit, whose entry matches only the bundled path. Control 4 below measures this. The follow-up is package-aware suppression matching in ASH, and these entries get narrowed once that lands.Controls, each run with
ash scanon a throwaway copy of this branch's tree:deploy/cdk/package-lock.jsondeploy/cdkroot brace-expansion 1.1.18The committed configs are byte-identical to control 1's.
ash config validatepasses on both files.Verification
Measured locally with grype 0.111.0 (DB built 2026-09-30T06:32:47Z), trivy 0.69.3 and npm 10.9.4. The grype and trivy versions match what CI pins.
main(e678ec0f)ash scan --scanners grype,npm-auditnpm audit,deploy/cdknpm audit,deploy/cdk-constructsThe ASH numbers on
mainmatch what CI reports on the failing legs. syft catalogs 197 packages fromuv.lock(197[[package]]entries) and 42 from the transpiler'suv.lock(42 entries), so the zero pyjwt count comes from the updated version and not from a scan that skipped the file.Tests:
uv run --extra cdk pytestgave 8083 passed, 138 skipped, 3 xfailed. The one failure came from a.jsiifile that my localnpm run buildofdeploy/cdk-constructsleft behind. It passed after I deleted the file.deploy/cdk:npm ci,npm run buildandnpm testgave 470/470 tests in 15 suites.deploy/cdk-constructs:npm ci,npm run build(jsii) andnpm testgave 116/116 in 3 suites.With the suppressions in place,
uv run --extra cdk pytestgives 8084 passed, 138 skipped, 3 xfailed and 0 failed.I committed the first commit with
SKIP=pretty-format-json,ash. The second commit ran every hook, including the localashscan, and all of them passed.pretty-format-jsonsorts keys, and on these files it rewrote about 4,000 lines of npm's lockfile layout. The localashhook exits 2 on the bundled finding described above. Every other hook ran and passed.None of the open dependabot PRs (#683, #658, #637) touches pyjwt or brace-expansion.