A developer's hands typing on a laptop with a code editor in a dim office at night; above the laptop a glowing golden vault door stands open on an empty vault, and a few golden fragments drift out and fade.

Article20 May 20263 min read

Assume compromise: what the GitHub breach teaches anyone who builds software

A poisoned editor extension cost GitHub thousands of internal repositories. How we design our own work so that a breach yields nothing of value.

In May 2026 GitHub disclosed that an attacker had copied around 3,800 of its internal repositories. The way in was not a sophisticated exploit against GitHub’s platform. It was a single employee laptop, and on it a tampered version of a popular extension for the Visual Studio Code editor. The poisoned version was available in the marketplace for only minutes before it was pulled, and that was enough. GitHub found no evidence that customer repositories were affected.

The lesson is one many teams would rather not hear: if you build software, you will be part of a breach at some point. Not because you are careless, but because modern engineering runs on layers of tools, extensions and dependencies that nobody fully controls.

Assume compromise, minimise impact

Prevention still matters, and we invest in it. But a design that only works as long as nothing gets in is a design that fails on the worst day. We start from the opposite assumption: someone will get in, so make sure they leave with nothing of strategic value. In practice that comes down to four habits.

Core logic behind interfaces. Proprietary rules and algorithms do not sit in a repository as readable source. They live behind services, interfaces or private modules, so a copied repository shows how things connect, not how they work.
Nothing sensitive in code. No secrets, no internal endpoints, no configuration that maps out the infrastructure. Secrets live in a vault and are fetched at run time by an identity, never pasted into a file.
Deliberate abstraction. Code is written to be clear for the people who work on it and to reveal as little as possible to anyone who should not be reading it.
Public by default. Every repository is written as if it could be exposed tomorrow. If a file would be a problem on the front page of a news site, it does not belong in the repository.

The workstation is the perimeter

The GitHub case also shows where the real perimeter sits today: on the developer’s machine. The editor, its extensions and the command-line tools on that machine all run with the developer’s access. That calls for the same discipline as any other part of the estate: a short list of approved extensions, devices managed and kept current, sign-ins bound to a managed device, and access that is scoped to the task rather than to everything a developer might one day need.

Resilience, not paranoia

Security is not only about keeping attackers out. It is about making sure that when something happens, the damage is small, contained and quickly reversed. The GitHub breach will not be the last headline of its kind. How much it costs you is decided one design choice at a time, long before the incident.

We run our own repositories this way, and we help teams adopt the same habits: secrets in a vault, managed developer devices, a short list of approved editor extensions and a review on every change.

See what we offer in cybersecurity and compliance and team enablement.