04
CI/CD & supply chain
Your build pipeline has access to production. One injected command changes everything.
Attackers increasingly target build pipelines rather than applications directly, because pipelines have access to production credentials, deployment keys, and every environment your code touches. This assessment finds every path from an untrusted pull request or a leaked secret to full deployment access.
What I test
- →Pipeline injection: can a pull request title, branch name, or commit message trigger unintended commands during the build?
- →Credential leakage: are secrets printed in build logs or cached between pipeline runs?
- →Hardcoded credentials: are API keys or passwords stored in the repository or its commit history?
- →Dependency confusion: could a malicious package be installed instead of a legitimate internal one?
- →Pipeline permissions: do build jobs have more access to production systems than they need?
- →Self-hosted runner security: is the build machine exposed to the internet or insufficiently isolated?
- →Third-party build dependencies: could an external action or script used in your pipeline run attacker-controlled code?
- →Artifact integrity: are build outputs verified before deployment?
Build pipelineCredential leakageDependency securityGitHub ActionsGitLab CI
Example findings
CRITICALPull request title injected into build script. Code executed directly in the production deployment.
CRITICALAWS credentials printed in a build log. Keys valid, unrestricted access to production.
HIGHBuild server reachable from the internet with no authentication required.
HIGHExternal build dependency not pinned to a specific version. Attacker can push a malicious update.
Illustrative examples, not exhaustive.
Deliverable
Request this assessment →Pipeline security report with findings per workflow. Includes corrected workflow templates ready to use.