How to Audit GitHub Actions, CI/CD Runners, and Build Permissions for Supply Chain Risk

Your CI/CD Pipeline May Have More Power Than Most Employees

Your CI/CD pipeline can read source code.

It can access secrets.

It can create software artifacts.

It can publish packages.

It may even deploy directly to production.

Therefore, GitHub Actions and other CI/CD platforms are part of the software supply chain.

Yet many audits focus only on the application.

OWASP highlights several CI/CD risks.

These include weak identities, poor credential handling, pipeline abuse, and limited logging.

For an ISO 27001 internal audit, the main question is:

Why CI/CD Is Part of the Software Supply Chain

A modern pipeline may look like this:

Every stage can affect the final software.

An attacker may target the workflow, runner, token, or build process.

Therefore, CI/CD belongs inside software supply chain risk management.

1. Audit Who Can Change Workflow Files

Start with the workflow itself.

GitHub Actions workflows normally use YAML files stored with the source code.

Changing a workflow can change:

• Which code runs.
• Which tools execute.
• Which secrets are exposed.
• Which permissions are granted.
• Where software is deployed.

Internal audit should ask:

Then test whether sensitive changes require independent review.

Evidence to Request

• Repository permissions.
• Branch protection.
• Rulesets.
• CODEOWNERS.
• Pull request approvals.
• Workflow change history.
• Administrative bypass rights.

2. Review GITHUB_TOKEN Permissions

GitHub Actions jobs can receive a GITHUB_TOKEN.

GitHub creates this token automatically.

The risk depends on what the token can do.

GitHub recommends granting only the permissions each job needs.

Internal Audit Should Review

Then ask:

For example, a unit-test job may only need read access.

It may not need contents: write.

Least privilege applies to CI/CD identities too.

3. Audit Third-Party GitHub Actions

A workflow can execute code from another repository.

For example:

That makes third-party actions part of the software supply chain.

A compromised action may access tokens, source code, or available secrets.

GitHub allows organizations to restrict approved actions.

It can also require full commit SHA references.

Internal Audit Should Ask

• Which third-party actions are allowed?
• Who approves them?
• Are they reviewed before use?
• Are they pinned?
• Are unused actions removed?
• Are updates reviewed?

Instead of a movable tag such as:

Use an approved immutable reference where appropriate.

4. Review Self-Hosted Runners Carefully

Self-hosted runners need extra attention.

A persistent runner may retain:

• Files.
• Credentials.
• Build artifacts.
• Tokens.
• Cached dependencies.
• Malicious persistence.

GitHub warns that self-hosted runners are not automatically clean after every job.

Untrusted workflow code may therefore create persistent risk.

Internal Audit Should Check

• Which repositories can use the runner?
• Is the runner persistent or ephemeral?
• Is it rebuilt between jobs?
• What network access does it have?
• Which secrets can it reach?
• Can it access production?
• Who administers it?
• Is the host patched and hardened?

Better Design

Use runner groups to restrict sensitive runners.

For higher-risk workloads, consider clean ephemeral runners.

5. Test Pull Request Trust Boundaries

Pull requests create an important CI/CD trust boundary.

Lower-trust code may enter through:

• Forks.
• Feature branches.
• External contributors.
• Automated bots.

GitHub applies protections to forked pull requests.

However, the workflow event still matters.

The pull_request_target event runs in a higher-trust context.

Unsafe use may expose sensitive tokens or secrets.

Internal Audit Should Ask

• Which events trigger workflows?
• Can untrusted pull requests use privileged runners?
• Can forked code access secrets?
• Are deployment jobs separated from PR validation?
• Is pull_request_target used?
• If yes, why?

6. Audit Secrets in CI/CD

Build pipelines often need sensitive credentials.

These may include:

Therefore, secret management is a major audit area.

GitHub recommends storing sensitive data in secret-management features.

Secret masking alone does not replace least privilege.

Evidence to Request

• Repository secrets.
• Organization secrets.
• Environment secrets.
• Secret access policies.
• Rotation records.
• Vault integrations.
• Secret change logs.

Audit Questions

• Who can create secrets?
• Who can replace them?
• Which workflows receive them?
• Are secrets shared across unrelated repositories?
• Do old credentials remain active?

7. Replace Long-Lived Cloud Secrets Where Possible

One strong CI/CD improvement is reducing stored cloud credentials.

GitHub Actions supports OpenID Connect, or OIDC.

OIDC can provide short-lived cloud access.

As a result, teams may not need permanent cloud credentials in GitHub.

