Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
Repository compromise response checklist
Updated
Revoke repository access, tokens, and deploy keys. Diff for malicious commits and workflow changes. Rotate any secret that sat in history. Ask whether a published artifact was poisoned. This page is not legal advice.
Operational guidance, last verified 7 September 2026 against GitHub's Responding to a security incident (enterprise/organization incident tutorial — vendor documentation, not a statute, not ranked over any other host), GitLab's Responding to security incidents (Self-Managed and GitLab.com supplement — vendor documentation, not a statute, not ranked over any other host), CISA's Supply Chain Compromises Impact Nx Console and GitHub Repositories alert (28 May 2026 — a cybersecurity alert, not a statute), SLSA v1.2 Threats & mitigations (source-track threat (B) modifying the source and (C) source-code management; build-track threat (F) artifact publication — a specification, not a statute), and the OpenSSF Source Code Management Platform Configuration Best Practices (Best Practices Working Group, 2023-08-29 — industry practice covering GitHub and GitLab equally, not a ranking). Pointers to each host's incident documentation are equal. This page does not start a notification clock and is not a substitute for counsel, your insurer, or a retained DFIR firm. Not legal advice.
Audit access and tokens first — this is not a statute
Audience: the incident commander facing a compromised source repository (stolen account, leaked token, planted commit, or tampered workflow), and counsel, the insurer, and DFIR on the out-of-band bridge. The we've-been-breached page on this site is the first-moves hub. The preserve-evidence page on this site is the capture order for audit logs, commit objects, and workflow runs. The credential-compromise-checklist page on this site is the revoke-rotate-hunt for the identity that minted the repo tokens. The who-to-call page on this site is the contact order. This page is the repository-compromise runbook: audit members, tokens, and deploy keys; hunt malicious commits and workflow changes; rotate secrets that sat in history; then ask whether a published artifact was poisoned. It does not rank GitHub or GitLab, does not rank DFIR firms, does not name either host as the source of truth, and does not start a notification clock.
GitHub's Responding to a security incident (last verified still listed on 7 September 2026) sequences assess, contain (revoke credentials, restrict access, stop malicious workflow runs), investigate, remediate (rotate tokens and secrets, audit persistence including deploy keys and workflow files), and document — vendor documentation, not a statute. GitLab's Responding to security incidents sequences credential exposure, suspected compromised user, CI/CD-related incidents, and misconfigured project settings, and tells you to revoke or rotate the token after assessing impact, then review audit events for newly created users, tokens, malicious pipelines, changes to code, and changes to project settings — vendor documentation, not a statute. Neither host's page outranks the other. CISA's 28 May 2026 supply-chain alert tells organizations that discover a compromise to rotate and revoke all secrets accessible to CI/CD, including GitHub/GitLab/Bitbucket tokens and SSH keys, and to audit workflow files and contributor activity for suspicious pull requests and direct commits. Last verified 7 September 2026. Not legal advice.
- Revoke access and tokens first, then hunt planted changes, then rotate secrets that sat in history. A revert without a revoked deploy key is not containment. GitHub: for exposed or exploited credentials, the most immediate action is to revoke the affected credentials. GitLab: revoke or rotate after you have assessed scope and potential impact.
- Do not tip the actor. No in-band 'we see you', no public status page, no mass force-push from a possibly compromised identity. GitHub: preserve evidence and keep a record before cleanup. The preserve-evidence page on this site is that hold.
- The cloud-account-compromise-checklist page on this site is the preserve-logs-first tenant runbook when a repo token minted cloud keys. The cicd-compromise-checklist page on this site is the freeze-and-audit, secret-rotation, and artifact-provenance runbook. The supply-chain-incident-checklist page on this site is the vendor-incident intake, blast-radius, and flow-down runbook.
- This page does not rank hosts, does not rank GitHub or GitLab, does not interpret YOUR policy, does not start a notification clock, and is not legal advice.
What to do now
Walk top to bottom. Unknowns belong on the list. Last verified 7 September 2026. Not legal advice.
- Declare the incident. Name one commander. Open an out-of-band bridge the actor cannot see (phone, a clean conference). The who-to-call page on this site is the contact order.
- Place the evidence hold on source-control audit logs, commit objects, reflogs, workflow-run logs, package and release records, and webhook deliveries. Do not force-push, delete the repo, or rotate those logs away to 'clean up.' GitHub: take screenshots, export logs, and save copies of affected files or code before cleanup. GitLab: document the time of credential exposure and the time you revoked. The preserve-evidence page on this site is the capture list.
- Revoke repository access and tokens: members and outside collaborators added in the dwell window, personal access tokens, OAuth and GitHub App / GitLab application grants, deploy keys, deploy tokens, SSH keys, runner tokens, pipeline trigger tokens, and webhooks pointing at unknown destinations. This product does not revoke deploy keys and does not rotate GitHub or GitLab tokens.
- Hunt planted commits and workflow tampering: unexpected commits on protected branches, force-pushes, moved tags, new or edited workflow files, CI variables, branch-protection changes, and unknown GitHub Apps or GitLab hooks. This product does not hunt malicious commits.
- Rotate every secret that sat in the repository, in history, in forks, in CI logs, or in artifacts. Deleting the line is not rotation. CISA (28 May 2026): rotate and revoke all credentials, tokens, and secrets accessible to CI/CD, including API keys, cloud credentials, SSH keys, registry tokens, and GitHub/GitLab/Bitbucket tokens.
- Ask whether a published artifact was poisoned: did a pipeline run from the planted revision; were packages, containers, or GitHub/GitLab Releases published; do downstream consumers need a hold. SLSA v1.2 threat (F) is artifact publication that does not reflect the official source. The cicd-compromise-checklist page on this site is that freeze-and-audit runbook.
- Page counsel and the insurer if YOUR plan or policy requires prompt notice. A planted commit in a public repo can still be a notification question. This page does not start a clock.
Access-and-token audit
Containment for a compromised repository is not 'kick the user and hope.' GitHub's incident tutorial treats credential revocation as the most immediate action and lists deploy keys, GitHub Apps, and OAuth authorizations among the persistence to audit after. GitLab's incident guide treats personal access tokens, group/project access tokens, runner tokens, pipeline trigger tokens, and SSH keys as credential-exposure types, and tells you to look for audit events that create tokens, SSH keys, or user accounts to maintain persistence. Walk the rows. Last verified 7 September 2026. Not legal advice.
| Surface | What 'done' looks like | If you skip it |
|---|---|---|
| Members, collaborators, teams | Every member, outside collaborator, invited user, and team added or privilege-escalated in the dwell window is inventoried. Unexplained access is removed. Remaining access has an owner. | The actor keeps a second account you never kicked. GitLab: adversaries create tokens, SSH keys, or user accounts to maintain persistence. |
| Personal access tokens and OAuth / app grants | PATs (classic and fine-grained), OAuth app tokens, GitHub App user and refresh tokens, GitLab personal / group / project access tokens, and runner or pipeline-trigger tokens for the compromised identity are revoked at the issuer. GitHub documents a REST credentials-revoke endpoint when the literal token value is known. | A new password with the old PAT still live is not containment. GitHub: PATs and app tokens bypass the interactive MFA prompt. This product does not rotate GitHub or GitLab tokens. |
| Deploy keys, deploy tokens, SSH keys | Every deploy key, deploy token, and SSH key on the repo and on the user is listed. Unexplained keys are deleted at the host. Remaining keys have an owner, a scope (read-only vs write), and a rotation date. | A deploy key is a standing credential on the repo, not on the user you just blocked. This product does not revoke deploy keys. |
| Webhooks and integrations | Webhooks, Git hooks, authorized OAuth applications, and installed GitHub Apps / GitLab integrations point at named, owned destinations. Unknown URLs are disabled. GitHub: a compromised webhook is a live exfiltration channel; disable it. | You kicked the user and left a webhook posting every push to the actor. |
| Service accounts and bots | Bot and machine identities that can push, approve, or register runners are inventoried. Unexplained bots are blocked. Remaining bots have an owner and a token that was rotated after first-access. | CISA (28 May 2026): audit contributor activity for suspicious pull requests and direct commits, particularly those authored by automated accounts (build-bot, auto-ci, ci-bot, pipeline-bot). |
Malicious-commit and workflow-tamper hunt
Rotation without a hunt leaves the commit the actor planted. GitHub's investigation areas cover malicious code injection (suspicious code changes, unexpected workflow runs, new files) and tell you to use audit logs, activity view, code search, and workflow-run logs. GitLab tells you to review audit events for changes to repositories, changes to group or project configurations, addition or modification of runners, webhooks or Git hooks, and CI-related events that modify CI/CD variables, and to review job logs for pipelines the adversary ran. CISA (28 May 2026) asks you to monitor and audit workflow files and contributor activity, and to revert unauthorized changes, especially from automated accounts. OpenSSF SCM Best Practices (industry practice) treat default-branch review, protected branches, and read-only default workflow tokens as configuration — not a ranking of hosts. Last verified 7 September 2026. Not legal advice.
| What to hunt | What to look for | What 'cleared' looks like |
|---|---|---|
| Unexpected commits on protected branches | Direct pushes, unsigned commits if you require signatures, unknown authors, commits that arrived without a reviewed merge, force-pushes that rewrote history, tags moved to a different SHA. | Each commit in the dwell window has a named author you can place, a review record, and a parent that still exists. Unexplained commits are reverted from a known-good revision, not force-pushed away until counsel and DFIR say the evidence copy exists. This product does not hunt malicious commits. |
| Workflow and pipeline files | New or edited GitHub Actions workflows under .github/workflows, GitLab CI files (.gitlab-ci.yml and includes), reusable workflows pointing at an unexpected repo or SHA, workflow_dispatch or pipeline triggers the team did not add. CISA's Megalodon campaign injected malicious GitHub Action workflows to harvest CI/CD secrets, cloud credentials, and tokens. | Every workflow file matches a known-good tree. Unexplained workflows are disabled and the runs they spawned are cancelled. The cicd-compromise-checklist page on this site is the freeze-and-audit runbook; the planted file is still this row. |
| CI variables, secrets, runners | New CI/CD variables, unmasked secrets in job logs, new self-hosted runners, runner registration tokens, pipeline trigger tokens. GitLab: CI-related audit events and job logs. GitHub: cancel in-progress runs, disable Actions for the repo, remove self-hosted runners. | Unexplained variables and runners are removed. Remaining secrets were rotated after first-access. Job logs from the dwell window are under the evidence hold, not deleted. |
| Branch protection and project settings | Required reviews removed, status checks skipped, force-push re-enabled, visibility flipped to public, merge-request approval settings weakened. GitLab: misconfigured project or group settings, including visibility, MR approval, protected branches, and suspicious webhooks. SLSA v1.2 (B1): a highly-permissioned actor disables controls, pushes, then re-enables them. | Protections match a known-good policy. Unexplained changes are reverted. Audit events for the change are exported before anyone 'fixes' the setting. |
| Persistence files the review UI may hide | New deploy keys, pre-commit / pre-push / update hooks, submodule URLs, Git LFS pointers, binary blobs, and files that look like documentation but are executable. SLSA v1.2 (B2): a change that looks benign to a reviewer can still be malicious. | Unexplained files are removed from the default branch after an evidence copy exists. Remaining hooks and submodules have an owner. |
Rotate secrets that sat in history
A secret committed to git, pasted into a ticket, stored as a CI variable, or baked into an image is a live credential in a place the actor can read — now or from history. Version control keeps the old value. Deleting the line is not revocation. Forks, clones, CI logs, and artifact stores still hold the old copy. Last verified 7 September 2026. Not legal advice.
- Treat a committed secret as already compromised. Rotate at the issuer, revoke the old value, then remove it from code going forward. GitHub: even if you are not certain a credential was compromised, rotate it if there is any possibility of exposure. GitLab: revoke or rotate after assessing production impact.
- CISA (28 May 2026) lists what to rotate after a source or CI compromise: API keys, cloud provider credentials, SSH keys, Docker/npm/PyPI/Vault/Terraform/Kubernetes tokens, GitHub/GitLab/Bitbucket tokens, and developer or pipeline secrets. Walk that list against YOUR issuers.
- History, forks, CI logs, release assets, and container layers still hold the old copy after you delete the line. A git filter-repo is not rotation. Do not rewrite history until counsel and DFIR have an evidence copy.
- This product does ingest GitHub secret-scanning alerts into Security findings (exposed secrets as findings). It does not rotate the secret, revoke the token, or hunt whether that key was used.
Was a release poisoned?
A planted commit is a source-integrity problem. A pipeline that ran from that commit, or a package that was published from it, is a supply-chain problem. SLSA v1.2 models source threats (B) modifying the source and (C) source-code management separately from build threats (F) artifact publication and (G) distribution channel. Provenance that names the expected source does not help if the source itself was rewritten. CISA (28 May 2026) tells organizations that discover a compromise to conduct a forensics review of CI/CD logs, cloud audit trails, and affected developer machines, and to notify proper stakeholders if necessary. The cicd-compromise-checklist page on this site is the freeze-and-audit runbook. The supply-chain-incident-checklist page on this site is the vendor-incident intake, blast-radius, and flow-down runbook. Last verified 7 September 2026. Not legal advice.
- Inventory pipeline runs, GitHub/GitLab Releases, package-registry publishes (npm, PyPI, containers, Maven, crates), and signed artifacts whose source SHA falls in the dwell window. Unknown publishes are a gap, not a clean bill.
- If a release may have been poisoned: yank or unpublish only after you have a copy and a consumer-notification plan; pin downstream consumers to a known-good digest; rotate signing keys if the actor could have used them. SLSA: verifiers reject an artifact whose provenance subject does not match the hash they received — that check does not catch a build that honestly built the planted source.
- This product's blast-radius search is over captured dependencies — transitive npm when a lockfile was fetched. That is package exposure in YOUR tree, not a finding that a release you published was poisoned and not a hunt for planted commits.
Where this shows up in ShipReady Metrics
The signed-in app does not revoke deploy keys, hunt malicious commits, rotate GitHub or GitLab tokens, disable workflows, cancel pipeline runs, or unpublish a poisoned release. It does ingest security findings, including GitHub secret-scanning alerts (exposed secrets as findings, typically critical), Dependabot alerts, and code-scanning / SAST findings (ingested GitHub code scanning plus this product's first-party SAST engine). Security findings is where those land, alongside DAST. Security also has a blast-radius search over captured dependencies — transitive npm when a lockfile was fetched — which is package exposure, not a planted-commit hunt. The GitHub connector and GitHub App are read-only (Contents, Metadata, Pull requests, Actions, Administration, Dependabot/code/secret-scanning alerts; org Members) — nothing writable. If you already have a session: signed-in app → Compliance → CRA reporting tracks the 24-hour / 72-hour / 14-day ladder from your recorded awareness for findings the org has classified as CRA-in-scope. That ladder is not a repository-compromise runbook, it does not start a clock for you, and it is not a determination that CRA applies. A named human still submits. None of those surfaces revokes a deploy key or rotates a GitHub token.
Primary sources (last verified 7 September 2026)
Every operational claim on this page is taken from one of these. If a later revision of a source changes the advice, the date above is how you can see we have not re-checked yet.
GitHub, Responding to a security incident (code-security tutorial for enterprises and organizations) remains the current GitHub incident-response tutorial this page cites for assess / contain / investigate / remediate / document, credential revocation, stopping malicious workflow runs, and auditing persistence (deploy keys, workflow files, GitHub Apps, webhooks) — vendor documentation, not a statute, last verified still listed on 7 September 2026. GitHub, Common security incident investigation areas is the companion reference for exposed credentials, malicious code injection, and workflow-run review. GitLab, Responding to security incidents remains the current GitLab incident-response guide this page cites for credential exposure (passwords, personal / group / project access tokens, runner tokens, pipeline trigger tokens, SSH keys), suspected compromised user (block, reset credentials the user could view, reset password, enable 2FA), CI/CD incidents, and misconfigured project settings — vendor documentation, not a statute, last verified still listed on 7 September 2026. Neither host's documentation is treated as the source of truth over the other; this page does not rank GitHub or GitLab. CISA, Supply Chain Compromises Impact Nx Console and GitHub Repositories (alert, 28 May 2026) remains the current CISA supply-chain alert this page cites for auditing workflow files and contributor activity, reverting unauthorized changes from automated accounts, rotating and revoking CI/CD-accessible secrets (including GitHub/GitLab/Bitbucket tokens and SSH keys), and reviewing CI/CD logs — a cybersecurity alert, not a statute. SLSA v1.2, Threats & mitigations remains the current SLSA threat model this page cites for source threats (B) modifying the source and (C) source-code management, and build threats (F) artifact publication — a specification, not a statute. OpenSSF Source Code Management Platform Configuration Best Practices (Best Practices Working Group, 2023-08-29) is industry practice for SCM configuration covering GitHub and GitLab equally (authentication, access control, protected default branches, workflow-token permissions) — not a ranking and not a statute. NIST SP 800-61r2 remains the current final Computer Security Incident Handling Guide this cluster cites for containment then eradication then recovery.
Frequently asked questions
What should we do first after a source repository is compromised?
Revoke repository access, tokens, and deploy keys; preserve audit logs and commit objects; then hunt planted commits and workflow changes; then rotate every secret that sat in history; then ask whether a pipeline published a poisoned artifact. GitHub's incident tutorial treats credential revocation as the most immediate action. GitLab's incident guide tells you to revoke or rotate after assessing impact. CISA (28 May 2026) tells you to rotate CI/CD-accessible secrets including GitHub/GitLab/Bitbucket tokens. Not legal advice.
Should we force-push to erase the malicious commit?
Not first. GitHub: preserve evidence and save copies of affected files or code before cleanup. GitLab: document the time of exposure and the time you revoked. A force-push that rewrites the default branch destroys the evidence copy and does not revoke the deploy key or the PAT the actor still holds. Revert from a known-good revision after the evidence hold is in place. SLSA v1.2 (B2) treats rewritten history as a way to hide malicious activity. Not legal advice.
Does deleting a secret from git history revoke it?
No. Version control, forks, clones, CI logs, and artifact stores still hold the old value. Rotate at the issuer, revoke the old credential, then remove it from code going forward. CISA (28 May 2026) lists GitHub/GitLab/Bitbucket tokens, SSH keys, cloud credentials, and registry tokens among what to rotate after a source or CI compromise. This product ingests GitHub secret-scanning alerts into Security findings; it does not rotate the secret. Not legal advice.
Does ShipReady Metrics revoke deploy keys, hunt malicious commits, or rotate GitHub tokens?
No. The signed-in app does not revoke deploy keys, hunt malicious commits, rotate GitHub or GitLab tokens, disable workflows, or unpublish a release. It does ingest security findings, including GitHub secret-scanning alerts, Dependabot alerts, and code-scanning / SAST findings (ingested plus this product's first-party SAST). Blast-radius search is package exposure over captured dependencies, not a planted-commit hunt. Compliance → CRA reporting is a ladder from recorded awareness, not a clock this product starts. Not legal advice.
Is this legal advice?
No. It is operational guidance distilled from GitHub's Responding to a security incident, GitLab's Responding to security incidents, CISA's 28 May 2026 supply-chain alert, SLSA v1.2 Threats & mitigations, and the OpenSSF SCM Best Practices. Whether a notification duty has started, whether a planted commit was 'unauthorised access' under a named statute, and what you may say externally are questions for counsel on YOUR facts. This page does not rank GitHub or GitLab and does not start a notification clock.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.