Most engineering teams believe that because their code lives on GitHub or Azure DevOps, it's properly backed up.
That assumption is wrong.
Teams usually discover this fact mid-incident, when they reach for something they need and discover it isn’t there.
GitHub and Azure DevOps are excellent platforms. But they are not backup solutions. The gap between those two things is where attackers, accidental deletions, and auditors do their damage.
These platforms are no longer just where code lives. They now hold the automation, CI/CD pipelines, and Infrastructure as Code that run the business, which is exactly why they've become a target. Gartner projects 80 percent of organizations will run on a DevOps platform by 2027, up from 25 percent in 2023.
What Native Protection Actually Covers
GitHub has a real safety net: if someone simply deletes a repository, GitHub holds it in a soft-deleted state for 90 days, and you can restore it yourself from settings. Unlike Microsoft 365, a compromised admin cannot empty that recycle bin.
But there is one important exception: a deleted repository cannot be restored if it was part of a fork network that still has other forks in it. In enterprises where forking is routine, a deleted parent repository with active forks left behind falls outside the 90-day net entirely, and GitHub blocks the restore with an error.
Rubrik can sidestep this, because recovery recreates the repository and pushes your protected history and settings into it independently of the old fork network.
The problem is that this is not how a real attacker holds an organization hostage. Deleting the repository is exactly what trips that safety net. The modern playbook leaves the repository in place and destroys what lives inside and around it, in the corners that have no recycle bin at all.
With a compromised admin token, an attacker strips branch protection across every repository, then overwrites history by force-pushing a ransom commit over your main branch. Your real code is still there physically, but nothing points to it anymore. It is a set of orphaned commits waiting to be swept away.
Attackers do the same thing to encrypt or replace an entire commit history, not just a single branch. They go after everything that is not Git history: releases, tags, CI/CD secrets, webhooks, and issues. That data lives in GitHub's own database, and once it is deleted there is no recycle bin and no self-service undo. This is also why a developer's local clone is not a safety net. A git clone only pulls the code and commit history, not the releases, pipeline secrets, webhooks, issues, or repository settings, so the copy on someone's laptop is missing everything that is not Git itself.
Now try to recover from that. The 90-day restore does not help, because nothing was deleted. To get your code back you need the exact commit reference from the moment before the overwrite. That will only work until GitHub sweeps away the orphaned commits, which happens somewhere between a few days and about two weeks. The manual path is to dig through each repository's activity log for the force-push event, compare it, cut a new branch, and open a pull request to merge it back, one repository at a time. Do this across hundreds of repositories in the middle of a live incident and your recovery time stretches from minutes into days.
Azure DevOps is no different in the ways that matter. Microsoft maintains internal point-in-time backups of the underlying databases, but those exist for Microsoft's own disaster recovery, not for yours. The documentation is blunt about it: "We don't support restoring assets that customers accidentally delete." A deleted organization is recoverable for 28 days, then it is gone. Individual work items are a partial exception. Deleted work items land in a Recycle Bin and can be restored with their comments, attachments, and history intact. However, that Recycle Bin lives inside the same tenant, and a compromised project administrator can destroy a work item permanently, which skips the Recycle Bin entirely and cannot be undone by you or by Microsoft.
On Azure DevOps it is worse in one respect: an attacker with the right access can empty the recycle bin through the API, hard-deleting a repository and removing even the soft-delete net that might otherwise save you.
The common thread: native version control was built to track changes, not to survive a breach or an accident. Retention is short, recovery is coarse, and the copy you would restore from sits inside the same blast radius as the thing you are recovering from. This is the shared responsibility model, and most teams have not caught up to it. Under it, GitHub and Microsoft keep the platform running. Protecting and recovering the data inside your tenant is your job, not theirs. The shared responsibility model is explicit that you always own your data and its recoverability.
Why This Matters Now
The exposure is growing on two fronts.
Attacks on code are not new, but they are increasing and turning more destructive. In 2019 a coordinated ransom campaign used exposed Git credentials to wipe history across GitHub, GitLab, and Bitbucket at once. In 2024 the Gitloker campaign hijacked accounts through malicious OAuth apps and wiped repositories for extortion. In 2026, attackers exfiltrated roughly 3,800 of GitHub's own internal repositories through a poisoned VS Code extension. And the pattern has shifted from theft to destruction: in the Trivy supply chain attack, one threat group used stolen tokens to delete 178 legitimate software releases, and force-push campaigns have overwritten commit history on default branches outright. We break this wave down in “The Code Deletion Threat.”
Gartner predicted 45 percent of organizations would hit a software supply chain attack by 2025, three times the 2021 rate, and reality has already run past it. None of these attacks were exotic. They used valid credentials, a phishing email, or a trusted tool, and native version history offered no defense because the attacker owned the same domain the history lived in.
AI coding agents widen the attack surface. AI coding agents now commit code, open pull requests, and modify infrastructure definitions at machine speed, faster than any review cycle was designed to catch. That means flawed commits at scale, dependencies pulled in without a human in the loop, and changes that are hard to audit after the fact. Your repositories are no longer just where the application lives. They are where the business is built, and increasingly where automated systems have write access.
The Do-It-Yourself Trap
When teams realize native tooling falls short, the usual next step is a script. Clone every repo on a schedule, push it somewhere, call it a backup.
That approach breaks under real conditions. Scripts depend on personal access tokens that expire, secrets that rotate, and the one engineer who wrote it and has since moved on. They fail silently. They hit API rate limits partway through a mass operation and stop, and you find out only when you need a recovery that is not there. There is no central monitoring, no alerting, and no audit trail. When you have to restore thousands of repositories after an incident, a Python script on a laptop is not a recovery plan. It is a liability with a cron entry.
The Compliance Angle Executives Care About
This exposure is also a governance problem, not just an engineering one. Regulations and frameworks including the EU's Digital Operational Resilience Act (DORA, effective January 2025), SOC 2, ISO 27001, and HIPAA all expect or require demonstrable backup, defined retention, and the ability to prove recoverability on demand. Fragmented, homegrown tooling produces none of that. No central reporting, no evidence of retention, no repeatable proof that critical intellectual property can be recovered.
Organizations leaning on native features and scripts do not just carry technical risk. They walk into audits unable to demonstrate the controls the auditors are there to check.
Rubrik Can Protect Your DevOps Platforms
Rubrik DevOps Protection starts with immutable, logically air-gapped repository backups that live outside the blast radius of your DevOps platform, so a backup cannot be altered or deleted before its retention expires, even by a compromised admin.
Rubrik’s solution includes:
- SLA-driven automation: A policy engine discovers repositories automatically, on a 24 hour cycle and on demand, and applies SLA policy at the organization level, so new repositories inherit protection with no manual step and no scripts to maintain.
- Least-privilege by design: Onboarding provisions a read-only backup identity and a separate, write-capable restore identity that is only used during recovery, with credentials scoped and encrypted per organization. Routine backup jobs cannot modify your repositories, and the blast radius of any credential compromise stays contained to a single organization. This matters because a compromised, over-privileged token or service principal is the root cause of many DevOps breaches, including the 2026 Trivy supply chain attack. Keeping the backup identity separate from the daily operational identity is a core Zero Trust principle, and it means the credential that runs your backups is never the one an attacker can turn against your repositories.
- Whole-repository recovery to a clean point: Rubrik never overwrites your live repository in place. You can restore to a new repository in the same organization, a different organization, a separate tenant, or across platforms between GitHub and Azure DevOps, which also makes Rubrik a migration and disaster recovery path. Efficient incremental backups respect platform API rate limits and resume automatically after an interruption, unlike brittle CLI scripts.
- Enterprise security controls: Granular RBAC separates backup administrators from developers. Retention Lock stops anyone, including admins, from deleting or shortening retention before it expires. Quorum Authorization requires a second approver for destructive actions like removing an organization from protection.
- Unified visibility: Your GitHub and Azure DevOps backups sit in Rubrik Security Cloud next to your other enterprise, cloud, and SaaS workloads, in one place for compliance monitoring, reporting, and audit readiness.
Your security tools look for threats. Rubrik makes sure that when something gets through, or someone fat-fingers a delete, you can get back to a state you trust. Rubrik does not decide which snapshot is clean, that is your incident response and threat hunting work. What Rubrik hands them is a set of clean, immutable restore points to choose from, so recovery is a decision, not a scramble.
Native tooling versus Rubrik
The Bottom Line
Version history is not a backup. Native platform protection is not a backup strategy. The distance between what you think you have and what you actually have is exactly where attackers, accidents, and auditors find you.
Your repositories are where your business is built. When an attacker, an accident, or an audit puts that at risk, you need a copy that lives outside the blast radius and a way to prove you can bring it back.
Learn more about Rubrik DevOps Protection for GitHub and Azure DevOps. More of a hands-on learner? Head to Rubrik Explore and take one of our self-guided, hands-on labs for GitHub and Azure DevOps. And if you are around, Rubrik will be at GitHub Universe this October - feel free to join us at our Recovery Hour!