Internal Audit Should Check

If OIDC is used, verify:

• Which repositories are trusted.
• Which branches are trusted.
• Which environments can request tokens.
• Which cloud roles workflows can assume.
• Whether trust conditions are narrowly scoped.

The cloud provider should not trust every repository by default.

8. Separate Build Permissions From Deployment Permissions

Build jobs and deployment jobs do not need the same access.

These permissions should be separated.

Internal Audit Should Test

• Are production secrets available during normal builds?
• Can every branch trigger deployment?
• Are production environments protected?
• Is approval required?
• Can one developer change and approve the workflow?

The goal is to stop one compromised job from gaining unnecessary authority.

9. Review Environment Protection

GitHub environments can protect deployment targets.

For example, a production environment may require:

• An approved branch.
• Human review.
• A restricted deployment workflow.
• Environment-specific secrets.

Internal audit should verify these controls technically.

Do not rely only on a procedure that says:

The workflow should enforce the rule.

10. Test Build Artifact Integrity

The output of CI/CD matters more than the logs alone.

Internal audit should ask:

Useful evidence may include:

• Artifact hashes.
• Digital signatures.
• Build provenance.
• Controlled artifact repositories.
• Immutable version identifiers.
• Release records.

11. Review Build Dependencies

GitHub Actions workflows can download many dependencies.

These may include:

• Packages.
• Container images.
• Actions.
• Build tools.
• Scripts.

Therefore, CI/CD audit work should connect with software supply chain controls.

Review whether the pipeline uses:

• Version pinning.
• Lockfiles.
• Approved registries.
• Dependency scanning.
• Integrity checks.

A secure repository can still build compromised software if the pipeline downloads malicious dependencies.

12. Audit Who Can Administer GitHub Actions

Do not review developers only.

Review administrators too.

Ask who can:

• Change Actions policies.
• Create self-hosted runners.
• Modify runner groups.
• Change repository settings.
• Add organization secrets.
• Disable branch protection.
• Approve production environments.
• Allow new third-party actions.

These permissions can change the security model for many workflows.

Internal Audit Test

Create a privileged-access matrix.

Then confirm that privileged access is reviewed regularly.

13. Test Workflow Logging and Monitoring

If a malicious workflow runs, the organization should be able to investigate it.

Auditors should verify access to:

• Workflow run history.
• Repository audit logs.
• Secret changes.
• Runner registrations.
• Permission changes.
• Deployment history.
• Failed workflow attempts.
• Administrative changes.

Practical Audit Test

Choose one production deployment.

Then ask the team to reconstruct:

If the team cannot reconstruct the event, auditability is weak.

14. Test the Compromised Runner Scenario

Strong audits include practical scenarios.

Ask:

Then map the possible path.

The goal is to reduce the blast radius.

A runner should not become a bridge to the entire organization.

15. Test Emergency Revocation

What happens if a CI/CD credential or runner is compromised?

The organization should know how to:

• Disable the runner.
• Revoke credentials.
• Remove cloud trust.
• Rotate secrets.
• Stop deployments.
• Disable compromised workflows.
• Review affected releases.
• Investigate activity.

ISO 27001 Controls to Consider

CI/CD security can support several ISO/IEC 27001:2022 control areas.

The exact mapping should match your ISMS scope, architecture, risks, and Statement of Applicability.

Evidence Internal Audit Should Request

A practical evidence pack may include:

Use risk-based sampling.

A repository that deploys production software deserves more attention than a documentation repository.

Common GitHub Actions Internal Audit Findings

Watch for these patterns.

Quick GitHub Actions Security Audit Checklist

Before closing the audit, confirm:

Connect CI/CD Risk to Your SharePoint ISMS

CI/CD evidence often sits inside GitHub and cloud platforms.

Meanwhile, ISO 27001 findings and risk records may sit somewhere else.

That separation can make audit traceability difficult.

Canadian Cyber’s ISMS SharePoint Solution can help centralize:

Frequently Asked Questions

The Takeaway

Your CI/CD pipeline is not just automation.

It is a privileged software factory.

It decides:

Therefore, CI/CD security belongs inside the ISMS.

A strong audit should trace:

If any stage can be silently changed, risk increases.

The same is true if a stage can be bypassed or overprivileged.

Audit the pipeline that builds the software, not only the software itself.

Stay Connected With Canadian Cyber

Follow Canadian Cyber for practical guidance on ISO 27001 internal audits, GitHub Actions, CI/CD security, secure development, software supply chains, and SharePoint ISMS.