GitHub Enterprise has changed the way engineering teams collaborate.
It’s fast, distributed, and deeply integrated into how we build and ship software today.
But as more organizations migrate to the cloud, we’re quietly losing something that used to come for free in an on-prem, air-gapped world — the certainty that our code and secrets are completely shielded from the outside.

When everything lived in a local Git server or a data center we controlled, the security perimeter was clear.
We knew exactly which machines could talk to the source, and we could walk down the hall to unplug one if needed.
Now, our most valuable intellectual property — the source code — lives in a shared, always-connected platform.
That’s not inherently unsafe, but it demands a different kind of discipline.

The New Reality: Great Collaboration, Vanishing Certainty

GitHub is an incredible platform, but with it comes a shared-responsibility model:
GitHub secures the service; we’re responsible for everything that connects to it — people, devices, and tokens.

And it’s the tokens that keep me up at night.

We’ve all seen the headlines.
In 2024, a single stolen GitHub token gave attackers access to over 5,000 private repositories from The New York Times (Cloud Security Alliance).
The Shai-Hulud supply-chain worm spread through npm packages, exfiltrating tokens and secrets from developer machines (Unit42 Research).
And when Toptal’s GitHub account was compromised, attackers used that access to push malicious code and wipe developer machines (The Hacker News).

The pattern is consistent: attackers don’t need to break into GitHub.
They steal something that’s already trusted — a Personal Access Token, an SSH key, a CI credential — and use it from anywhere.
Most identity systems can’t tell the difference between a legitimate user and an impersonator using a stolen credential.

That’s the modern supply chain threat in one sentence.

Why Air-Gapped Systems Still Teach Us Something

Before the cloud, security-conscious organizations solved this by air-gapping critical systems.
If your Git or CI/CD servers weren’t reachable from the internet, stolen credentials were basically useless.
The trade-off, of course, was agility. Remote work, contractor access, or automated builds became complicated.

But air-gapping taught us an enduring lesson:
it’s not just about who is authorized — it’s about where and how access happens.

When we moved to GitHub Enterprise Cloud, most teams kept the identity discipline (SSO, MFA, Okta, Entra, etc.), but we lost the context.
We stopped asking:

“Is this device trusted?”
“Is it compliant with our security baseline?”
“Should this token even be valid from here?”

Those questions define the new perimeter.

Thinking in Zero Trust Terms

Zero Trust isn’t a marketing slogan — it’s a mindset shift.
It means treating every request, every device, every credential as potentially compromised until proven otherwise.
Applied to software development, it means no device, token, or user gets access to source code unless it passes both identity and posture verification.

This is where we’ve focused our work at EDAMAME: building a system that continuously answers those two questions for GitHub and CI/CD environments, without breaking developer workflows.

Our approach is simple in principle:

We verify that the person trying to access code really is who they say they are.
We verify that the machine they’re using is secure and compliant.
And we let GitHub and the other platforms enforce that decision natively — through their existing device and IP allowlists.

No proxies. No magic network tunnels. Just smart orchestration of the controls that already exist.

How We Do It in Practice

1. Binding Identity to a Real User

When a developer joins a project, EDAMAME ties their access to their corporate identity using a one-time PIN sent to their email account.
That PIN step isn’t cosmetic — it’s the difference between an attacker reusing a stolen token and an actual user logging in from a verified account.
Unless the attacker also compromises the user’s email (which is already heavily protected by MFA and corporate policies), the device never gets on the access list.

2. Checking Device Posture Continuously

Every developer laptop, CI runner, and even mobile device that touches GitHub or a CI/CD system reports its posture:
OS version, encryption status, EDR presence, firewall, patch levels, and other signals.
If a machine falls out of policy — say, antivirus is turned off or a kernel patch is missing — EDAMAME automatically removes it from the device whitelist.
Access stops until it’s fixed.

GitHub Enterprise, Azure Entra, or your ZTNA solution enforces that in real time.
The result: only compliant devices belonging to verified users can talk to your repos.

3. Extending to All Environments

Developers work across every platform imaginable:
Windows, macOS, Linux, mobile (iOS/Android), and containerized CI/CD runners on both x86 and ARM.
The same principles apply everywhere.

When someone uses the GitHub mobile app, EDAMAME checks that their phone meets corporate posture standards before adding it to the whitelist.
For CI/CD, our CLI and GitHub Action integration run inside the pipeline, verifying the build runner’s integrity before it can fetch code or secrets.
That way, the CI environment becomes part of the same Zero Trust boundary as developer laptops.

A Real-World Scenario

Consider again the Shai-Hulud scenario.
An attacker steals a developer’s GitHub token from an infected laptop.
They try to use it from their own machine.

They fail immediately.

Why? Because that token isn’t enough.
To access the repository, they’d also need to:

Use a device on the EDAMAME-managed whitelist, and
Authenticate through the developer’s corporate email to receive a one-time PIN.

Without both, GitHub’s native controls — updated dynamically by EDAMAME — simply block the request.
Even if they somehow cloned the developer’s environment, the lack of verified email authentication and mismatched device posture would revoke access instantly.

That’s what we mean when we say “virtual air gap.”
It’s not about isolation; it’s about continuous verification.

Developer Experience Matters

Security that interrupts work doesn’t last.
We learned early that developers will find a way around friction.
That’s why EDAMAME operates in reporting mode — it checks posture and guides developers to fix issues but doesn’t take over their devices.

We’ve found that this approach actually raises awareness.
When developers see a message like “Your local firewall n is off — click here to fix,” they respond immediately.
It’s security as collaboration, not enforcement.

Working Alongside Other Solutions

We don’t believe in silver bullets.
Zero Trust is a system of systems.
Our work complements tools like:

Aembit (aembit.io) for machine-to-machine identity,
Secrets managers like GitGuardian and Doppler, and
ZTNA and Conditional Access platforms like Azure Entra or Google Context-Aware Access.

We integrate with them, feed them device posture data, and let them do what they already do best.
Together, they create an ecosystem where both human and machine identities are continuously verified.

Why Compliance Follows Naturally

When you implement Zero Trust at this depth, compliance stops being an afterthought.
Continuous device verification and identity binding directly support SOC 2, ISO 27001, PCI-DSS, HIPAA, and NIS2 requirements for logical access and secure development.

Audit conversations become much simpler when you can show live evidence:
“Here’s the list of compliant devices currently allowed to access our codebase.”
No more screenshots or manual reviews — the system itself is the proof.

What We’ve Learned

Over the past few years, we’ve seen that security in modern software development isn’t about choosing between agility and control.
It’s about designing systems that adapt at the same speed as your engineers.

Air-gapped systems gave us confidence through isolation.
Zero Trust gives us confidence through verification.
That’s the mindset shift we need if we’re going to keep building in the open — safely.

Learn more about the Zero Trust model we’re applying to source code and CI/CD environments at https://www.edamame.tech and https://github.com/edamametechnologies.
Or check out our GitHub guide for access control integration: github.com/edamametechnologies/integrations/wiki/Setting-Up-GitHub-for-Access-Control-Integration.

Frank Lyonnet

Share this post