GitHub is introducing another security barrier for public repositories by automatically pausing certain GitHub Actions workflow runs that appear potentially malicious. Instead of allowing the workflow to begin and warning maintainers afterwards, GitHub will require a trusted collaborator to review and approve the run first.
The change is aimed at a growing software supply-chain risk: attackers compromising legitimate GitHub accounts and then using repository automation to steal credentials, modify releases or gain access to connected services.
This matters because GitHub Actions workflows can hold far more power than simply running a few automated tests. Depending on their configuration, they may access repository tokens, encrypted secrets, package-publishing credentials, cloud infrastructure and deployment environments.
A malicious workflow can therefore become an entry point into systems well beyond the repository where it first appears.
Why GitHub Actions Are Valuable Targets
GitHub Actions allows developers to automate tasks whenever something happens inside a repository.
A workflow may begin when someone pushes code, submits a pull request, creates a release or starts a manual deployment. It can then build an application, run security checks, publish a package or deploy software to production.
This makes Actions extremely useful, but it also means workflow files can sit close to some of an organisation's most sensitive systems.
A privileged workflow might be able to:
If an attacker gains control of a maintainer's account, changing the workflow may be enough to turn the organisation's own CI/CD system against it.
The automation still appears to come from a legitimate repository, but its purpose has changed from building software to stealing credentials or distributing compromised code.
The New Protection Stops Flagged Workflows Before Execution
Under GitHub's new system, a suspicious workflow run remains paused while it waits for human approval.
A repository collaborator with write access must review the held workflow and approve it through an authenticated GitHub web session. Only after that approval will the workflow continue through the normal Actions process.
Until approval is granted, the workflow does not begin executing.
That distinction is important.
Many security controls detect suspicious activity only after a job has started. By that point, the workflow may already have accessed a token, loaded a secret or sent information to an external server.
The new approval requirement introduces a decision point before the runner begins processing the potentially dangerous workflow.
Repository Owners Do Not Need to Enable It
GitHub is applying the protection automatically.
Maintainers do not need to modify repository settings, create an additional policy or opt into the feature. When GitHub's detection systems identify a workflow run as suspicious, the approval requirement is added automatically.
The protection currently applies to public repositories hosted on GitHub.com.
It is not available for self-hosted GitHub Enterprise Server environments, meaning organisations running GitHub on their own infrastructure will not receive the same control through this rollout.
GitHub has also not publicly explained the full criteria used to decide when a workflow should be held.
That lack of detail is understandable from a security perspective. If attackers knew every detection rule, they could design workflows specifically to avoid them. However, it may also leave maintainers uncertain about why a particular run was flagged.
A Human Review Can Add Context That Automation Lacks
Automated detection systems are valuable, but they do not always understand why code has changed.
A workflow modification may legitimately add a deployment step, change permissions or introduce a new third-party Action. The same behaviour could also be part of an attack.
A collaborator familiar with the repository can examine whether the change was expected, who introduced it and what access the workflow requests.
Useful questions during review include:
The approval step does not guarantee that the reviewer will spot every threat, but it creates an opportunity to interrupt an attack before credentials become exposed.
The Feature Is Not a Complete Malware Detector
GitHub has not claimed that every malicious workflow will be identified.
The approval requirement applies only when GitHub's systems classify a run as suspicious. A workflow that avoids detection may still execute normally.
Maintainers should therefore treat the new protection as an additional safety layer rather than a replacement for established controls.
Strong repository security still requires:
No single detection system can compensate for an account with excessive privileges or a workflow that has unrestricted access to production systems.
The GITHUB_TOKEN Should Follow Least Privilege
Every GitHub Actions job can receive an automatically generated credential known as the GITHUB_TOKEN.
This token allows the workflow to interact with the repository according to the permissions assigned to it. It may be used to read code, update pull requests, create releases or perform other repository operations.
The token is created temporarily for each job, but it can still cause serious damage when its permissions are too broad.
GitHub recommends granting only the access that each workflow genuinely requires.
A workflow running automated tests may need permission to read repository content but should not necessarily be able to modify releases or push code. A documentation job may not need access to issues, packages or deployment environments.
Permissions can be reduced at the workflow or job level so that more sensitive access is granted only where necessary.
This approach limits the damage if the workflow is altered or a third-party Action becomes compromised.
Be Careful with Untrusted Pull-Request Code
Public repositories frequently accept contributions from external developers.
Running pull-request code is useful for checking whether a proposed change builds correctly or passes automated tests. However, that code should not be processed inside a privileged workflow that can access secrets or write to the repository.
An attacker could submit a pull request containing code designed to read environment variables, inspect memory or transmit information to an external server.
If the workflow has access to deployment credentials or package-publishing tokens, the attacker may be able to collect them without first obtaining direct access to the repository.
Maintainers should separate low-trust testing from high-trust release workflows.
External contributions can be tested in a restricted environment with read-only permissions and no access to sensitive secrets. Publishing and deployment jobs should run only after trusted maintainers approve or merge the code.
Encrypted Secrets Remain High-Value Targets
GitHub repositories can store encrypted secrets used by Actions workflows.
These may include credentials for:
The secrets are protected when stored, but they become available to the workflow when explicitly referenced during execution.
A malicious workflow may attempt to print the value, encode it, place it inside an artefact or transmit it over the network.
GitHub masks recognised secret values in logs, but attackers may use transformations or memory inspection to bypass simple masking.
That is why secret access should be tightly limited.
Long-lived credentials should be avoided where short-lived identity federation is available. Organisations can use OpenID Connect to issue temporary cloud credentials rather than storing permanent keys in the repository.
Previous Attacks Show How CI/CD Secrets Can Be Exposed
Recent software supply-chain incidents involving third-party GitHub Actions have demonstrated what can happen when attackers compromise widely used automation components.
In the reviewdog and tj-actions incidents, malicious code was reportedly introduced into Actions used by many other repositories. The altered code searched runner memory for credentials and exposed information through workflow logs.
Investigators believed credentials linked to a bot account were obtained during one compromise and then reused to access another Action repository.
The incident became more serious because affected version tags were reportedly redirected to malicious code.
Repositories referencing those familiar tags could execute the compromised version without changing their own workflow files. From the maintainer's perspective, the workflow configuration looked the same, but the code behind the tag had changed.
This illustrates why trusted names and version labels are not always enough.
Pin Third-Party Actions to Full Commit Hashes
GitHub advises maintainers to reference third-party Actions using full-length commit hashes whenever practical.
A tag such as v3 or latest is easy to read, but it may be movable. The repository owner can redirect the tag to another commit later.
A full commit hash points to one specific version of the code.
For example, instead of referencing only a major version, a workflow can specify the exact commit that has already been reviewed.
This does not eliminate every risk. The selected commit could still contain a hidden vulnerability, and maintainers must deliberately update the hash when security patches are released.
However, pinning prevents a previously trusted reference from silently changing underneath the workflow.
Dependency-management tools can help monitor pinned Actions and suggest updates when new versions become available.
Restrict Which Actions Repositories May Use
GitHub also allows organisations and repositories to control which Actions are permitted.
Maintainers can limit workflows to:
This reduces the chance that a contributor introduces an unknown automation component with excessive access.
Third-party Actions should be evaluated like any other software dependency. Teams should review their maintainers, update history, permissions, source code and response to security reports.
Popularity alone should not be treated as proof of safety. Widely used projects can become especially attractive targets because compromising one repository may affect thousands of downstream users.
Separate Build, Test and Release Responsibilities
A secure CI/CD design should not place every activity inside one highly privileged workflow.
Testing external code, building artefacts and publishing production releases have different risk levels.
A safer structure may use:
This compartmentalisation means a compromise in one stage does not automatically provide access to every other stage.
The new GitHub approval control supports that strategy, but repository owners still need to design their workflows around clear trust boundaries.
Dependabot Is Expanding Its Malware Intelligence
GitHub is also strengthening other parts of its software supply-chain protection.
Dependabot is incorporating malware advisories from the OpenSSF malicious-packages repository. This gives GitHub additional information about harmful packages identified across ecosystems such as npm and PyPI.
Repositories that already have malware alerting enabled receive the expanded coverage automatically.
When a project depends on a package matching an advisory in the added dataset, Dependabot can generate an alert so maintainers can investigate and remove or replace it.
This is valuable because malicious packages are not always ordinary software containing accidental vulnerabilities.
Some are created specifically to steal environment variables, install backdoors, harvest browser data or compromise developer workstations.
New npm Packages Will Be Scanned Before General Availability
GitHub is also introducing automated security scanning for newly published npm packages.
After a package is uploaded, it may not become immediately available for installation. The package first goes through an automated evaluation process.
Depending on the findings, it may be:
GitHub says the normal delay should be around five minutes, although it may exceed 15 minutes during busy periods or when packages are unusually large or complex.
For individual developers, this delay may be barely noticeable. For automated release pipelines that expect a package to become installable immediately, it could require workflow changes.
Release Automation May Need to Allow for the Delay
Some CI/CD processes publish a new npm package and immediately begin another job that installs or tests the newly released version.
Those pipelines may fail when the package is still waiting for scanning.
Developers may need to add retry logic, polling or a short delay before assuming that the new version is publicly available.
While scanning is pending, publishers can reportedly continue using the npm dist-tag command.
However, commands that depend on the new version already being available, including npm deprecate and npm unpublish, will not function until the scan has been completed.
The added waiting period is an inconvenience, but it gives npm an opportunity to stop suspicious packages before they reach large numbers of developers.
Security Tools Can Look Like Malware to Automated Scanners
Some legitimate packages contain features that resemble malicious behaviour.
Penetration-testing tools, malware-analysis utilities and security research packages may inspect credentials, interact with processes or simulate exploitation techniques. Automated scanners could flag those capabilities even when the package has a legitimate defensive purpose.
To address this, npm is introducing a disclosure process for dual-use packages.
Maintainers must declare the content through a contentPolicy field inside package.json and provide a plain-text DISCLOSURE file explaining what the capability does and why it is included.
This gives reviewers and automated systems additional context before deciding whether the package should be released.
Dual-Use Packages Must Use Stronger Authentication
Packages declaring security-related dual-use capabilities must be published through a method that enforces two-factor authentication.
Supported methods include:
This requirement helps reduce the risk of an attacker compromising the maintainer account and publishing a weaponised version under a trusted package name.
Once a package has been published with the dual-use declaration, future versions must retain both the contentPolicy field and the DISCLOSURE file.
npm plans to reject updates that remove those declarations as enforcement expands.
This prevents a package from presenting itself as transparent during one release and quietly hiding its security-sensitive capabilities later.
A Broader Shift from Detection to Prevention
GitHub's new workflow approval control, Dependabot expansion and npm package scanning all reflect the same security direction.
The company is trying to stop suspicious activity earlier in the software lifecycle.
Instead of discovering that a workflow leaked credentials after it finished, GitHub can hold it before execution. Instead of warning about a malicious package only after installation, npm can delay or block it before general availability.
Prevention is not perfect, and false positives are unavoidable. However, software supply-chain attacks can spread so rapidly that even a short delay may give defenders valuable time.
A compromised Action or package can affect thousands of projects within hours because automated systems retrieve and execute new versions without human involvement.
Adding review points slows that propagation.
Maintainers Still Remain Responsible for Their Security Model
GitHub's platform-level protections are useful, but they cannot understand every repository's business context.
Only the maintainers know which workflows should have deployment access, which third-party Actions are approved and whether a specific change was expected.
Repository owners should regularly review:
Unused secrets and obsolete collaborators should be removed. Release credentials should be rotated periodically, especially after suspicious activity.
Organisations should also maintain an incident-response plan for CI/CD compromise. That plan should cover token revocation, package removal, release verification and communication with downstream users.
Final Thoughts
GitHub's decision to pause suspicious Actions workflows before execution is a practical improvement to software supply-chain security.
A compromised account can transform a trusted repository's automation into a credential-stealing or malware-distribution mechanism. Requiring a collaborator with write access to approve a flagged run creates a valuable opportunity to stop the attack before the workflow reaches repository tokens and stored secrets.
The feature is not a complete solution. GitHub will not detect every malicious workflow, and human reviewers can still approve unsafe code.
Its effectiveness therefore depends on the controls surrounding it: least-privilege tokens, protected secrets, restricted third-party Actions, commit-hash pinning and separation between untrusted testing and privileged release processes.
The related improvements to Dependabot and npm show that GitHub is applying the same preventive approach across more of the development ecosystem.
For maintainers, the lesson is clear. CI/CD automation should be treated as production infrastructure, not merely a convenient scripting tool. The code that builds and publishes software often holds the same level of access as the people who operate the organisation's most sensitive systems.
Comments