What it is
Modern attacks target the build pipeline more than the code, because the build pipeline holds the secrets and turns commits into deploys. The 2023 PyPI typosquatting waves, the 2022 GitHub OAuth integration breach, the recurring 'malicious GitHub Action' incidents, the colors.js and ua-parser-js sabotages — each one rode a supply-chain weakness more than a code-level bug. Repo security hygiene is unglamorous and unforgiving: branch protection on `main`, exact-SHA pinning on third-party Actions, secret-handling discipline in workflows, signed commits where it matters. None of it is novel; all of it is how you avoid being the next post-mortem.
How it happens
Common defect classes. The most dangerous: `pull_request_target` workflows that check out the head ref of the PR and execute build/test scripts. `pull_request_target` runs in the context of the base branch with full access to the repo's secrets — a malicious fork PR can extract secrets, push commits, or backdoor the CI. Third-party Actions referenced by tag (`uses: foo/bar@v1`): the tag is mutable, the upstream maintainer (or anyone who compromises the maintainer's account) can move it to point at compromised code. Secrets echoed in workflow logs: GitHub redacts known secret values from logs but only as exact substring matches; base64-encoded or partially-modified versions slip through. Unprotected default branches: any contributor with write access can rewrite history or merge unreviewed code straight to main.
Common variants
pull_request_target with head checkout
The single most-exploited supply-chain vector in GitHub Actions. Malicious PR runs in privileged context. CVE-class incidents have come from this exact pattern.
Unpinned third-party Actions
`uses: foo/bar@v1` instead of `uses: foo/bar@<full SHA>`. Tag mutability is a feature in npm-land; in CI it's a supply-chain risk vector.
Secret echo in workflow logs
`echo $SECRET` for debugging. GitHub redacts known values, but base64 / partial / transformed versions leak.
No branch protection
Default branch can be force-pushed and merged-to without review. Anyone with write access — or any compromised contributor account — rewrites history or pushes unreviewed code.
What an attacker gets
Supply-chain compromise. Code execution in your CI runner with your secrets means: stolen Stripe keys, AWS access keys, deploy tokens. Malicious commits pushed to main means a backdoored release. Compromised deploys means every customer of yours runs the attacker's code. The blast radius depends on what your CI has access to — for typical SaaS deployments, that's the entirety of production.
// what fixvibe reports
What FixVibe reports
Runs when you connect a GitHub repository, on Pro and above. Each finding shows the file and line, its severity and fix steps you can paste into your AI coding tool.
How to fix it
Require pull-request reviews + status checks on the default branch via GitHub's branch protection settings. At minimum: require 1 reviewer, require status checks to pass, prevent force-push, prevent deletion. Pin third-party Actions to full 40-char commit SHAs (`uses: foo/bar@2c4abf...`). Renovate keeps them automatically updated to the latest SHA, so you get the security benefit without the maintenance burden. Use `pull_request` (not `pull_request_target`) for workflows that test forked PRs; if you must use `pull_request_target`, never check out the head ref — check out the base branch and treat the PR diff as data, not code. Don't echo secrets in workflow steps; use `if: env.SECRET_NAME != ''` to verify presence without printing. Enable Dependabot security updates and code scanning. Use signed commits and require them on protected branches for high-stakes repos. As a defense-in-depth layer, scope your secrets aggressively: per-environment, per-workflow, with short-lived OIDC tokens to cloud providers instead of long-lived static keys where possible.