The Suniworks journal

GhostAction: review the workflow, not just the application

Deployment workflows can reach powerful credentials. Define review responsibilities, limit access and prepare a response to a compromised pipeline.

Updated on .

Illustrative data flow showing technical credentials being diverted

A configuration file can have as much power as the application it builds. A GitHub Actions workflow decides which commands run and which access is needed for deployment. A change described as a security check deserves a proper code review.

A familiar identity can deliver a malicious change

StepSecurity’s GhostAction investigation describes compromised maintainer accounts adding workflows that send credentials to an attacker. The documented campaign also examines Git history for secrets.

The author’s name and the filename do not establish trust. Review what the workflow actually executes, reads and connects to.

Treat deployment configuration as sensitive code

A reviewer should be able to explain the triggers, permissions and dependencies before accepting a change. Downloaded commands, new tokens and additional network destinations need an understandable purpose.

  • Identify who may change workflow files.
  • Require an appropriate review of build and deployment changes.
  • Limit credentials to the required service and environment.
  • Review external actions and their versions before adding them.

GitHub’s secure-use reference explains the technical framework. Check which controls are available and how they behave for your repository and plan.

An empty search result is not a clean bill of health

Searching for known filenames helps initial triage. A campaign can change names, destinations and techniques. A useful review examines recent changes, execution records and effective access, with a documented scope and time period.

Separate credentials present in the current files from those removed in earlier commits. A secret retained in history still needs attention. Deleting its current line does not revoke it with the provider.

Prepare the response before removing evidence

If a suspicious workflow appears, stop affected executions and preserve the information needed to investigate. Revoke and replace exposed credentials, then examine the systems they could access. Removing the file alone does not restore trust.

For an organisation buying custom software, the procurement questions are direct: who can change the delivery pipeline, who reviews the change and who manages access during a supplier transition? Establish those responsibilities before the first deployment.

A software decision to prepare? Tell us about the context and the work your application needs to support.

Discuss your project