Failed to read security insights file due to excess of API rate limit

[gbartolini]

With CloudNativePG we are participating in the Security Slam. We have integrated the OSPS assessement github action, but we get this error:

https://github.com/cloudnative-pg/cloudnative-pg/actions/runs/22569524233/job/65373535225#step:3:107

Thank you for your assistance.

[eddie-knight]

edit: My co-maintainer disagrees with the assessment below, so it's possible that we have a different problem. But we have folks like LFX kicking this off like 30k times per week without issue, so I am hesitant to think this is caused by a bug.

Details

This error should only pop up when there's not a valid GH API token provided. It looks like [this secret](https://github.com/cloudnative-pg/cloudnative-pg/blob/main/.github/workflows/osps_security_assessment.yml#L25) may be misbehaving in your pipeline, or may not have the right scopes.

Here's the token that I was using most recently:

[mnencia]

I've tried to create a dedicated token and give all the permission you explained, but the result is the same: https://github.com/cloudnative-pg/cloudnative-pg/actions/runs/22719093991

[jmeridth]

@mnencia separate issues IMO, but yours is still an issue.

[eddie-knight]

Hey @mnencia the result looks different in the link you provided last. It's getting past the API throttling, at least!

The new issue here is that OSPS-QA-05.01 isn't currently set up to support the largest repos.

Edit:

• Just pointed it at kubernetes/kubernetes and it did produce the same error.
• This was NOT caused by recent changes to OSPS-QA-05.01, I ran with an older commit and got the same error.
• The problem is coming from the change to using IsBinary, reminding me why we removed it a while back. It increases accuracy when it runs, but tips over on large repos.

[eddie-knight]

@jmeridth I tried without avail to find a way to paginate the API call, but I don't think it's supported for this case.

Perhaps we have a fallback heavy-weight assessment step which will pull the repo and scan it locally if it's too large for the API?

As an alternate, I was trying to figure out how Scorecard is doing the binary check. Didn't get very far since I'm not fresh remembering how to navigate that codebase.

[jmeridth]

Having Claude look at https://github.com/ossf/scorecard/blob/main/checks/binary_artifact.go (which I found myself - huzzah!!) it says:

Claude investigation result

Detection Strategy (two-layer approach)

  1. Magic bytes via filetype library (github.com/h2non/filetype)
  - Reads only the first 1024 bytes of each file
  - Uses filetype.Get() to inspect the file's magic bytes/header and determine its type
  - If the detected extension matches the known binary types list → flagged

  2. Extension + non-text fallback
  - If magic bytes don't match, checks the file extension against the same list
  - Additionally runs isText() on the first 1024 bytes — a control-character scan (anything < ' ' that isn't \n, \t, or \r → binary)
  - A file is flagged only if it fails both: extension match AND non-text content

  Known binary extensions checked:
  crx, deb, dex, dey, elf, o, a, so, macho, iso, class, jar, bundle, dylib, lib, msi, dll, drv, efi, exe, ocx, pyc, pyo, par, rpm, wasm, whl

  Special case: Gradle wrapper JARs
  - gradle-wrapper.jar files are excluded if a GitHub Actions workflow using gradle/wrapper-validation-action or gradle/actions/wrapper-validation has a successful run on the latest commit.

  ---
  How it handles large repositories

  The 1024-byte limit per file is the main optimization, but it still iterates every file in the repo via fileparser.OnMatchingFileReaderDo with the glob pattern "*" (matches all files). There's no early exit, no file size cap, and
   no directory exclusion — it walks everything.

  The practical scaling concern: for a repo with thousands of files, it opens and reads up to 1024 bytes from each one. The filetype library's magic byte detection is fast, but the I/O cost scales linearly with file count, all
  happening over the GitHub API (or local FS for local checks). There's no batching limit or concurrency throttle visible at this layer — that would be handled by the underlying RepoClient implementation.

with the last paragraph in the investigation, local cloning may still be the only option for speed. 🤔

[jmeridth]

@eddie-knight you are spot on. Scorecard brings down the repo as a tarball, untars, and then does all file validations locally via TarballHandler.

Claude investigation result

This is the key. Here's the full picture for large repos:

What actually happens

The GitHub client doesn't use the API to fetch files one-by-one. Instead, tarballHandler does this:

1. Downloads the entire repo as a .tar.gz via GitHub's archive URL — the whole thing, in one HTTP request, streamed to a temp file on disk
2. Fully extracts it to a temp directory — every file, written to local disk with io.Copy (no size limit per file, only the decompression bomb comment acknowledges this)
3. Indexes all file paths into handler.files
4. Then listFiles runs the predicate over that in-memory slice
5. Then GetFileReader opens each matched file from the local temp dir with os.Open

So for a large repo, the binary artifact check:
- Downloads and fully extracts the entire repo to disk before any file is inspected
- Has no file count limit, no repo size limit, no timeout at this layer
- The comment at the decompression bomb risk (//nolint:gosec) explicitly acknowledges this: "Since such an attack will only impact a single shard, ignoring this for now" — meaning they're aware but accept it as a single-shard DoS
 risk
- Then opens every non-testdata file sequentially, reading 1024 bytes from each for the filetype check

The 1024-byte read limit in checkBinaryFileReader is essentially irrelevant from a performance standpoint — the bottleneck is downloading and fully extracting the tarball upfront. A repo with gigabytes of history or thousands of
large files will cause significant disk and time pressure before the check logic even starts

Based on my human reading it does this no matter the repo size.