The Repository Is The New Package
Sometimes a blog post starts with a carefully planned research project.
Sometimes it starts with a mate sending you a screenshot and saying:
“GitHub just disabled eight of my repositories.”
That was Friday.
By Saturday morning I had spent several hours enumerating Microsoft-owned GitHub organisations, correlating repository disablement timestamps, cross-referencing public reporting, speaking to researchers and incident responders, and accidentally becoming a data source for somebody else’s blog post.
As one does.
The immediate story was fascinating enough. Dozens of Microsoft-owned repositories had been disabled by GitHub. Not archived. Not made private. Disabled.
The familiar GitHub banner appeared:
This repository has been disabled. Access to this repository has been disabled by GitHub Staff due to a violation of GitHub’s terms of service.
At first glance it looked like a collection of unrelated incidents. It wasn’t. The more interesting story wasn’t Microsoft’s problem. The more interesting story was what it tells us about the future of software supply chain security.
A weird pattern
The first thing that caught my attention wasn’t the repositories. It was the timestamps. Using the GitHub API and GitHub CLI, I started pulling metadata from disabled repositories across Microsoft’s GitHub organisations. What emerged was unusual. Very unusual.
Seventy-three repositories across four organisations were disabled within a 105-second window.
That isn’t a human being clicking buttons. That isn’t even a security engineer running through a checklist. That’s an automated response. Something decided those repositories needed to disappear immediately.
The blast radius
The Azure organisation absorbed most of the impact.
The affected repositories included:
- Azure Functions Host
- Azure Functions Core Tools
- Azure WebJobs SDK
- DurableTask
- Functions Actions
- Language Workers
- OpenAI Extensions
- Agent Runtime
- MCP Extensions
- Connector SDKs
And many more.
If you’re an Azure Functions customer, that’s not a random collection of repositories. That’s effectively an ecosystem. The disablements extended beyond Azure itself.
Repositories in:
- Azure
- microsoft
- Azure-Samples
- MicrosoftDocs
were affected.
That matters. Because it suggests the response wasn’t targeting individual malicious files. It was targeting trust boundaries.
The attack surface has moved
For years we’ve trained developers and defenders to think about supply chain attacks through package managers.
- npm
- PyPI
- NuGet
- Maven
Historically the model looked something like this:
flowchart TD
A[Developer] --> B[Package Registry]
B --> C[Dependency]
C --> D[Build System]
D --> E[Production]
Compromise the package. Compromise the build. Compromise production.
Simple, understandable, something we know how to defend against (even if we are still bad at actually doing so). But that’s increasingly not how modern development works.
Today the path often looks more like this:
The repository itself has become the attack surface. Not the package. The repository.
Repositories are now execution environments
Ten years ago repositories mostly contained source code.
Today they contain:
- GitHub Actions workflows
- Azure DevOps pipelines
- Infrastructure-as-Code
- MCP configuration
- VS Code configuration
- Cursor rules
- Copilot instructions
- Agent prompts
- Deployment scripts
- Secret references
- Build automation
A modern repository isn’t just source code. It’s a development environment, an automation platform and an execution environment.
That’s a profound shift, and most organisations are still defending repositories as if they’re passive storage.
Miasma changes the conversation
Around the same time, public reporting emerged around Miasma, a worm derived from the earlier Shai-Hulud ecosystem.
The important thing isn’t the malware implementation. The important thing is what it targeted.
According to SafeDep’s excellent analysis, Miasma specifically abused AI coding agent configuration and repository-level trust relationships rather than relying solely on traditional package compromise.
The attack path wasn’t Install malicious package. The attack path was Trust malicious repository content.
That’s a very different threat model.
If attackers can influence:
- AI coding assistants
- Workspace configuration
- GitHub Actions
- MCP definitions
- Repository instructions
then the repository itself becomes the payload. Not the software it contains. The repository.
The trust boundary migration
I think that’s the real lesson here. For years we’ve invested enormous effort securing artifacts. We scan packages, containers, dependencies, binaries. Meanwhile trust has quietly migrated elsewhere. Trust now lives inside repositories.
The repository decides:
- What gets built
- How it gets built
- Who builds it
- What secrets are available
- What AI sees
- What AI does
- What gets deployed
- Where it gets deployed
If you compromise the repository, you inherit all of those trust relationships. That’s far more powerful than compromising a package.
The AI acceleration effect
AI isn’t creating this problem. It’s accelerating it. An AI coding assistant doesn’t just read source code. It consumes context, instructions, configuration, prompts, and repository metadata. Files that traditionally weren’t considered executable can now influence behaviour in meaningful ways.
That blurs a line security teams have historically relied upon.
The distinction between:m Data and Instructions is becoming increasingly fuzzy. Attackers understand this. Defenders need to catch up.
What defenders should be watching
Many organisations still focus almost exclusively on dependency security. That’s necessary but it’s no longer sufficient.
Defenders should increasingly treat repositories as high-value assets and monitor for:
- New GitHub Actions workflows
- Changes beneath .github/
- Changes to MCP configuration
- New bootstrap scripts
- New install hooks
- Changes to IDE configuration
- Changes to AI instruction files
- Unexpected repository ownership changes
- Unusual workflow executions
- Secret access pattern changes
The challenge is that many of these things were historically considered administrative changes rather than security events. That assumption no longer holds.
The broader lesson
At the time of writing, many details surrounding the Azure Functions and DurableTask incident remain unclear. Public reporting continues to evolve. Incident responders are still doing incident responder things. Researchers are still researching.
People on social media are still confidently presenting theories as facts. Normal weekend activity 😉
What matters isn’t whether one particular theory proves correct. What matters is the pattern. The attack surface is moving, the trust boundary is moving, and many organisations haven’t moved with it. Supply chain security isn’t disappearing. It’s evolving. The package still matters. But increasingly the repository matters more.
The next generation of supply chain attacks won’t just target what you install.
They’ll target what you trust.
And today, we trust repositories with almost everything.
Sometimes the most valuable thing a security researcher can do is notice something odd.
The technical term for this is “weaponised curiosity.” 😈
References
- SafeDep — Miasma Worm: AI Coding Agent Configuration Injection https://safedep.io/miasma-worm-ai-coding-agent-config-injection/
- OpenSourceMalware — The Blight Reaches Microsoft: 73 Repos Disabled in 105 Seconds https://opensourcemalware.com/blog/miasma-reaches-azure/
- GitHub Security Lab, OpenSSF, and various public analyses on repository-centric software supply chain attacks and workflow compromise.