AI-Assisted Secure Coding (Appendix C) · CI/CD Pipeline Hardening Specific to AI Augmentation
Never run fork code with write access or secrets
Verify that workflows triggered by untrusted contributions (GitHub Actions `pull_request_target`, `workflow_run`, and equivalent fork-aware triggers in other CI systems) never check out, build, test, or otherwise execute untrusted code in a context that has repository write permissions or access to repository, organization, package-registry, cloud, or deployment secrets. Where a privileged follow-up step is needed, the untrusted contribution is first processed in an unprivileged `pull_request` workflow, and only validated passive artifacts are passed forward to a separate privileged workflow.
OWASP AISVS v1.01, requirement AC.12.1
In plain English
Some CI triggers run with write access and secrets even when the pull request comes from a stranger's fork. GitHub's pull_request_target and workflow_run are the well-known ones. Workflows on those triggers must never check out, build, test or otherwise run the untrusted code. Process it in an unprivileged workflow first, and pass only validated, passive results to a privileged one.
What good looks like
- No privileged workflow checks out or executes code from an untrusted contribution.
- Untrusted code is built and tested in an unprivileged pull_request workflow with a read-only token and no secrets.
- A privileged follow-up receives only validated, passive artifacts (see AC.12.7).
- Every use of a privileged trigger in the organisation is inventoried and reviewed.
How teams usually do it
- The split-workflow pattern from GitHub Security Lab's guidance on preventing "pwn requests".
- Static analysis of workflow files, for example with zizmor, or with CodeQL's Actions queries, to find dangerous checkouts.
- A default of read-only workflow token permissions across the organisation.
Suggested evidence
- Workflow files.
- The inventory and review of privileged triggers.
- Scanner results.
Common mistakes
- Checking out the PR head ref inside a pull_request_target workflow.
- Running an AI agent on fork content in a privileged workflow, which lets the PR's text steer a tool that holds secrets.
- Interpolating PR titles or branch names into shell scripts.
Not sure which requirements apply to your system? Take the assessment, or browse every guide in this chapter.
Requirement text from the OWASP AI Security Verification Standard, licensed under CC BY-SA 4.0. This guidance is shared under the same licence.