Early 2026 has a familiar rhythm: another supply-chain campaign, another "rotate everything" scramble, another postmortem that reads like a checklist of good hygiene… followed by the quiet realization that the real failure mode wasn’t hygiene at all.

It was physics.

Bearer credentials (PATs, deploy tokens, CI secrets, SSH keys) are still treated as portable trust. If you have the string (or the key), you are the identity—until someone notices and revokes it.

GitHub’s own documentation says the quiet part out loud:

“After you authorize a personal access token or SSH key, the token or key will stay authorized until revoked.”
— GitHub Docs: Authorizing a personal access token for use with SSO

That one sentence explains why attackers don’t “hack GitHub.” They don’t need to. They steal what GitHub already trusts.

And the last ~24 months have produced enough real-world examples to stop treating this as theoretical.

The incidents are different. The credential story is the same.

The New York Times (January 2024): one stolen token, thousands of repos

According to the Cloud Security Alliance’s breakdown, attackers used a stolen GitHub token to access 5,000+ repositories and exfiltrate ~270GB of data (including source code and internal tooling).

No MFA prompt. No “new device” friction. No device posture check. Just: token works → repos open.

Mercedes‑Benz (discovered January 2024): a leaked token became a master key

TechCrunch reported that a Mercedes token exposed online gave “unrestricted” access to internal source code hosted on GitHub Enterprise Server.

Even worse (and this is the part most teams underestimate): source code access is rarely the end. Once you’re inside the repos, you often find more credentials.

Home Depot (revoked December 2025): a publicly exposed GitHub token sat for ~a year

TechCrunch (via security researcher Ben Zimmermann) described a leaked GitHub access token that enabled access to hundreds of private repositories and potentially sensitive internal systems until it was revoked in December 2025.

This is the operational reality of token security:

exposure happens quietly,
discovery happens late,
and the token remains valid the entire time.

Shai‑Hulud 2.0 (December 2025): malware harvested secrets and pushed them to attacker‑controlled repos

Microsoft’s Defender research team described Shai‑Hulud 2.0 as a supply-chain campaign that maliciously modified packages to harvest credentials and configuration secrets, exfiltrating them to attacker-controlled GitHub repos and accelerating propagation through developer and CI environments.

If your “control” starts and ends at the login page, this is where you lose.

GitHub and GitLab have improved token management — but they can’t change what bearer credentials are

It’s important to acknowledge the platform progress (because it’s real):

GitHub (Enterprise Cloud)

Org owners can enforce maximum lifetimes for PATs.
- For fine-grained PATs, the default maximum lifetime policy is set to expire within 366 days.
- Classic PATs historically had no expiration requirement unless you enforce it.
  — GitHub Docs: Setting a personal access token policy for your organization
GitHub Apps provide short-lived tokens in multiple modes:
- Installation access tokens expire after 1 hour.
  — GitHub Docs: Authenticating as a GitHub App installation
- User access tokens created by GitHub Apps expire after 8 hours by default (and GitHub warns against configuring them to never expire).
  — GitHub Docs: Token expiration and revocation
GitHub Actions supports OIDC so workflows can exchange short-lived tokens directly with cloud providers (reducing stored long-lived cloud secrets).
— GitHub Docs: OpenID Connect (OIDC)
GitHub supports IP allow lists at the org/enterprise layer.
— GitHub Docs: Managing allowed IP addresses for your organization
— GitHub Docs: Restricting network traffic to your enterprise with an IP allow list

All of this helps.

But none of it changes the core mechanic behind the worst Git credential incidents:

A valid token/SSH key is still a skeleton key that works “from anywhere” unless you add a control that enforces where/how Git is reachable.

GitLab

GitLab documents PAT lifetime behavior and limits, including 365-day constraints in many contexts and admin-configurable lifetime limits.
— GitLab Docs: Personal access tokens
— GitLab blog: Why GitLab access tokens now have lifetime limits
GitLab 18.8 introduced a Credentials Inventory API to centralize visibility across multiple credential types.
— GitLab 18.8 release notes (Jan 15, 2026)
And the platform remains software: GitLab shipped patches in January 2026 for a 2FA bypass vulnerability (CVE‑2026‑0723).
— GitLab patch release (Jan 21, 2026)
— NVD: CVE‑2026‑0723

Again: this helps. But it doesn’t eliminate the “credential works from anywhere” failure mode.

Aembit’s framing is sharp — and they’re right about the root cause

If you want to see a vendor define the problem efficiently, Aembit does it well (example: Just‑in‑Time Access for Workloads: Eliminating Standing Privileges).

They consistently hammer on a few ideas that are absolutely correct:

Standing privilege is the enemy (long-lived credentials embedded in scripts/pipelines).
Token abuse thrives when tokens are untethered from runtime context—usable “from any environment, device, or service” with weak audience/scope/behavior checks.
The modern enterprise is drowning in non-human identities and the credentials that power them, and the only scalable answer is policy + automation + ephemeral access.

Their solution set is coherent:

Issue just-in-time / short-lived credentials to workloads instead of distributing static secrets.
Enforce conditional access policies and produce identity-centric auditability for workload access.
For GitHub specifically, they promote moving from PATs to GitHub Apps for automation (because PATs can’t realistically be “minutes-lived” in practice). For example: Replacing a GitHub Personal Access Token with a GitHub Application.
For GitLab, they emphasize automatic rotation and lifecycle management (especially for service accounts).

If your problem is workloads talking to APIs and you want to remove static secrets from CI/CD, Aembit is playing the right game.

But Git credential risk doesn’t end where workload IAM begins.

