On January 4, 2023, an engineer at CircleCI opened a file on a company laptop that had already been quietly compromised by information-stealing malware. The malware didn't need a password — it lifted an active session token directly out of the browser, a token that had already cleared two-factor authentication. Attackers walked in as that engineer, no login screen required, and CircleCI spent the next several weeks urging every customer to rotate every secret the platform had ever stored. This is the quiet failure mode of modern authentication: session persistence, the mechanisms that let a login stay valid across requests, hours, or weeks without asking for a password again. Built for convenience, these long-lived cookies, refresh tokens, and CI/CD credentials have become one of the most reliable ways for attackers to move through a software supply chain undetected. Understanding how session persistence turns from a UX feature into a breach vector is essential for any team that ships code.
What Is Session Persistence, and Why Does It Become a Security Risk?
Session persistence is the set of mechanisms — browser cookies, JWTs, OAuth refresh tokens, personal access tokens, CI/CD runner credentials — that keep a user or a machine authenticated without re-entering credentials, and it becomes a risk the moment a token outlives the trust decision that created it. A password login might require MFA, device checks, and a risk score. The session token issued after that login usually requires none of that on every subsequent request — it is the proof of authentication, and whoever holds it inherits the access, MFA and all.
This gap is structural, not accidental. GitHub's classic personal access tokens had no expiration at all until the platform added optional expiry in 2021 and fine-grained, auto-expiring tokens in 2022. npm access tokens went without built-in expiration until a 2023 overhaul introduced granular, time-limited tokens. Countless SaaS integrations, deploy keys, and service accounts across the software supply chain were designed the same way: authenticate once, stay trusted indefinitely. That design choice is exactly what attackers exploit.
How Do Attackers Actually Steal and Reuse Session Tokens?
Attackers steal sessions mainly through three channels — commodity infostealer malware, adversary-in-the-middle phishing kits, and stale tokens left behind in code, logs, or support tickets — and all three skip the login screen entirely. Infostealers like RedLine, Raccoon, and Lumma are built specifically to harvest browser cookie jars, extracting live session cookies for GitHub, npm, Slack, and cloud consoles from an infected developer laptop in seconds. That's precisely what happened at CircleCI: malware on a single engineer's machine exfiltrated a session token that bypassed 2FA because the second factor had already been satisfied when the cookie was minted.
Phishing has evolved the same way. Modern adversary-in-the-middle kits (Evilginx and its successors) proxy a real login page, capture the resulting session cookie the instant a victim authenticates, and hand the attacker a working session — MFA completed, credentials never even needed. And sometimes there's no theft required at all: in September 2022, Toyota disclosed that an access key had been sitting exposed in a public GitHub repository since 2017. It took roughly five years and the exposure of data tied to about 296,000 customers before anyone noticed.
Which Recent Breaches Were Actually Session Persistence Failures?
At least four major incidents between 2021 and 2023 trace back to a session or access token that outlived the trust it represented, not a cracked password. In April 2022, GitHub disclosed that an attacker used stolen OAuth user tokens originally issued to Heroku and Travis CI — third-party CI integrations — to download private repository contents from dozens of organizations, including npm's own codebase. The tokens had been active, unrevoked, and unmonitored long after the integrations had any operational reason to hold them.
In July 2023, Sourcegraph found that a site-admin access token had been exposed in a public commit; because the token itself carried no short expiry, it remained usable well after exposure and was used to create and resell unauthorized accounts. And the chain that hit Cloudflare on Thanksgiving weekend 2023 started with Okta's October 2023 support-system breach, where an attacker accessed HAR files containing live session tokens uploaded during support cases. Cloudflare had one of those tokens among its own systems and hadn't rotated it — the resulting intrusion into its Atlassian environment was traced directly back to that single persistent session credential.
Why Do CI/CD Pipelines Multiply Session Persistence Risk?
CI/CD systems multiply the risk because they run on persistent, machine-to-machine sessions — deploy keys, service-account tokens, cached environment variables — that are individually low-visibility but collectively hold the keys to build, sign, and ship every release. A developer's stolen session might expose one account; a compromised CI runner session can expose every artifact that pipeline ever touches.
The Codecov incident is the clearest illustration. Around January 31, 2021, an attacker used a leaked credential in a misconfigured Docker image to modify Codecov's Bash Uploader script. For roughly two months, undetected, that modified script quietly exfiltrated environment variables — which routinely include session tokens, API keys, and cloud credentials — from every CI pipeline that ran it, reportedly affecting thousands of customer environments before discovery on April 1, 2021. One persistent, unmonitored credential turned a build tool into a supply-chain-wide credential-harvesting operation.
How Long Do Stolen Sessions Typically Stay Valid Before Anyone Notices?
Longer than most teams assume: industry dwell-time research (Mandiant's annual M-Trends reports) has consistently put median attacker dwell time somewhere between roughly 10 and 16 days over the past several years, and that's just the median — plenty of sessions and tokens go unnoticed far longer. Some never expire at all unless someone manually revokes them, which is exactly why Toyota's exposed key sat live for years and why Sourcegraph's leaked token remained dangerous long after the initial exposure.
Verizon's Data Breach Investigations Report has listed the use of stolen credentials among the top attack vectors for over a decade running, and session/token theft increasingly sits alongside password theft in that category precisely because a stolen session skips credential checks altogether. Every extra day a token stays valid after exposure is a day an attacker can operate with zero authentication friction.
What Can Engineering Teams Do Today to Shrink the Session Persistence Attack Surface?
The fix is fundamentally about shortening the lifespan of trust: short-lived tokens, scoped permissions, and continuous visibility into what sessions actually exist. In practice that means issuing access and refresh tokens with the shortest TTL the workflow can tolerate, replacing static CI/CD credentials with short-lived OIDC-issued tokens (GitHub Actions' OIDC integration with cloud providers is a good template — no long-lived cloud keys stored anywhere), and binding sensitive sessions to device or network context so a stolen cookie doesn't work from a different machine.
It also means treating every token as an inventory item, not a one-time setup step: teams should be able to answer, at any moment, which tokens exist, what they can touch, when they were last used, and when they expire. Sessions should be force-revoked on password reset, MFA re-enrollment, or role change — not left to expire on their own schedule. And package registries, CI providers, and SaaS integrations should be audited specifically for tokens with no expiration, the exact pattern behind the GitHub OAuth, Sourcegraph, and Codecov incidents.
How Safeguard Helps
Safeguard approaches session persistence as a software supply chain problem, not just an identity problem, because the incidents above show the two are inseparable. Safeguard continuously discovers and inventories the tokens, service-account sessions, and CI/CD credentials that touch your build and release pipeline — including the third-party integrations and registry tokens that traditional identity tools rarely see. Rather than waiting for an annual access review, Safeguard flags tokens with no expiration, credentials that have gone stale but remain active, and sessions with permissions broader than their actual usage pattern.
When a session is reused in an anomalous way — a new IP, an unusual build environment, a token suddenly active after months of dormancy — Safeguard surfaces it against the specific pipelines, artifacts, and packages that credential could reach, so a security team isn't just told "a token was misused," but exactly which builds, signatures, and downstream consumers might be affected. Combined with provenance and SBOM tracking, that means a compromised session can be traced to its blast radius in minutes rather than the weeks it took CircleCI, Sourcegraph, and Codecov to fully scope their incidents. Reducing session persistence risk isn't about eliminating sessions — it's about making sure none of them can quietly outlive the trust they were built on.