For the complete documentation index, see llms.txt. This page is also available as Markdown.

Actions Secret

The Action Secrets section in StepSecurity allows you to monitor, manage, and track GitHub Actions secrets across an entire organization or within specific repositories.

This helps ensure secure storage and proper usage of sensitive information, such as API keys, tokens, and credentials used within workflows.

To access these features, open your StepSecurity dashboard and navigate to the Action Secrets section. The page has two tabs: Organization Secrets and Repository Secrets.

Organization Secrets

  • Provides a centralized view of all secrets used across repositories.

  • Tracks the last rotation date of secrets, helping enforce regular updates for security.

Repository Secrets

The Repository Secrets tab lists secrets specific to individual repositories, along with rotation age, usage status, and OIDC replaceability.

Summary cards

At the top of the tab, summary cards give you an at-a-glance view of your cleanup opportunities:

  • Total Secrets: every repository secret across the organization.

  • Unused Secrets: secrets no workflow references. Strong candidates for removal.

  • Stale Secrets: secrets whose referencing workflows have not run in over 90 days.

  • OIDC Replaceable: secrets that could be replaced with OpenID Connect (OIDC) authentication, eliminating the need to store the secret at all.

Usage status

Each secret is assigned one of four statuses:

Status
Meaning

Active

The secret is referenced by at least one workflow, and one of those workflows ran within the last 90 days.

Stale

The secret is referenced by a workflow, but none of the referencing workflows have run in the last 90 days. The secret may be a leftover from a retired pipeline.

Unused

No workflow in the analyzed repositories references the secret. It is a strong candidate for removal.

Unknown

The repositories that could use this secret have not been analyzed for secret references yet, so usage cannot be determined. This clears automatically once analysis runs.

The 90-day window is based on the most recent run of any workflow that references the secret. The last run time of each referencing workflow is shown in the Used in Workflows column, so the most recent of these is the secret's effective last-used time.

The Unused status considers only the workflows that StepSecurity has analyzed. A secret consumed outside of GitHub Actions (for example, by an external system reading it through the API) is not counted as a workflow reference

Where each secret is used

For every secret, the dashboard lists the workflows that reference it. Expand a secret row to see the full list of referencing workflows, each with:

  • The repository and workflow file where the reference was found.

  • The Action (uses: value) of the step that consumes the secret, so you can see exactly which Action reads a given secret.

  • The last run of that workflow, including its conclusion and a link to the run on GitHub.

How references are detected

StepSecurity analyzes your workflow YAML to find every way a secret can be read:

  • Direct references such as secrets.NPM_TOKEN.

  • Bracket references such as secrets['NPM_TOKEN'].

  • Bulk references such as toJSON(secrets) and dynamic lookups such as secrets[matrix.environment]. These expose every secret in scope, so they are attributed to all secrets the workflow can access.

The analysis also follows reusable workflow calls made with secrets: inherit, so a secret used only inside a called workflow is still attributed correctly. References to the automatically provided GITHUB_TOKEN are excluded, since it is not a configured secret.

OIDC recommendations

Static, long-lived secrets such as cloud credentials and registry tokens are a common source of supply chain risk. Many of them can be replaced with OIDC, where GitHub issues a short-lived token for each workflow run and no static secret is stored at all.

The dashboard flags a secret as OIDC Available when either of the following is true:

  • The secret is passed to an Action that supports OIDC federation:

    • aws-actions/configure-aws-credentials (AWS)

    • google-github-actions/auth (GCP)

    • azure/login (Azure)

  • The secret's name identifies a registry publishing token that supports OIDC trusted publishing, such as an npm token or a PyPI token.

When a secret is OIDC Available, the badge also shows the provider (for example, OIDC Available · AWS). Secrets that are referenced but have no OIDC-based alternative are marked Not Applicable, and unreferenced secrets show no OIDC signal.

Filtering

Use the controls above the table to narrow down the list:

  • Search: Filter by repository or secret name.

  • Status filter: Filter secrets by usage status: Active, Stale, Unused, or Unknown.

  • OIDC available: Show only secrets that can be replaced with OIDC.

Acting on the results

A typical cleanup pass looks like this:

  1. Start with Unused secrets. Confirm they are not needed outside of Actions, then delete them.

  2. Review Stale secrets. If the pipeline that used them is retired, remove the secret. If it is still needed, rotate it.

  3. Work through the OIDC Replaceable list. Migrate cloud credentials and publishing tokens to OIDC, then delete the static secret once the workflow is verified.

This turns the secrets inventory from a static list into an actionable checklist for reducing your standing credential footprint.

Last updated

Was this helpful?