GitHub has introduced an automatic approval step for certain GitHub Actions workflow runs in public repositories. The measure is intended to stop workflows that the platform identifies as potentially malicious before they begin executing.
The protection targets supply chain attacks involving compromised GitHub credentials. Attackers can use hijacked accounts to add or modify Actions workflows, extract CI/CD credentials, and carry out further attacks through repository automation.
GitHub Actions workflows can use repository tokens, stored secrets, package-publishing credentials, and access to external services, depending on how they are configured. A malicious workflow that obtains those credentials can use them outside the affected repository.
CI/CD environments can provide access to multiple stages of the software release process. Depending on its configuration, a workflow can run tests, build software, create releases, publish packages, or connect to cloud infrastructure.
How the approval process works
When GitHub holds a workflow run, it remains paused until a repository collaborator with write access reviews and approves it. The approval must be submitted through an authenticated web session.
The workflow does not begin executing while the review is pending. If the collaborator approves the run, it continues through the normal GitHub Actions process.
The additional review applies only when GitHub identifies a run as potentially malicious. GitHub did not describe the detection criteria used to flag workflows in its announcement.
Repository owners do not need to enable or configure the protection because GitHub applies it automatically. The control applies to public repositories hosted on GitHub.com and is not currently available for GitHub Enterprise Server deployments.
The feature adds a human review step before a flagged workflow can execute, rather than issuing an alert after the run has started. A collaborator with write access must examine the held workflow and decide whether it should proceed.
GitHub did not state that the control will identify every malicious workflow. It applies to runs detected by the company’s systems and does not replace repository access controls, code review, or limits on workflow permissions.
Risks from compromised CI/CD workflows
GitHub advises maintainers to limit the permissions assigned to the automatically generated GITHUB_TOKEN. It also warns against running untrusted pull-request code in workflows that have write access or can retrieve repository secrets.
The GITHUB_TOKEN is created for each workflow job and can interact with repository resources according to its assigned permissions. GitHub recommends granting only the access required for each job, rather than providing broader permissions by default.
Repositories can also provide workflows with encrypted secrets used to authenticate with package registries, cloud platforms, deployment systems, and other services. These secrets are available only when maintainers configure a workflow to use them, but they can become targets if privileged workflows execute altered or untrusted code.
Previous supply chain attacks have demonstrated how compromised Actions code can collect credentials from CI environments. OpenSSF’s account of the reviewdog and tj-actions compromises said attackers introduced code that searched runner memory for secrets and exposed the results through workflow logs.
OpenSSF said secrets exposed during the reviewdog incident likely included credentials for a bot account used by tj-actions. According to its account, those credentials were then reused to gain access to the tj-actions/changed-files repository.
The affected Action was used by other repositories in their automated workflows. OpenSSF said the malicious changes were linked to version tags, allowing repositories that referenced those tags to execute altered code without modifying their own workflow files.
The new approval requirement adds a review point before a flagged workflow can run. It does not replace existing controls covering token permissions, secret management, or the use of third-party Actions.
GitHub advises maintainers to pin third-party Actions to full-length commit hashes where possible. A commit hash points to a specific version of the code, reducing the risk that a mutable tag will later be redirected to a different release.
Maintainers can also restrict which Actions are permitted in a repository, review the permissions assigned to each job, and separate workflows that process external contributions from those that publish software or access sensitive credentials.
GitHub has introduced related controls elsewhere in its software supply chain services. Dependabot now uses malware advisories from the OpenSSF malicious-packages repository, expanding alert coverage across ecosystems including npm and PyPI.
Repositories with malware alerting already enabled receive the expanded Dependabot coverage automatically. Alerts are generated when a project dependency matches an advisory in the additional dataset.
GitHub is also adding automatic scanning for newly published npm packages before they become available for installation. Based on the scan results, a package can be released normally, held for manual review, or blocked.
GitHub said the process typically adds about five minutes between publication and availability. The delay can exceed 15 minutes during peak periods or when packages are larger or contain material that requires additional review. Release automation that assumes immediate package availability may therefore need to accommodate a delay.
While scanning is pending, publishers can continue to use the npm dist-tag command. Operations that depend on the new version being available, including npm deprecate and npm unpublish, will not work until the package clears the scanning process.
npm is also introducing requirements for packages with legitimate security-related functions that can resemble malicious behaviour during automated scanning. Maintainers must declare this dual-use content through a contentPolicy field in package.json and include a text-only DISCLOSURE file describing the capability and its intended use.
These packages must be published using a method that enforces two-factor authentication. Supported methods include trusted publishing through OpenID Connect, an interactive session protected by two-factor authentication, or npm’s staged publishing process.
Once a package has been published with the dual-use declaration, later versions must retain both the contentPolicy field and the DISCLOSURE file. npm said it will reject releases that remove either item as the requirements are progressively enforced.
(Photo by Rubaitul Azad)
See also: GitHub Actions abuse turned Packagist repositories into scanners
Want to learn more about cybersecurity from industry leaders? Check out Cyber Security & Cloud Expo taking place in Amsterdam, California, and London. The comprehensive event is part of TechEx and is co-located with other leading technology events including the AI & Big Data Expo. Click here for more information.
Developer Tech News is powered by TechForge Media. Explore other upcoming enterprise technology events and webinars here.