Best Practices for Storing Secrets Used by Frogbot
Learn Frogbot JFrog token storage in GitHub secrets and practices that limit secret exposure.
Frogbot uses a JFrog token stored as a GitHub secret to authenticate with the JFrog Platform. GitHub App installations store the token as an organization secret, while manual integrations typically use a repository secret. Workflows in repositories granted access to the secret can use the token, so follow the practices on this page to reduce the risk of misuse.
Token Permissions
Frogbot always requires JFrog Xray, and for SCA scans, it also requires JFrog Catalog permissions.
The following table describes the minimum JFrog token by Frogbot and Xray version.
| Frogbot version | Xray version | Minimum JFrog token |
|---|---|---|
| 3.7.0 or later | 3.155.0 or later | Xray Admin and Catalog Admin |
| Earlier than 3.7.0, or Xray earlier than 3.155.0 | — | Platform Admin |
On Frogbot 3.7.0 or later with Xray 3.155.0 or later, an Xray Admin token with Catalog permissions is sufficient instead of a Platform Admin token. Treat that narrower token as a reason to upgrade Frogbot and Xray, not only as a compatibility note.
If the token isn't a Platform Admin token, pre-create and index the Frogbot repository before the first scan. For more information, see Pre-create the Frogbot Repository.
Secret Scope
- A scoped repository secret is appropriate when only one repository uses the token. That avoids widening exposure.
- A single organization-level secret is appropriate for organization-wide installations. Duplicating a repository secret across many repositories makes revoke and rotate harder if the token is exposed.
GitHub Environments
You can gate Frogbot's workflow execution behind a GitHub environment with required reviewers.
- For Gradle and Maven, a protective environment is required. Dynamic dependency-tree resolution can execute build-plugin code during a scan.
- For every technology in the
scan-pull-requestflow, a protective environment is recommended. That flow uses thepull_request_targettrigger, which exposes secrets to pull-request-triggered runs.
For more information, see Execution Environment for Open Source Repositories.
Rotation and Workflow Access
- You can rotate the token regularly, and immediately on any suspected exposure or when a maintainer with repository or organization access leaves the team.
- You can restrict who can modify
.github/workflows/. That is the only place secret access is granted, so treat changes there with the same scrutiny as production code.
Frequently Asked Questions
These answers cover Frogbot token permissions and GitHub secret handling.
FAQs
Q: What JFrog token permissions does Frogbot need?
A: From Frogbot 3.7.0 and JFrog Xray 3.155.0, the minimum token is Xray Admin and Catalog Admin. Earlier Frogbot or Xray versions require a Platform Admin token. See Token Permissions.
Q: When should I use a repository secret instead of an organization secret?
A: Use a repository secret when only one repository uses the token. Use one organization-level secret for organization-wide installations so you can revoke or rotate it in a single place.
Q: When is a GitHub Environment required for Frogbot?
A: A protective GitHub Environment is required for Maven and Gradle scan-pull-request scans. It is recommended for every technology in that flow because pull_request_target exposes secrets to pull-request-triggered runs. See GitHub Environments.
Q: Why should I rotate the Frogbot JFrog token?
A: GitHub repository and organization secrets are available to anyone who can run a workflow in that scope. Rotate the token regularly, and immediately if you suspect exposure or a maintainer with repository or organization access leaves the team.
Q: Does the scan-pull-request workflow expose GitHub secrets?
A: Yes. Frogbot scan-pull-request uses pull_request_target, which exposes secrets to pull-request-triggered runs. Gate the token behind a GitHub Environment with required reviewers.
Related Topics
Updated 10 days ago