gh-thumper

A GitHub CLI extension to grep for packages affected by Shai-Hulud using a variety of different strategies.

It takes time for vulnerabilities to be acknowledged, published and rolled out across repositories - this tool is a quick attempt at thinking about the 'zero day' problem where you have a raw list of affected packages and want to start remediating your exposure before any of that has happened.

Finding occurrences of ~800 packages across an organization of significant size can be tricky, it will often be challenging to perform the search around rate limits and use of monorepos may make some integrations less practical than others.

This is a very rapidly generated prototype that makes an effort to capture best practice to 'sieve' for results via a few different methods with very basic 'resume' functionality when it hits a backoff, YMMV heavily depending on the organization you're working with.

This implementation assumes you have a CSV of package versions to look for in the form:

package,versions
foo
bar, =4.17.20
baz, = 3.14.1 || = 3.14.2

This is likely not an exhaustive list, it's mostly a collection of things I've encountered in the field.

gh extension install brrygrdn/gh-thumper

Usage: gh thumper <command> [flags]

Experimental GitHub helper commands

Flags:
  -h, --help    Show context-sensitive help.

Commands:
  find-lockfiles --file=STRING <organization> [flags]
    Find lockfiles for an organization

  find-dependencies --file=STRING <org-or-repo> [flags]
    Find dependencies for an organization or repository

  find-sboms --file=STRING <organization> [flags]
    Find SBOMs for an organization

  prepare-code-search --file=STRING <organization> [flags]
    Prepare code search data for an organization or user

Run "gh thumper <command> --help" for more information on a command.

This uses the Code Search API to find the lockfiles that exist in your org which contain the package names.

This search doesn't support regex, so it will pull back a lot of false positives and leave it up to the user to dig further.

Possible extensions:

• Download all found lockfiles into a local cache
• Perform version checking on the cache and output affected repos

This uses a combination of the Rest API and GraphQL API to find all of the JavaScript repositories in your org and then iterate over their manifests' dependency lists to find specific matches.

This approach is very request-heavy and I haven't added any form of resume if processing bails out mid-repo, so it is likely to become 'stuck' when processing monorepositories with thousands of dependencies.

Possible extensions:

• Store the GraphQL co-ordinates after each page so it can resume mid-repository and eventually churn through everything
• A finer code review of Copilot's implementation to look for opportunities to optimise¹

This uses the Rest API for repos to find all of the JavaScript repositories in your org and then calls the Rest API for their SBOM and dumps everything into a directory.

It will only make one attempt to retrieve the SBOM as some monorepos may have an excessively large number of manifests and experience timeouts generating these results.

Possible extensions:

• Generate a PURL for each vulnerable package and then grep the downloaded SBOMs to find matching manifests

This is a slightly unusual strategy, rather than retrieving any data, it will just process your input CSV into links to GitHub's Code Search, using regular expressions to look for specific versions in your lockfiles.

I've found this approach useful for manually checking, but given the breadth of code search there are limitations that may mean it isn't exhaustive.

It is useful for a gut check on impact and can be combined with high-value repositories/parameters to find things to fix first before using another approach.

As noted above, this repository is a collection of experiments in trying to solve this problem using different approaches with various APIs and UIs that exist currently, I do not intend to address issues or develop it further.

• GitHub CLI installed
• Go 1.21 or later

1. Clone the repository
2. Install the extension locally:

   gh extension install .

3. Make changes to main.go
4. Rebuild and test:

   go build && gh thumper

This extension uses gh-extension-precompile to automatically build and publish releases for multiple platforms.

To create a new release:

git tag v1.0.0
git push origin v1.0.0

The GitHub Action will automatically build binaries for:

• Linux (amd64, arm64, 386)
• macOS (amd64, arm64)
• Windows (amd64, 386, arm64)

• Creating GitHub CLI extensions
• go-gh library