IP allow list blocks gh CLI in CI, preventing release integrity attestation

[633kh4ck]

Description

When attempting to verify a release using the GitHub CLI in a CI environment, the operation fails due to the IP allow list enforced by the Aqua Security GitHub org.

The following command works locally (with a fine-grained PAT), but fails in CI:

gh release verify v0.69.3 --repo https://github.com/aquasecurity/trivy

Error

HTTP 403: Although you appear to have the correct authorization credentials, the `aquasecurity` organization has an IP allow list enabled, and your IP address is not permitted to access this resource. (https://api.github.com/repos/aquasecurity/trivy/git/ref/tags/v0.69.3)

While an IP allow list is a meaningful security control, in this case, it (likely unintentionally) blocks legitimate, security-relevant use cases, representing a supply-chain security limitation for downstream users:

• This undermines the ability to programmatically verify releases attestations using official tooling (gh release verify)
• As a result, consumers may be forced to:
  • Skip verification entirely, or
  • Implement less reliable or non-standard workarounds

GitHub explicitly promotes release verification as part of securing the software supply chain¹ and references it in its documentation for immutable releases². Please consider relaxing this restriction, or explicitly allowing GitHub-hosted runner CIDR ranges, to permit read-only operations required for release integrity verification of this public repository.

Desired Behavior

Release attestation verification via gh release verify succeeds in CI environment.

Actual Behavior

The request is denied with HTTP 403 due to the organization's IP allow list restrictions.

Reproduction Steps

1. Create a GitHub Actions workflow in an external GitHub organization.
2. Add a job that runs `gh release verify v0.69.3 --repo https://github.com/aquasecurity/trivy`.
3. Run the workflow on a GitHub-hosted runner.
4. Observe the job fail with HTTP 403 from the GitHub API due to the org IP allow list restriction.

Target

None

Scanner

None

Output Format

None

Mode

None

Debug Output

N/A

Operating System

N/A

Version

N/A

Checklist

• Run trivy clean --all
• Read the troubleshooting

Footnotes

1. https://docs.github.com/en/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/verifying-the-integrity-of-a-release ↩

2. https://docs.github.com/en/code-security/concepts/supply-chain-security/immutable-releases#next-steps ↩

[stevehipwell]

Anyone?

[itaysk]

IP restriction is a precautionary step taken while we were remediating the latest security incident. It isn't supposed to affect public repositories or assets. We will re-evalate this restriction soon as we resume normal operation.

As far as I know, the gh release verify command just ensures the release tag is immutable, it doesn't actually ensures enything related to the artifact you are installing. You do the same thing by looking at the release page in the web ui. See here: https://docs.github.com/en/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/verifying-the-integrity-of-a-release?tool=webui

[stevehipwell]

@itaysk we use the API to map latest to a concrete release version via a GitHub Action (and to validate version SemVer inputs), this change has broken a significant number of repositories automation.

I'm also interested in why you think that blocking access to the data that would allow a consumer to spot malicious releases makes sense here?

[itaysk]

We didn't block specific APIs intentionally, unfortunately GitHub doesn't allow this level of granularity.
Can you try to call the API without any authentication? Anonymous calls should go through.

[stevehipwell]

GitHub best practice for calling the API from actions is to always authenticate. The anonymous rate limit is incredibly low (10 IIRC) and given that we're running from GitHub hosted runners the IPs could already be over this limit.

[Wirone]

@stevehipwell We have similar problem - broken Renovate automation. Feels weird to be blocked from wanting to be up-to-date and using latest security checks 😅.

[bored-engineer]

This is a long-standing, very annoying GitHub API bug: if you use GitHub app authentication where the GitHub app is installed on an Organization (apps installed on a User are NOT impacted by this), IP restrictions are incorrectly applied to requests for repository owned by any Organization that has IP allowlists enabled. This is true even when the repository being accessed is public and if the app is installed on a completely unrelated organization. You can work-around it by using a GitHub app installation token for a User (brittle) or use basic auth client_id:client_secret from a GitHub OAuth application (doesn't work for GraphQL), though often neither of these are within the user's control (ex: RenovateBot, GitHub Actions, etc)

[Shikachuu]

Same issue here, both with mise (without lock) or by our custom Action that wraps the Trivy binary for security checks even for an unaffected v0.69.3 🤔

[knqyf263]

This behavior seems problematic to me — blocking authenticated non-member users from accessing public resources appears to provides no security benefit and breaks legitimate use cases like yours. I've opened a discussion on the GitHub community forum to clarify whether this is intentional:
https://github.com/orgs/community/discussions/191185

[kxc171]

This is also a problem for us - we use a couple API requests to pin and verify an image by it's tag, using GH to avoid some Docker calls. We could switch to querying the Docker registry directly, but we've already got a process built around querying GH releases (and related artifacts).

[knqyf263]

We would appreciate it if you could comment on or upvote the discussion below to help increase its priority on GitHub.
https://github.com/orgs/community/discussions/191185

[Wirone]

This IP limitation breaks our automated updates with Renovate. We have scheduled pipeline in GitHub Actions which runs Renovate with a rule:

{
  "customManagers": [
    {
      "customType": "regex",
      "fileMatch": ["^\\.github/workflows/_ib\\.yml$"],
      "matchStrings": [
        "uses:\\s+aquasecurity/setup-trivy@[^\\n]+\\n\\s+with:\\n(?:\\s+.*\\n)*?\\s+version:\\s*'?(?<currentValue>v?\\d+\\.\\d+\\.\\d+)'?"
      ],
      "depNameTemplate": "aquasecurity/trivy",
      "datasourceTemplate": "github-releases",
      "versioningTemplate": "semver-coerced"
    }
  ]
}

to be able to update config like this:

      - name: Install Trivy
        uses: aquasecurity/setup-trivy@v0.2.6
        with:
          cache: true
          version: 'v0.69.2'

We define version explicitly because 'setup-trivy' doesn't currently support caching the 'latest' version, but still want to be up-to-date, hence the custom Renovate rule. Currently it does not work, and we get this "Although you appear to have the correct authorization credentials, the aquasecurity organization has an IP allow list enabled, and your IP address is not permitted to access this resource." error (also with "datasourceTemplate": "github-tags").

Please reconsider this approach, as currently it's limiting our security workflow.