May 21, 2026
Posted by Refael Angel
A public GitHub repo named “Private-CISA” sat unmonitored from November 2025 to May 2026, exposing AWS GovCloud admin keys and plaintext credentials for the agency’s DevSecOps environment. The real story isn’t the contractor. It’s the architecture that let static secrets exist in the first place.
On May 18, 2026, Brian Krebs reported that a contractor for the Cybersecurity & Infrastructure Security Agency (CISA) maintained a public GitHub repository that exposed credentials to several highly privileged AWS GovCloud accounts and a large number of internal CISA systems. The repository was discovered by Guillaume Valadon, a researcher with the security firm GitGuardian, whose company continuously scans public repositories for exposed secrets.
What Happened?
The file inventory reads like a worst-case-scenario tabletop exercise:
- A file titled “importantAWStokens” containing administrative credentials to three Amazon AWS GovCloud servers
- An “AWS-Workspace-Firefox-Passwords.csv” listing plaintext usernames and passwords for dozens of internal CISA systems
- A kube-config.txt granting cluster access
- Plaintext credentials to CISA’s internal Artifactory, described by security consultant Philippe Caturegli as “a prime place to move laterally. Backdoor in some software packages, and every time they build something new they deploy your backdoor left and right”
The repository had existed since November 2025, which means six months of continuous exposure. The exposed AWS keys remained valid for an additional 48 hours after the account was taken down.
Most damning of all: the CISA administrator disabled the default setting in GitHub that blocks users from publishing SSH keys or other secrets in public code repositories. The guardrails were there. They were turned off.
Why “Don’t Commit Secrets” Misses the Point
The standard post-mortem will focus on the human: better training, stricter background checks, mandatory push protection, accountability for the contractor and for Nightwing. All reasonable. None of it addresses the architectural decision to issue long-lived, static, plaintext credentials, which created this incident in the first place.
If you accept that credentials will sometimes end up where they shouldn’t — committed to a repo, copied to a home laptop, screenshotted into a Slack DM, sitting in a CSV on a contractor’s desktop — then the only durable answer is to ensure the credential is either already expired by the time it leaks, never existed as a static value, or cannot be read even if exfiltrated.
That is the design center of the Akeyless Platform.
What Akeyless Would Have Changed
Let’s walk the actual incident through an Akeyless-protected architecture, layer by layer.
1. The AWS GovCloud admin keys would not have existed as static credentials.
In an Akeyless deployment, privileged AWS access is delivered through Dynamic Secrets. Rather than provisioning a permanent IAM user with admin policies, Akeyless defines an AWS Dynamic Secret producer bound to a target IAM role. When an admin or pipeline needs access, they authenticate to Akeyless (typically via OIDC from their identity provider) and receive a short-lived AccessKeyId, SecretAccessKey, and SessionToken scoped to a single role with a configurable TTL (usually minutes).
akeyless dynamic-secret create aws \
--name /gov/cisa/aws-govcloud-admin \
--target-name govcloud-target \
--aws-access-mode iam_user \
--aws-role-arns arn:aws-us-gov:iam::123456789012:role/PrivilegedOps \
--user-ttl 15mThe “importantAWStokens” file could not have contained admin credentials because admin credentials in this model do not exist as durable strings. Even if a contractor copy-pasted the output of a single retrieval, that output would have expired within 15 minutes — long before the GitHub indexer surfaced it, let alone the six-month exposure window the actual incident produced. The 48-hour post-takedown validity window is structurally impossible: there is no static key to forget to revoke.
2. The plaintext password CSV would not have been retrievable in plaintext, even by Akeyless itself.
The “AWS-Workspace-Firefox-Passwords.csv” file is a textbook secrets-in-spreadsheet failure. In an Akeyless deployment, those credentials would have lived as Static Secrets inside the platform but protected by Distributed Fragments Cryptography™ (DFC™), Akeyless’s patented Zero-Knowledge architecture.
DFC does not split an existing key into pieces. Key fragments are independently generated across separate cloud regions and accounts, and one fragment is held exclusively by the customer (in this case, it would be deployed inside CISA’s own GovCloud partition via the Akeyless Gateway). The complete key never exists in memory at any single location, including Akeyless infrastructure. Cryptographic operations happen as a distributed computation across fragments.
The practical consequence for the CISA scenario: a contractor exporting the contents of their browser password manager into a CSV is a serious incident. A contractor exporting Akeyless-managed credentials cannot produce a plaintext CSV without authenticating to Akeyless and triggering audit events for each retrieval. These events flow directly into the agency’s SIEM via the local Gateway, with anomaly detection on bulk-export patterns.
The platform is CMVP-validated FIPS 140-3 Level 1 (NIST CMVP #5227). For workloads requiring the highest assurance, the customer fragment can be protected inside a FIPS 140-2 or 140-3 Level 3 HSM, which is relevant for DoD IL4/IL5, FedRAMP High, and CJIS.
3. The kubeconfig would have been a short-lived, brokered access token.
In Akeyless, Kubernetes cluster access for administrators is delivered through Secure Remote Access (SRA), a brokered session model where the admin never sees or holds the cluster credential. The credential is generated dynamically, the session is recorded, commands and output are captured into a transcript forwarded to the SIEM, and the credential is revoked at session end.
A kube-config.txt file on a contractor’s laptop is, in this model, not a useful artifact to anyone. It would not contain a working credential.
4. The “disable GitHub Push Protection” maneuver would have been irrelevant.
This is the architectural point that matters most. The contractor disabled GitHub’s secret-scanning push protection because there were secrets on their machine to push. In an Akeyless architecture with Secretless Authentication:
- The developer’s laptop authenticates to Akeyless via OIDC token from their IdP (SAML, Entra, Okta, Google) — no API key to store, no secret in ~/.aws/credentials, no token in .env
- The CI/CD pipeline authenticates via its GitHub Actions OIDC token, bound by Auth Method policy to a specific repository, branch, and workflow — no static AWS_ACCESS_KEY_ID in repository secrets
- Workloads in Kubernetes authenticate via Service Account JWT or SPIFFE — no Kubernetes Secret to mount
There is no .aws/credentials file. There is no Important AWS Tokens.txt. The act of “disabling push protection to commit secrets” requires secrets to exist. They don’t.
With Akeyless, secrets are never stored whole, and increasingly, are never stored at all. Where they must exist, they exist as fragments across a distributed network that the vendor itself cannot reconstruct.
What the CISA Statement Actually Means With Akeyless
CISA’s spokesperson said “Currently, there is no indication that any sensitive data was compromised as a result of this incident.” With the architecture as it stands today, that statement is a hope built on logs and access patterns that may or may not have been collected.
In a Zero-Knowledge architecture, that statement is structurally provable in three ways:
| Claim | How Akeyless makes it verifiable |
|---|---|
| “The exposed credentials were not used” | Every credential issuance is logged, identity-bound, and tamper-evidently recorded. TTLs ensure exposure windows are minutes, not months. |
| “No lateral movement to Artifactory” | Artifactory access is brokered through SRA with session recording. Each session has a recorded transcript. |
| “Akeyless cannot have leaked customer data” | DFC mathematically prevents the vendor from reconstructing keys. Compelled disclosure produces nothing usable. |
The Federal Posture Argument
For federal agencies and their contractors operating in GovCloud, the architectural primitives matter beyond this incident:
- Customer Gateway deployed inside the GovCloud partition; plaintext never crosses a jurisdictional boundary
- FIPS 140-3 Level 1 validated cryptography (CMVP #5227), with optional HSM-backed custody for FedRAMP High / IL4 / IL5
- Audit trails stream locally; every secret retrieval, every authentication, every dynamic credential issuance flows from the Gateway into the agency’s in-region SIEM with tamper-evident append-only logging
- Hybrid TLS 1.3 with ML-KEM768 today, for post-quantum protection against harvest-now-decrypt-later collection
- Secure Remote Access with session recording for privileged operations on cloud consoles, databases, SSH, RDP, and Kubernetes
- Universal Secret Connector for governance over existing AWS Secrets Manager, HashiCorp Vault, and Azure Key Vault deployments without forcing migration
The Uncomfortable Question for Every Federal CISO
The CISA contractor was apparently using a public repo as a sync mechanism between their work laptop and home computer. That is a culture problem, a contracting problem, an oversight problem, and a training problem.
It is also a capability problem. If your authentication architecture forces administrators to handle long-lived credentials in plaintext, some fraction of those administrators will mishandle them. Not because they are bad actors — though some are — but because the design hands them a primitive that is fundamentally incompatible with the way humans work.
The question isn’t “how do we stop the next contractor from doing this.” It’s “why do we still issue credentials in a form that can be done this way?”
To learn more, schedule a 30-minute architectural review with an Akeyless solutions engineer. We’ll walk through your current credential issuance model and show you what removing the static-secret primitive looks like in your environment.
