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
Workflows triggered by outside contributions, such as pull_request_target or workflow_run, must never check out or run untrusted code with write access or secrets. Process untrusted code in an unprivileged workflow first and pass only checked, passive results to a privileged one.
What good looks like
- Privileged triggers never run fork code.
- Untrusted code runs in unprivileged workflows.
- Only validated artifacts pass between them.
How teams usually do it
- The split-workflow pattern described in GitHub Security Lab's guidance on pwn requests.
Evidence an auditor would accept
- Workflow files and a review of privileged triggers.
Common mistakes
- Checking out the PR head in a pull_request_target workflow.
Not sure which requirements apply to your system? Take the assessment.
Requirement text from the OWASP AI Security Verification Standard, licensed under CC BY-SA 4.0. This guidance is shared under the same licence.