In April 2022, GitHub disclosed that an attacker had used stolen OAuth tokens issued to Heroku and Travis CI to pull private repository contents from dozens of organizations — including npm's own source code. No malware, no CVE, no phishing email at the final step. Just a trusted third-party integration with broad, unmonitored access sitting quietly in an SCM's settings page. That incident captured something most security programs still underweight: the source-code manager itself — GitHub, GitLab, Bitbucket, Azure DevOps — is a production system with its own configuration, its own permissions, and its own attack surface. Its health is rarely measured the way teams measure a server's patch level or a container image's CVE count. Repository health covers branch protection, permission sprawl, dormant collaborators, leaked secrets, and third-party app grants. Tools built to scan code for vulnerabilities, like Checkmarx, say almost nothing about whether the repository hosting that code is itself configured securely. Keeping a secure source code repository takes more than clean code — it means auditing the SCM configuration itself. Here's what repository health security actually means, and where the coverage gaps are.
What is "repository health" and why does it matter for supply chain security?
Repository health is the security posture of the SCM configuration surrounding your code — not the code itself. That includes who has admin rights on a repo, whether branch protection rules are enforced on the branches that actually ship to production, which OAuth apps and GitHub Apps have been granted access, whether deploy keys and personal access tokens are scoped and rotated, and whether CI/CD workflow files can be modified without review. The 2020 SolarWinds compromise is the textbook case: attackers didn't need a code vulnerability, they needed build-pipeline access, and they got it partly through weak isolation between the build environment and source control. Gartner and other analysts now treat SCM posture as a distinct pillar of software supply chain security, separate from SAST, SCA, and secrets scanning — because a perfectly clean codebase sitting behind a misconfigured repository is still an open door. Checkmarx's One platform is built around static analysis, software composition analysis, and IaC scanning of what's inside the repo; it was not designed to continuously assess the repo's own settings.
How do unprotected branches let a single compromised token rewrite production code?
They let it happen because without branch protection, a push directly to main requires nothing more than valid write credentials — no review, no status checks, no second approver. In March 2024, the discovery of the XZ Utils backdoor (CVE-2024-3094) showed how a trusted maintainer relationship, cultivated over two years, was used to slip obfuscated malicious code into a widely-used compression library that fed into OpenSSH. The attacker didn't need to defeat a scanner; they needed commit access and an absence of independent review gates. Similarly, in the March 2025 compromise of the popular tj-actions/changed-files GitHub Action (used in an estimated 23,000+ repositories), attackers modified tagged releases to exfiltrate CI secrets — an attack made dramatically easier when workflow files and action pins aren't protected from unreviewed changes. A repository with enforced branch protection, required reviews, and pinned (not floating) dependency references closes off exactly this path. Repository health scanning checks for these controls across every branch that matters — not just main — because staging and release branches are frequently left unprotected.
Why are dormant repositories and stale collaborators a hidden entry point?
Because access doesn't expire just because a project goes quiet, and attackers specifically hunt for exactly this gap. A repository that hasn't been touched in 18 months but still has five contractors with write access, an old Slack integration with a stale webhook secret, and an admin account belonging to someone who left the company two years ago is a fully functional backdoor that nobody is watching. Verizon's 2024 Data Breach Investigations Report found that credential-based attacks remain involved in over 30% of breaches, and stale non-human and third-party credentials are among the least frequently rotated. Organizations running hundreds or thousands of repositories — common at any company past Series C — routinely lose track of which repos are archived-in-name-only versus genuinely decommissioned, and permission audits rarely reach further than the actively developed 20%. Checkmarx's scanning runs against code that's actively submitted for analysis; it has no native mechanism for surfacing a forgotten repository that was never re-scanned because no pipeline touches it anymore.
How did the 2022 GitHub OAuth token theft campaign exploit SCM trust relationships?
It worked by abusing the trust organizations extend to third-party integrations, not by breaking GitHub itself. Attackers stole OAuth user tokens issued to Heroku and Travis CI — two CI/CD integrations widely granted repository read access — and used those tokens to download private repository contents from at least 100 organizations before GitHub revoked the tokens on April 12, 2022. The campaign succeeded because those integrations had been granted access scopes far broader than their actual use case required, and because no one at the affected organizations was monitoring which third-party apps held live tokens against their source code. This is a structural SCM risk: every CI provider, code-review bot, and productivity integration an engineering org connects to GitHub or GitLab becomes a standing credential with repository access, and most security teams have no inventory of what's connected, what scope it holds, or when it was last used. Application security scanners have no visibility into this layer at all — it lives entirely in SCM settings, not in code.
What role do exposed secrets and CI/CD credentials play in SCM-layer breaches?
They turn a single leaked string into full pipeline compromise, and it keeps happening at scale. The January 2023 CircleCI breach, disclosed publicly on January 4, resulted in the company urging every customer to rotate all secrets stored in the platform — API keys, database credentials, and SCM tokens alike — after attackers compromised an engineer's laptop and session cookies to access production systems. Two years earlier, the April 2021 Codecov Bash Uploader compromise went undetected for roughly two months while attackers harvested environment variables — including cloud credentials and SCM tokens — from thousands of customer CI pipelines. GitGuardian's 2024 State of Secrets Sprawl report found over 12.7 million secrets exposed in public GitHub commits in a single year, a number that has grown annually despite widespread secrets-scanning adoption, because most scanning only covers new commits going forward, not the full commit history, forks, and gists where old secrets remain live and valid indefinitely. Repository health assessment has to include commit history and fork lineage, not just the current HEAD.
Why do AppSec platforms like Checkmarx typically miss these SCM-layer risks?
Because they're architected to analyze code artifacts, not to continuously monitor the identity, permission, and configuration layer that surrounds the code. Checkmarx One's core strength is SAST and SCA — finding vulnerable patterns and outdated dependencies inside a codebase — plus IaC and container scanning bolted on through acquisitions. That's valuable, but it answers "is this code safe" rather than "is the environment this code lives in safe." Questions like which of your 400 GitHub organizations enforce two-factor authentication, which repos allow force-pushes to release branches, which service accounts have organization-owner rights they haven't used in a year, and which forks of an internal repo are public sit entirely outside a code-scanning platform's scope. Teams that rely solely on SAST/SCA coverage frequently discover, only after an incident, that the breach vector was a repository setting, not a line of code the scanner ever touched.
How Safeguard Helps
Safeguard treats the SCM itself as a first-class asset to secure, continuously scoring repository health across every organization, repository, and branch you own — not just the ones a pipeline happens to scan. That means ongoing checks for branch protection coverage on production-relevant branches, stale or over-scoped collaborator and machine-user access, third-party OAuth and GitHub App grants (closing exactly the gap the 2022 Heroku/Travis CI campaign exploited), unpinned or floating Action and workflow references (the pattern behind the tj-actions incident), and secrets present anywhere in commit history, forks, or gists — not just new commits.
Safeguard correlates these findings with your actual dependency and CI/CD graph, so a stale admin account on a dormant repo that still feeds a live build pipeline gets flagged with the urgency it deserves, while genuinely archived, unreferenced repositories don't drown your team in noise. Where Checkmarx and similar AppSec platforms tell you your code is clean, Safeguard tells you whether the repository hosting that code — and every integration, token, and permission attached to it — is itself defensible, so you keep a secure source code repository as access and integrations change over time, not just at the moment you last audited it. For teams that already run SAST and SCA, that's not redundant coverage; it's the layer those tools were never built to see.