1. Permissions — Principle of Least Privilege The single highest-impact change you can make to any GitHub Actions workflow is locking down permissions. By default, GITHUB_TOKEN has read and write access to most scopes. Override that immediately. Default Read-Only Permissions (Top-Level) Place this at the top of every workflow file to make read-only the default … Read more
GitHub Actions has become the most widely adopted CI/CD platform in the world. With over 90% of GitHub repositories capable of using it natively, it powers everything from simple linting checks to complex multi-cloud deployments. But that ubiquity makes it the single most targeted CI/CD attack surface in modern software development. In 2024 and 2025, … Read more
To secure GitHub Actions in an enterprise environment, you must adopt a layered defence strategy that spans identity management, infrastructure hardening, and strict workflow governance. Security in CI/CD pipelines is critical because pipelines often have high-level privileges and access to production environments, making them a prime target for attackers. In enterprise environments, CI/CD pipelines are … Read more
Overview GitHub Actions has become the most widely adopted CI/CD platform for open-source and commercial software alike. That popularity makes it the number-one attack surface in the CI/CD landscape. Misconfigured workflows routinely leak secrets, grant excessive permissions, and pull in third-party code that can be silently tampered with. In this hands-on lab you will harden … Read more
Overview Every container image your CI/CD pipeline produces should be cryptographically signed before it reaches any environment. Unsigned images are a blind spot — you have no proof they came from your pipeline, no guarantee they weren’t tampered with in transit, and no policy hook to block rogue deployments. In this hands-on lab you will: … Read more
Overview If your GitHub Actions workflows authenticate to AWS using AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY stored as repository secrets, you have a serious security problem. Those long-lived credentials never expire on their own, can be exfiltrated by any workflow step (including third-party actions), and give attackers persistent access to your AWS account if compromised. OpenID Connect (OIDC) … Read more
What to change concretely in real CI/CD environments 🔐 Access & Identity Hardening If failing SSO/MFA controls: 🧱 Runner Isolation If using shared runners in regulated pipelines: 🚫 Policy Gates Not Blocking If SAST/SCA/DAST results are advisory only: 📦 Artifact Integrity If artifact signing missing: Evidence Centralization If logs only exist in vendor UI: 🔁 … Read more
Overview GitHub-hosted runners are shared and ephemeral by default — every job gets a fresh virtual machine that is destroyed after the job completes. Self-hosted runners, on the other hand, are persistent and shared across workflow runs. This creates a significant security risk: secrets, tokens, and build artifacts from one job can leak into the … Read more
Overview Third-party GitHub Actions are one of the most convenient features of the GitHub ecosystem. With a single uses: directive, you can pull in complex build logic, deploy to cloud providers, or run security scanners. But that convenience comes with a critical trade-off: every third-party action executes code in your CI environment with access to … Read more
GitHub Actions has become one of the most widely adopted CI/CD platforms. Its flexibility, tight integration with GitHub repositories, and rich ecosystem make it attractive for teams of all sizes. At the same time, GitHub Actions runners have emerged as a critical attack surface in modern software supply chain attacks. Runners execute untrusted code, handle … Read more
