Security & Compliance
GitHub Actions security and compliance, operated at scale
Securing GitHub Actions across thousands of repositories is a consistency-and-evidence problem, not a missing-feature one. GitHub gives you strong native building blocks; CodeCargo applies them uniformly across your estate, controls the runtime, and proves it. For regulated organizations, financial services institutions among them, the goal has a name: a Secure SDLC. The most reliable way to reach it is to make it the destination of a migration or modernization you are already running.
Secure SDLC
A Secure SDLC on GitHub is an estate where access is standardized, provisioning is automated, policy is enforced at the org level, secrets are caught before they land, pipelines authenticate without stored credentials, and every artifact traces to the workflow and commit that built it.
Organizations most often reach this state as part of a migration or modernization already underway, not as a separate initiative. A migration from Jenkins, Azure DevOps or GitLab, or a modernization of an existing GitHub Actions estate, moves pipelines in waves onto a small number of shared workflows a platform team owns. Because every pipeline calling a shared workflow inherits what it does, each control below is built once, in the shared workflows and organization settings, and applied to every pipeline that moves.
Where GitHub Actions security meets a Secure SDLC
| Control | What GitHub provides natively | Where CodeCargo operates |
|---|---|---|
| Access | Organization, team and repository permissions, with rulesets governing branches and tags | Inherits your GitHub team structure and repository permissions; adds role-based access to CodeCargo projects and self-service workflows, with an exportable audit log on the Enterprise plan |
| Provisioning | Enterprise Managed Users, SCIM-provisioned by your identity provider, and template repositories for new projects | Self-service workflows that expose pre-approved deploys, environment provisioning and pipeline changes as forms, with RBAC and approval rules |
| Policy | Organization policies limiting which actions and reusable workflows can run, including full-length commit SHA pinning | Guardrail rules, built-in and custom, evaluated on every workflow change: a 0-100 score per workflow, violations inline on the pull request, drift tracking and auto-remediation pull requests |
| Secrets | Secret scanning with push protection (GitHub Secret Protection), blocking pushes that contain secrets | Guardrails flag hardcoded credentials in workflow files, with the values redacted from findings; during a migration, credentials are imported as names only and mapped explicitly to GitHub Secrets |
| Authentication | OpenID Connect: a short-lived cloud token per job, in place of a long-lived stored secret | An OIDC authentication rule scored across every workflow, with remediation pull requests where a workflow still relies on stored cloud credentials |
| Provenance | Artifact attestations for binaries, container images and SBOMs, verified with gh attestation verify | Moves pipelines onto shared reusable workflows, through Migration Assistant for legacy pipelines or Actions Advisor for an existing GitHub Actions estate; custom guardrail rules that can require provenance attestations on every build; CargoWall controlling what a runner can reach while it builds |
SLSA Build Level 3, SBOMs, attestation and provenance
SLSA (Supply-chain Levels for Software Artifacts) defines Build Level 3 as hardened builds: the build platform prevents runs from influencing one another, and keeps the material used to sign provenance out of reach of user-defined build steps.
- Software bill of materials (SBOM). The list of components inside an artifact.
- Provenance. The record of where and how an artifact was built: which workflow, from which commit.
- Attestation. A signed statement binding provenance, or an SBOM, to the artifact so it can be verified before deployment.
GitHub provides the primitives natively: artifact attestations for build provenance and SBOMs, and documented guidance for reaching SLSA Build Level 3 with reusable workflows. At enterprise scale, the work is making every pipeline build that way, which is the same shared-workflow motion as the migration itself. CodeCargo has built functionality to help customers harden their pipelines on that journey to SLSA Level 3.
Provenance and runtime control address the same risk from two angles: provenance records where and how an artifact was built, and it carries the most weight when the runner that built it could only reach what a legitimate build needs. CodeCargo's analysis of the Mini Shai-Hulud campaign covers why; CargoWall is the control CodeCargo built for that part of it.
Applying it during a migration
- Import legacy pipelines from Jenkins or Azure DevOps into Migration Assistant, or project an existing GitHub Actions estate in Actions Advisor, to see every pipeline, dependency and credential before anything changes.
- Group recurring patterns into shared reusable workflows a platform team owns, where least-privilege permissions, OIDC and attestation are built in once.
- Map every credential explicitly: a GitHub Secret at the right scope, or retired in favor of OIDC.
- Turn on guardrails from the first migrated workflow, starting in advisory mode and moving to enforcement.
- Run CargoWall in audit mode to learn what each workflow legitimately reaches, then enforce.
- Track compliance continuously: drift detection and audit trails give security and audit teams evidence over time, not a point-in-time snapshot.
CodeCargo operates under SOC 2 Type II, which is evidence of CodeCargo's own controls. Whether an organization's SDLC meets its regulatory obligations depends on the controls it enforces across its estate, which is the layer this applies and evidences.
The four layers of GitHub Actions security
Before anything runs
Supply-chain integrity
Pin actions to full commit SHAs, use OIDC for short-lived cloud credentials instead of stored secrets, allow-list trusted publishers, and scan dependencies and workflow files before merge, applied consistently across every repository.
Block the risky before it runs
Policy enforcement
Author policy once and enforce it everywhere. CodeCargo runs a fresh compliance scan on every workflow-file edit and surfaces violations inline on the pull request, so risky workflows are caught before they merge.
While jobs execute
Runtime detection
A malicious build step or a mid-job exfiltration attempt only appears at runtime. CargoWall, an eBPF kernel-level egress firewall, controls the network a workflow is allowed to reach and blocks exfiltration before the connection opens.
Prove it stays in policy over time
Continuous compliance
Every workflow is re-evaluated against policy on an ongoing basis, drift is surfaced the moment it appears, and there is an audit-ready evidence trail, rather than a point-in-time snapshot.
CargoWall: runtime network security
Pre-run scanning cannot catch a threat that only appears once a job is executing. CargoWall is an eBPF kernel-level egress firewall for GitHub Actions runners that closes that gap.
- Egress allow-lists at three scopes: hostnames, IPs, or CIDR blocks per workflow, per repository, or organization-wide.
- DNS query interception blocks tunnelling and data-exfiltration paths, not just direct IP connections.
- Audit mode logs every connection and policy decision without blocking, so a team learns a workflow’s real network behaviour before turning enforcement on.
- Supports GitHub-hosted and self-hosted runners, loading eBPF programs dynamically during execution with near-zero (microsecond) latency.
- Every blocked connection is logged with the workflow, the destination, and the policy that applied, so a runtime signal ties back to a specific owner.
Continuous compliance and scoring
A workflow that was compliant at audit time drifts. CodeCargo's compliance engine re-evaluates every workflow against policy and keeps the evidence current.
- A fresh compliance scan on every workflow-file edit, with violations surfaced inline on the pull request before merge.
- A 0-100 compliance score per workflow, tracked on a real-time dashboard by repo, team, and rule.
- A rule set covering SHA pinning, OIDC authentication, approved-actions-only, least-privilege permissions, hardcoded-credential prevention, secrets scanning, dependency review, and branch protection.
- Drift detection, audit trails of policy history and enforcement events, and auto-remediation pull requests with the fix already authored.
What CodeCargo covers
| Layer | What CodeCargo does |
|---|---|
| Supply chain | SHA pinning, OIDC, approved-actions allow-lists, pre-merge scanning, applied across every repo |
| Policy enforcement | Per-PR compliance scan, inline violations, one policy applied org-wide |
| Runtime network security | CargoWall eBPF egress firewall with per-workflow/repo/org allow-lists and DNS interception |
| Compliance scoring | 0-100 score per workflow, real-time dashboard, drift detection |
| Evidence | Audit trails of policy history, scores over time, remediation actions, enforcement events |
| Remediation | Auto-remediation pull requests with the fix authored |
CodeCargo operates under SOC 2 Type II and is a GitHub-native product. It extends GitHub rather than competing with it. For the full picture, read the runtime security and compliance guide.
GitHub-native security and where CodeCargo operates
This table compares where each control sits natively in GitHub versus where CodeCargo's platform layer operates.
| Concern | Where it is handled natively | Where CodeCargo operates |
|---|---|---|
| Secret scanning, code scanning, dependency review | GitHub Advanced Security, at the repository level | Not in scope, run GHAS for this |
| Which actions may run, and pinned to what | Branch and repository settings, configured per repository | Enforced across every workflow run in the organisation |
| Runner network egress | Runner configuration, per machine | CargoWall, an eBPF L4 firewall at the runner |
| Cross-team administration and self-service | GitHub organisation settings | Single control plane across the estate |
Frequently asked questions
What are the four layers of GitHub Actions security?
Supply-chain integrity (before anything runs), policy enforcement (block the risky before it runs), runtime detection (catch threats while jobs execute), and continuous compliance (prove it stays in policy over time). A mature program needs all four; no single tool spans them all.
How does CargoWall stop data exfiltration in GitHub Actions?
CargoWall is an eBPF kernel-level egress firewall for GitHub Actions runners. It controls the network a workflow job is allowed to reach with per-workflow, per-repo, and org-wide allow-lists and DNS interception, and blocks connections outside the allow-list before they are established, which pre-run scanning cannot do.
How does CodeCargo keep GitHub Actions workflows compliant over time?
CodeCargo scans each workflow on every edit, scores it 0-100, tracks drift on a real-time dashboard, and keeps audit trails of policy history, scores, remediation actions, and enforcement events, so compliance is continuous and evidenced rather than a point-in-time scan.
Is CodeCargo SOC 2 Type II compliant?
Yes. CodeCargo operates under SOC 2 Type II, an independent audit of how it runs its own security controls over a period of time. That is evidence of CodeCargo’s own posture; your organization’s regulatory compliance still depends on the controls you enforce across your workflows, which is the layer CodeCargo helps you apply and evidence.
Does CodeCargo replace tools like Falco, Wiz, or OPA?
No. CodeCargo is a control plane that complements detection and policy engines by applying controls consistently across a GitHub estate and proving compliance over time. It ties runtime signals to specific workflows and owners, enforces paved-road defaults, and adds runner-network egress control with CargoWall.
What is a Secure SDLC on GitHub?
A Secure SDLC on GitHub is an estate where access is standardized, provisioning is automated, policy is enforced at the org level, secrets are caught before they land, pipelines authenticate without stored credentials, and every artifact traces to the workflow and commit that built it. CodeCargo helps organizations reach it as part of a GitHub Actions migration or modernization.
What does SLSA Build Level 3 mean for GitHub Actions pipelines?
SLSA Build Level 3 requires hardened builds: the build platform keeps runs from influencing one another, and keeps provenance-signing material away from user-defined build steps. GitHub documents artifact attestations combined with reusable workflows as a path to it. At enterprise scale, reaching it means moving every pipeline onto shared, attested workflows, which is the same work as a well-run migration.
Does CodeCargo replace GitHub Advanced Security?
No. GitHub Advanced Security, through GitHub Secret Protection and GitHub Code Security, covers secret scanning and push protection, code scanning and dependency review natively across your repositories. CodeCargo is GitHub-native and operates a layer above that, at the workflow and organization level: enforcing policy such as SHA pinning, OIDC and approved actions across every workflow, controlling runner network egress with CargoWall, and keeping compliance evidence current across the estate.
Secure and prove GitHub Actions at scale
See how CodeCargo applies GitHub-native controls across every repository, gates the runtime with CargoWall, and produces the compliance evidence auditors accept.