Welcome to Support Portal

Overview

Bearer tokens used with Aqua Supply Chain Security APIs must include an allowed_endpoints claim that matches how granular RBAC evaluates each route. Tokens minted with ["ANY"] can receive explicit deny responses on Supply Chain v2 repository detail routes while other CodeSec or Supply Chain list endpoints still return HTTP 200 with the same credential.

This article explains the required wildcard form for v2 data-plane access, how pinned branches relate to API visibility, and how to retrieve scan results for non-default branches.

Understanding token scope and Supply Chain v2 APIs

Split behavior across API families

With one bearer token, environments may observe:

Example error body:

{
  "Message": "User is not authorized to access this resource with an explicit deny in an identity-based policy"
}

Supply Chain v2 build/repository endpoints participate in granular RBAC evaluation that expects wildcard action matching in the token, not only a generic "ANY" endpoint label.

Correct allowed_endpoints value

When generating a JWT or API bearer token, use:

"allowed_endpoints": ["ANY:*"]

instead of:

"allowed_endpoints": ["ANY"]

After minting a token with ["ANY:*"], repeat the same GET calls to repository and branch resources; authorized users should receive HTTP 200 with repository and branch payloads.

Pinned branches and non-default branch scan results

What pinning means

In Supply Chain Security, pinning designates a non-default branch (for example, a release line) for continuous posture and baseline tracking alongside the default branch. Pinning supports governance workflows; it does not hide branches from the API.

Retrieving non-default branch data

Repository metadata may include fields such as default_branch and pinned_branches. Branch list responses can include entries similar to:

{
  "branch_name": "main",
  "default_branch": false,
  "pinned_branch": false
}

Non-default, unpinned branches that have been scanned remain retrievable through the API when authentication and allowed_endpoints are correct. Branch pinning is managed in the Supply Chain UI workflows for your tenant; absence of pinned branches in API JSON does not by itself block access to other branches.

Use:

GET /supply_chain/v2/build/repositories/{repo_id}/branches

to enumerate branches, then use the documented scan result endpoints for the branch of interest (per your OpenAPI specification version).

Symptoms

• Programmatic access works for list-style CodeSec APIs but fails for Supply Chain v2 repository or branch URLs.
• Error message references explicit deny in an identity-based policy.
• UI shows scan results for non-default branches, but API calls appear unauthorized.
• Investigation focuses on branch pinning or repository visibility when the underlying issue is token scope.

Solution

• Regenerate the bearer token with allowed_endpoints set to ["ANY:*"] (or the minimum scope your security team approves that includes wildcard action matching for Supply Chain v2, if documented for your environment).
• Retry GET /supply_chain/v2/build/repositories/{repo_id} and .../branches with the new token.
• Fetch scan results for the target branch using the same token and the scan APIs defined in your OpenAPI document.
• If failures persist, verify the user or API key role includes Supply Chain permissions for the target application scope and repositories.

Verification and monitoring

• HTTP 200 from v2 repository and branch endpoints with the updated token.
• Response bodies include expected non-default branches and associated scan metadata.
• Automation uses the same token minting parameters in CI/CD secrets managers to avoid reverting to ["ANY"].

Platform coverage

Related Resources

• Supply Chain Security API – Aqua Docs
• Helpdesk : Aqua Security