One outage, and half the industry stopped shipping
GitHub went down twice in the same month this August. The second incident degraded core functionality for the better part of six hours. For a stretch of a normal working day, a large slice of the world's engineering teams could not open a pull request, trigger a build, pull a container image, or push a release. Code sat finished on laptops with nowhere to go.
The timing became a story of its own because Cursor chose that same morning to launch Origin, its own code-hosting product with review agents built in, aimed squarely at the platform that has held the industry's source code for two decades. The competitive drama is interesting. The operational lesson underneath it is the one worth your attention: most organisations have quietly concentrated their entire software delivery capability into a single third-party platform, and very few have measured what happens when that platform is unavailable.
We run into this in nearly every infrastructure and DevSecOps engagement. Teams have mature failover plans for their production databases and none at all for the system that builds and ships the code running those databases. Below is how we think about that gap, why agent-native platforms make it sharper, and the practical steps we use to close it.
Git is distributed. The platform around it is not.
Git itself was designed by Linus Torvalds in 2005 to survive exactly this scenario. Every clone is a full copy of the repository history. If GitHub, GitLab, or Bitbucket disappeared tomorrow, the commits already on your developers' machines and your CI runners would still be intact. That distributed core is real protection, and it is the reason a code-host outage is an inconvenience rather than a catastrophe.
The catch is that almost nothing your team depends on day to day lives in the distributed part. Pull requests, code review, branch protection rules, and merge queues are platform features. Continuous integration through GitHub Actions or GitLab CI runs on the platform. Your package and container registries, your release artifacts, your issue tracker, your single sign-on integration, and increasingly your secrets and deployment credentials all sit inside that one vendor. When the platform is down, git keeps working and everything built on top of it stops.
So the honest way to describe the risk is precise: your version history is resilient, but your delivery pipeline, your review process, and your build and release machinery are a single point of failure. That distinction matters because it tells you exactly what to protect. You are not trying to back up git. You are trying to keep shipping when the layer above git is gone.
What an outage actually costs
The direct cost of a few hours of downtime is easy to wave away until you count what is attached to it. A frozen pipeline means no security patches ship, no hotfixes reach production, and no incident response that requires a code change can complete. If you are mid-deployment when the platform fails, you can land in a half-released state with no clean way to roll forward or back. For regulated clients in banking and telecom, an inability to deploy an urgent fix inside an agreed window is not just lost productivity. It can be a reportable control failure.
There is a second-order cost that rarely makes it into the incident review. When developers cannot push or review through the normal path, they improvise. People email patches, commit straight to shared branches, disable checks "just to get it out," and share credentials to work around broken automation. Every one of those shortcuts is a security regression, and they tend to outlive the outage that caused them. We have walked into environments months later and found branch protection still switched off from an incident nobody documented.
Agent-native repositories raise the stakes
The Cursor Origin launch points at where this is heading. The new generation of code platforms pairs every repository with an autonomous agent that can browse the codebase, make edits, and open pull requests on its own. That is a genuine productivity shift, and it is also a new and poorly understood attack surface.
Think through what an agent with repository write access actually holds. It can read every secret and configuration file in the repo. It can author commits that a tired reviewer may approve on a Friday afternoon. It can be steered by a prompt injected into an issue, a comment, or a dependency's README, which turns "summarise this ticket and open a fix" into an instruction path an attacker can influence. The 2024 XZ Utils backdoor showed how patient a supply-chain attacker will be to get malicious code merged through legitimate channels by a trusted contributor. An agent that merges code is a trusted contributor that never sleeps and does not apply judgment the way a human does.
None of this is an argument against using coding agents. We use them, and our clients are adopting them fast. It is an argument for treating an agent's repository access with the same rigour you would apply to any privileged service account: least privilege, scoped tokens, mandatory human approval on merges to protected branches, and full audit logging of every action the agent takes. The moment an agent can push to main, it belongs in your identity and access model, not in a footnote.
The wider software supply chain picture
Platform concentration is one facet of a broader problem that has grown sharply. Malicious packages planted in open-source repositories grew roughly thirteen-fold between 2020 and 2023, with ReversingLabs logging more than 700,000 malicious packages since 2019. Verizon's 2025 Data Breach Investigations Report found that third-party involvement in breaches doubled year over year to around 30% of all cases. Cybersecurity Ventures put the global annual cost of software supply chain attacks at roughly 60 billion dollars for 2025. The SolarWinds compromise in 2020 and the XZ Utils backdoor in 2024 are the headline cases, but the volume that never makes the news is the real signal.
The frameworks to manage this are mature and worth naming, because they give you a concrete target rather than a vague intention to "do better." NIST's Secure Software Development Framework, published as SP 800-218, sets out the practices for building software securely across its lifecycle. SLSA (Supply-chain Levels for Software Artifacts) defines graded levels of build integrity, from basic provenance up to hermetic, reproducible builds with signed attestations. A software bill of materials, or SBOM, gives you the inventory you need to answer "are we affected?" within minutes of the next widely used package being compromised, instead of spending two days finding out. Map these against ISO 27001 and NIST CSF and you have a defensible programme rather than a pile of tools.
Where the concentration risk sits, and what reduces it
It helps to separate the platform into the capabilities you actually rely on and treat each one on its merits. Not every function needs a hot standby. Some need a documented manual fallback, and some simply need a recent backup you have tested.
Platform capabilityWhat breaks in an outagePractical mitigation
Source history (git)
Little — clones are full copies
Confirm every active repo is cloned to CI and a second host; schedule mirror pushes
CI/CD (Actions, GitLab CI)
Builds and deployments halt
Keep a self-hosted runner path or a second CI provider that can run the same pipeline definition
Package and container registry
Deploys fail to pull dependencies
Run a pull-through cache or internal registry mirror for critical artifacts
Code review and merge
Review and merge queue frozen
Document an emergency-change procedure with named approvers and after-the-fact audit
Identity / SSO
Team locked out entirely
Break-glass accounts, tested and stored offline; MFA recovery path that does not depend on the platform
Secrets and deploy credentials
Automation cannot authenticate
Keep secrets in a dedicated vault you control, not only in the code platform
A resilience and security checklist you can act on this quarter
You do not need to re-platform to reduce this exposure. Most of the value comes from a handful of deliberate steps that a competent team can put in place in a few weeks.
- Mirror every business-critical repository to a second git host on a schedule, and actually test a restore from the mirror. A backup you have never restored is a hope, not a control.
- Make sure your CI runners and deployment tooling can operate against that mirror, so a code-host outage does not also mean a deployment outage.
- Move secrets and deployment credentials out of the code platform and into a dedicated secrets manager with rotation and access logging.
- Write an emergency-change runbook: who can approve a merge when the normal review path is down, how it gets logged, and how branch protection is restored afterward. Rehearse it.
- Create and test break-glass identity accounts so an SSO or platform outage cannot lock your whole team out of their own code.
- Treat every AI coding agent as a privileged identity. Scope its tokens, require human approval on protected branches, and log its actions to the same place you send the rest of your audit trail.
- Generate an SBOM for each production service and keep it current, so your first question after the next big package compromise is answered in minutes.
- Align the whole effort to a recognised framework — NIST SSDF, SLSA, ISO 27001, CIS Benchmarks — so it survives an audit and a change of staff.
Run this as a short project with an owner and a deadline, not as a backlog item that slips every sprint. The outage that justifies the work always arrives on a day you did not choose.
How Aydahwa Enterprise can help
We are an IT infrastructure and cybersecurity consultancy, and this is core to what we do. Our team has spent 25+ years building and hardening delivery pipelines for banking, telecom, and critical national infrastructure clients, backed by ISO 27001, PCI-DSS, SOC 2, NIST CSF and CIS Benchmark experience and Microsoft Cybersecurity Architect Expert certification. We map your real exposure rather than selling you another dashboard.
A typical engagement starts with a review of your source-control and CI/CD architecture against the risks above, moves into a prioritised remediation plan you can resource, and ends with the runbooks and controls in place and tested. If AI coding agents are already in your environment, we fold their access into the same identity and audit model as everything else.
If you want to see where you stand before committing to anything, start with our free cybersecurity self-assessment or work through the cybersecurity readiness checklist. For the delivery-pipeline and platform work specifically, our cloud services and cybersecurity practices cover the resilience and supply-chain side, and our IT support team keeps it running afterward. When you are ready to talk specifics, get in touch and we will scope it against your environment.