Where Aembit (and most “token management”) is fundamentally incomplete: Git is a protocol, not a login

The credential failure modes that matter most are exactly the ones token-management alone can’t guarantee against:

1) Stolen token used from a totally different machine

This is the New York Times / Home Depot / “token in a public repo” pattern.

Even if you rotate faster, or scope better, you’re still left with one brutal fact:

If GitHub accepts a token from anywhere until revoked, the attacker’s laptop looks identical to the developer’s laptop.

2) Stolen token used to create persistence (another credential)

In real intrusions, attackers don’t stop at “clone the repo.” They go for durable access:

add a new key,
add a new integration,
tamper with CI,
create or modify secrets,
or establish a new trusted execution path.

Whether that persistence is another token, an SSH key, a deploy key, or a poisoned workflow—the move is the same: use a valid credential to mint more trust.

Token rotation helps after you detect. It does not stop the first “bootstrap” step.

3) “Zombie” credentials created by (or bound to) an ex-employee

This one is less sensational but more common:

a PAT created for a one-off script,
a deploy token in an old pipeline,
an SSH key on a contractor laptop,
a service account nobody “owns” anymore.

Lifecycle automation helps for workloads. But for Git access across humans + tools + SSH, the bigger question is:

When someone leaves (or a laptop is lost), can you make every credential they ever touched useless immediately—even if you don’t know where it’s stored?

That’s not a token-management question.
That’s an enforcement-layer question.

This is why EDAMAME exists: not to “manage tokens,” but to make stolen credentials irrelevant

Our two posts (Building Real Security for GitHub Enterprise and Dear Security Posture, We Need to Talk) were written from the same premise:

When everything was on-prem and effectively air-gapped, we had something we barely appreciated: certainty. Cloud Git platforms traded that certainty for speed and collaboration—which is great—but the missing ingredient is context.

So the EDAMAME design goal is different from token management:

Don’t try to make every token perfect.
Make every credential insufficient by itself.

The EDAMAME safety net: the part token management doesn’t give you

EDAMAME adds a Zero Trust enforcement layer after the credential exists:

Continuously verify identity + device posture (OS, encryption, EDR presence, patch levels, firewall, etc.).
Dynamically update GitHub/GitLab’s native IP allow lists so only compliant, verified endpoints can even reach the Git host.
No proxy, no tunnel: just orchestrating the controls the platforms already enforce.

That creates what we called a “virtual air gap”: you keep GitHub/GitLab, but you regain “reachable only from trusted endpoints” certainty.

The key positioning point

This works across all SDLC credentials used for Git operations.

Because the enforcement happens before GitHub/GitLab even evaluates the credential, the mechanism doesn’t care whether the request is authenticated by:

a fine-grained PAT,
a classic PAT,
a deploy token,
a CI job token,
a GitHub App token,
or an SSH key.

If it’s coming from an endpoint that isn’t currently trusted, Git is dead on arrival.

That is the safety net.

Re-running the real incidents through a “Zero Trust for Git” lens

If Shai‑Hulud steals your developer’s PAT…

Microsoft describes credential harvesting and exfiltration to attacker-controlled repos as a core part of the campaign.

Without EDAMAME: attacker moves the token to a VPS and starts cloning/pulling.
With EDAMAME: that VPS cannot reach your Git host because it isn’t on the allow list. The token is valid, but valid doesn’t matter anymore.

If a leaked token sits in public for months…

Home Depot is the modern poster child: leaked token, broad repo access, long exposure window.

Token management helps once you find it.

EDAMAME helps even while you don’t know it’s leaked, because the token can’t be used from outside your trusted endpoint set.

If an attacker tries to turn a stolen token into persistence…

The “token → new key/token” move requires making authenticated API calls or Git operations from somewhere.

EDAMAME’s model forces the attacker into a much harder box:

They must operate from a currently trusted endpoint.
If that endpoint’s posture degrades, it falls off automatically.
Offboarding becomes “remove device access” rather than “find every credential ever created.”

Workload IAM reduces the attack surface but Zero Trust keeps you safe

Ephemeral credentials and workload IAM are the right way to reduce standing privilege in CI/CD and service-to-service access. They also correctly call out that token abuse thrives when tokens are usable without runtime context.

But even perfect workload IAM doesn’t fully close Git risk, because:

Git access is a mix of humans + tooling + SSH + HTTPS.
Credentials still exist (even ephemeral ones), and exfiltration still happens (Shai‑Hulud is literally built around that).
The gap is not “how tokens are minted.” It’s “what systems will accept them, from where.”

The reality is:

Workload IAM reduces the number of long-lived secrets and improves lifecycle management for non-human identities.
EDAMAME’s Zero Trust for Git is the safety net that prevents any SDLC credential from being used outside trusted, compliant endpoints—especially for Git.

Let’s stop pretending token management can be the last line of defense.

The 2026 takeaway

Stop asking “Is the token valid?” and start enforcing “Is this request allowed to reach Git?”

GitHub and GitLab will keep improving:

tighter token policies,
more inventories and governance,
more ephemeral options (Apps, OIDC),
more telemetry.

And they should.

But the breach pattern we keep living through happens because bearer credentials are, by design, valid without context until revoked.

EDAMAME’s Zero Trust for Git is the missing layer that changes the attacker math:

Stolen credentials don’t become instant remote access.
Ex-employee credentials don’t become latent backdoors.
SSH keys stop being “forever keys,” because “where” becomes mandatory.
SDLC credentials are no longer a single point of failure—because they’re no longer sufficient by themselves.

That’s what a real safety net looks like in 2026.