SecureCI vs GitHub’s built-in Actions security: from guardrails to a golden path

Q: Does SecureCI work with GitHub Enterprise Server?

Yes. Point GITHUB_SERVER_URL and GITHUB_API_URL at your GHES host; the CLI runs inside your own infrastructure.

Last reviewed: 24 October 2026

GitHub’s policies decide which actions may run. The SecureCI CLI decides whether each workflow does what your organisation requires: the right steps, in the right order, at the right versions, using the code you reviewed. And developers get the same answer locally, before they push.

Short answer:

Golden path, enforced: required actions, their order across jobs and minimum versions. GitHub’s policies can’t express these.
Moved tags: on GitHub.com, use GitHub’s new workflow lockfiles (public preview). On GitHub Enterprise Server, where they aren’t available, secureci.lock fails CI when a tag you allow starts pointing at different code.
Shift left: the same checks run on a laptop, and secureci run executes the workflow before it reaches GitHub.
Works with what you have: SecureCI runs as a required check next to GitHub’s policies, Dependabot and CodeQL, on GitHub.com and GitHub Enterprise Server.

At a glance

	GitHub built-in	SecureCI CLI
Require specific actions inside a workflow, in order	No	Yes needs-aware ordering across jobs
Minimum versions of internal actions	No	Yes `min-version`
Catch an allowed tag that moves, before merge	Partial workflow lockfiles (`actions.lock`) run the locked commit, but are in public preview and not available on GitHub Enterprise Server	Yes `inventory: check` fails the pull request, on GitHub.com and GitHub Enterprise Server, against `secureci.lock` or your `actions.lock`
Lock the actions your actions use (transitive)	Yes `actions.lock`	Yes `secureci.lock` records them and `inventory: check` fails the pull request when one moves (CLI 0.5.0 or later)
Checks mapped to compliance controls (PCI DSS, DORA, ISO 27001…)	Partial an NIST SSDF implementation guide; GitHub’s PCI DSS attestation covers GitHub itself, not your workflows	Partial published mapping; supports controls, doesn’t certify
Check before you push	No	Yes the same checks run locally
Run workflows locally	No	Yes `secureci run`
Only allow approved actions and owners	Yes allowed-actions policy, on every plan since February 2026	Yes `allowed-owners`, also checked locally
Block a specific action or version	Yes	Yes `forbidden` with an optional exact version
Require SHA pinning	Yes	Yes with per-owner exceptions
Required check before merge	Yes rulesets	Yes runs as that required check
Same rules on GitHub Enterprise Server	Partial depends on version and licence	Yes point `GITHUB_SERVER_URL` at your host
Injection and permission analysis	Yes CodeQL; since June 2026 `actions/checkout` refuses fork checkouts in `pull_request_target` by default	Yes template injection, token permissions and dangerous triggers, before you push (CLI 0.6.0 or later); from CLI 0.7.0 it also says whether `actions/checkout`'s safe default covers each checkout, or the workflow opted out with `allow-unsafe-pr-checkout`

Guardrails vs a golden path

GitHub’s allowed-actions policy, now with blocking and SHA-pinning enforcement, is a good baseline: it stops unknown actions from running. What it can’t say is “every deploy must run org/security-scan v1.2+ before org/deploy”. That’s a pipeline contract:

secureci validate .github/workflows/deploy.yml --contract contracts/platform-standard.yml

Contracts are checked through composite actions and reusable workflows, so a required step can’t disappear behind a wrapper.

Keep one contract in a central repository and every team checks against it: --contract my-org/standards/contracts/platform.yml@<sha> fetches it like a remote reusable workflow and records the commit it enforced (details).

Trusting tags safely

Many teams allow tags from trusted owners such as actions/*. Since October 2026, GitHub’s workflow lockfiles (public preview) record the commit behind every action a workflow uses, including the actions those actions use, and run exactly that commit. On GitHub.com, that’s the strongest protection against a moved tag, and we recommend it.

GitHub’s lockfile isn’t available on GitHub Enterprise Server, and its gh actions-lock extension doesn’t lock local ./ actions. There, secureci inventory --check records each tag’s commit in secureci.lock and fails the pull request when one moves. It detects drift rather than controlling what runs.

Already using GitHub’s lockfile? You don’t need a second one: when actions.lock is your only lockfile, secureci inventory --check and the action’s inventory: check verify against it, so the same check runs on a laptop and in pull requests (CLI 0.3.0 or later).

Shift left, to the developer’s laptop

GitHub’s checks run after you push. SecureCI gives developers the same answer locally, and secureci run executes the workflow in a container, so CI changes are tested before they cost a pipeline run.

Recommended setup

Add SecureCI as a required check (secureci init workflow) with your pipeline contract. On GitHub Enterprise Server, also turn on inventory: check.
On GitHub.com, onboard your workflows to GitHub’s workflow lockfiles (gh actions-lock); inventory: check then verifies against actions.lock.
Turn on GitHub’s allowed-actions policy with SHA pinning required.
Enable Dependabot for github-actions so pins stay current, and CodeQL default setup.

Try the SecureCI CLI

Free and open source (MIT). Needs Node.js 20+ and, to run workflows, Docker, Podman or containerd.

npm install -g @secureci/cli
secureci validate .github/workflows/ci.yml
secureci run .github/workflows/ci.yml --dry-run

Get it on npm → Read the CLI docs

Running GitHub Actions across many repositories? Get early access to org-wide SecureCI →

FAQ

Do I still need SecureCI if I use GitHub’s allowed-actions policy, Dependabot and CodeQL?

Yes, if you have standards beyond “which actions may run”. SecureCI enforces required actions, their order and minimum versions, and runs the same checks locally before developers push. For moved tags, use GitHub’s workflow lockfiles on GitHub.com; SecureCI’s lockfile check covers GitHub Enterprise Server.

Does GitHub enforce SHA pinning for actions?

Yes. Since August 2025 the allowed-actions policy can require full commit SHAs. SecureCI enforces the same rule in a contract, with per-owner exceptions, and checks it locally and on pull requests.

Can GitHub require that a workflow runs specific steps in order?

Rulesets can require a workflow to pass, but not what happens inside it. SecureCI contracts require specific actions, in order, at minimum versions, checked through composite actions and reusable workflows.

Does SecureCI work with GitHub Enterprise Server?

Yes. Point GITHUB_SERVER_URL and GITHUB_API_URL at your GHES host; the CLI runs inside your own infrastructure.

Does GitHub’s PCI DSS attestation cover my workflows?

No. It covers GitHub as a service provider, with a shared responsibility matrix; controls over what your workflows run stay with you. SecureCI supports some of them, such as a PCI DSS 6.3.2 inventory of third-party actions and change control for workflows. See the compliance mapping.

Does SecureCI replace GitHub’s workflow lockfiles?

No. On GitHub.com, GitHub’s workflow lockfiles (public preview) run the exact commits you locked, including transitive dependencies, and we recommend them. SecureCI adds what they don’t cover: pipeline contracts (required actions, order, minimum versions), checks before you push (including against your actions.lock), and a lockfile check on GitHub Enterprise Server.

Sources

Competitor features change quickly. We checked these on 24 October 2026; if something here is out of date, email [email protected] and we'll fix it.