ci-workflow-audit

namespace	aiwg
name	ci-workflow-audit
platforms	["all"]
description	Audit CI workflow files for supply-chain risk — unpinned actions, unpinned container images, pull_request-triggered jobs with secret access, curl-pipe-shell installers, and bare :latest tags. Produces a structured markdown report with file:line refs.
triggers	["help with CI builds or deployment","help me make the build or deployment path safer","start with pipeline safety or release readiness","pipeline safety ci"]

ci-workflow-audit

Use this skill when a user wants a one-shot scan of their CI workflows for the supply-chain attack surface that the ci-action-pinning rule defines as forbidden. The rule is the gate (blocks new violations post-deployment); this skill is the discovery tool (surfaces existing violations in a user repo).

Pairs with npm-supply-chain-audit (npm-ecosystem audit) — together they cover most of the user-side risk surface that AIWG's own supply-chain hardening (v2026.5.3) addresses on the AIWG side.

Triggers

• "audit workflow pinning"
• "ci workflow audit"
• "are my actions pinned"
• "check container image pins"
• "scan workflows for secrets"
• "supply chain risk in CI"

Scope

Audits the following workflow file locations (all supported in parallel):

Platform	Path
GitHub Actions	.github/workflows/*.yml, .github/workflows/*.yaml
Gitea Actions	.gitea/workflows/*.yml, .gitea/workflows/*.yaml
GitLab CI	.gitlab-ci.yml, .gitlab/*.yml (where applicable)
Reusable workflows	uses: ./.github/workflows/* references (transitive)

Read-only. No mutations.

Audit sequence

1. Inventory workflow files

find .github/workflows .gitea/workflows -type f \( -name "*.yml" -o -name "*.yaml" \) 2>/dev/null
test -f .gitlab-ci.yml && echo ".gitlab-ci.yml"

Record the count. Each subsequent check iterates over this set.

2. Action-pin audit — fail on tag-pinned uses:

# Detect floating tags (semver tags, branches, latest)
grep -rnHE '^\s*-\s*uses:\s*[a-zA-Z0-9._-]+/[a-zA-Z0-9._-]+@(v?[0-9]+(\.[0-9]+)*|main|master|latest)\s*(#.*)?$' \
  .github/workflows/ .gitea/workflows/ 2>/dev/null

Each match is a finding. Severity: HIGH (workflow runs arbitrary third-party code with workflow's secret access).

Acceptable exception: uses: ./ references (local reusable workflows in the same repo) — these pin to the calling commit. Flag separately as INFO and recurse into them to check their uses: references too.

3. Container-image-pin audit — fail on tag-pinned container:/image:

grep -rnHE '^\s*(container|image):\s*[a-zA-Z0-9._/-]+:[a-zA-Z0-9._-]+\s*(#.*)?$' \
  .github/workflows/ .gitea/workflows/ 2>/dev/null \
  | grep -v 'sha256:'

Each match without @sha256: is a finding. Severity: HIGH (same attack surface as actions; container provides the execution environment for every step).

4. Bare :latest audit

grep -rnHE ':latest\b' .github/workflows/ .gitea/workflows/ 2>/dev/null

Each match is a finding. Severity: CRITICAL (:latest is the canonical anti-pattern — captures both digest absence AND the most volatile possible tag).

5. PR-secret-exposure audit

For each workflow file, check whether any job triggered by pull_request references secrets.*:

# Identify pull_request-triggered jobs
for f in $(find .github/workflows .gitea/workflows -name "*.yml" -o -name "*.yaml" 2>/dev/null); do
  # Extract jobs that run on pull_request and check for secret references
  awk '/^on:/,/^[a-z]/ { print }' "$f" | grep -q 'pull_request' || continue
  if grep -nE '\${{\s*secrets\.' "$f" >/dev/null 2>&1; then
    echo "POTENTIAL SECRET EXPOSURE in $f"
    grep -nE '\${{\s*secrets\.' "$f"
  fi
done

Each match is a finding. Severity: CRITICAL (a contributor PR from a fork can read repo secrets via the workflow's environment; classic supply-chain attack vector documented in the Shai-Hulud campaign).

Acceptable exception: jobs gated with if: github.event.pull_request.head.repo.full_name == github.repository (only trusted maintainer PRs). Flag as INFO and verify the guard.

6. Curl-pipe-shell installer audit

grep -rnHE 'curl[^|]+\|\s*(bash|sh)' .github/workflows/ .gitea/workflows/ 2>/dev/null

Each curl | sh pattern is a finding. Severity: MEDIUM unless the surrounding context includes a content-hash check (look for sha256sum, OBSERVED_SHA, EXPECTED_INSTALL_SHA) — if no hash check is present, severity is HIGH.

The recommended fix pattern (strict-mode opt-in) is documented in the ci-action-pinning rule section "Standalone tools pinned by version + checksum".

7. Pin-manifest presence audit

test -f ci/digests.txt || test -f .ci/digests.txt || test -f docs/ci/digests.txt

If no pin manifest exists, finding: MEDIUM (without a manifest, diffs that change pinned references are not auditable).

Output format

Produce a markdown report at .aiwg/security/working/ci-workflow-audit.md with the structure below. If the working directory doesn't exist, create it.

# CI Workflow Audit

**Generated**: <ISO timestamp>
**Repo**: <repo path or URL>
**Workflow files scanned**: <count>

## Findings

### CRITICAL — Bare :latest tags

- `<file>:<line>` — `<matching line>`

### CRITICAL — PR-triggered jobs reference secrets

- `<file>:<line>` — `<matching line>`
  Mitigation: Gate the job with `if: github.event.pull_request.head.repo.full_name == github.repository`
  OR move the secret-using step to a separate `workflow_run`-triggered workflow.

### HIGH — Unpinned actions (tag-pinned uses:)

- `<file>:<line>` — `<matching line>`
  Resolve the pin: `git ls-remote https://github.com/<owner>/<repo> refs/tags/<tag>`
  Replace `@<tag>` with `@<40-char-sha>` and add a trailing `# <version>` comment.

### HIGH — Unpinned container images

- `<file>:<line>` — `<matching line>`
  Resolve the digest: `docker pull <image>:<tag>` then `docker inspect <image>:<tag> --format='{{.Id}}'`
  Replace with `<image>:<tag>@sha256:<digest>`.

### HIGH — curl|sh without hash check

- `<file>:<line>` — `<matching line>`
  Add observed-SHA logging and strict-mode opt-in per ci-action-pinning rule §
  "Standalone tools pinned by version + checksum".



  — 



 No  (or equivalent) found. Create one before applying any pinning fixes
  — the manifest is the source of truth for diff review of future pin bumps.



  — 
  Recursive check result: 



  — guard present: 



 All workflow files have at least one signed-tag verification step (or none required).
 No unpinned references found in  family.
 ...



Suggested order:

 Resolve and apply digest pins for CRITICAL findings first (largest blast radius).
 Establish or update  to reflect the resolved pins.
 Move PR-secret-exposure findings out of -triggered workflows.
 Add observed-SHA logging to all  installers (HIGH → MEDIUM).
 Re-run this audit. Iterate until clean.



If findings exceed a one-PR fix scope, file follow-ups for each finding category:

  — bulk-pin all  references
  — bulk-pin all container images
  — restructure PR-triggered workflows that reference secrets
  — add content-hash checks to all  installers



 []() — the enforcement gate
 AIWG's own []() — pin-manifest reference
 []() — npm-ecosystem complement

Incident-response trigger

If the audit surfaces a pull_request-triggered job with secrets.* references that has been merged to the default branch within the past 90 days, treat it as an incident-response candidate:

1. Check the workflow run history for that file via gh run list --workflow=<file> (GitHub) or mcp__git-gitea__actions_run_read (Gitea)
2. Inventory any external contributor PRs that triggered the workflow during the exposure window
3. Rotate any secrets the workflow could have read

The other audit findings are configuration-hardening, not active incidents — fix and move on.

Completion criteria

The skill is "done" when:

• All seven audit checks have produced findings (or a Clean Check note)
• A markdown report is written to .aiwg/security/working/ci-workflow-audit.md
• The report's Remediation Plan section lists every finding in suggested fix order
• If any CRITICAL finding is present, the user has been explicitly notified before the skill exits

See Also

• npm-supply-chain-audit skill
• supply-chain-hardening-quickstart skill
• ci-action-pinning rule
• supply-chain-trust skill — broader trust-chain design

References

• AIWG supply-chain hardening post-mortem 2026-05 (Shai-Hulud campaign response)
• GitHub Actions documentation: pinning third-party actions to commit SHAs
• npm trusted publishers documentation
• Sigstore / cosign documentation