On May 18, Brian Krebs reported that a federal contractor had maintained a public GitHub repository for roughly six months, exposing AWS GovCloud administrative credentials, plaintext passwords in a CSV, kube-config files, and bookmarks to dozens of internal CISA systems. The contractor was using the repository to synchronize files between a work laptop and a personal computer, and had explicitly disabled GitHub’s default push protection. By the time CISA was notified and the repository was removed, the AWS keys remained valid for another 48 hours. The incident is going to drive a wave of contractor audits across every program office with a comparable arrangement, which is most of them. The question for federal IT leadership is not whether this could happen on your contract. It is which of your controls would have caught it before commit number one.
Where the Layers Failed
This was not a single mistake. It was a sequence of missing layers, almost all of which map directly to NIST SP 800-171 controls that have been required of every federal contractor handling Controlled Unclassified Information since the CUI program took effect. Walking the chain in order:
Long-lived administrative access keys (3.13.10, 3.1.5). Static AWS access keys with admin privilege should not exist on a 2026 federal program. Modern AWS architectures use STS for temporary session credentials, IAM Identity Center for human access, and IAM Roles Anywhere for workloads outside AWS. The fact that a single endpoint compromise yielded six months of valid credentials is itself a design failure that sits upstream of every other layer.
Plaintext credential storage (3.5.10). NIST 800-171 explicitly requires storing and transmitting passwords only in cryptographically protected form. A CSV of usernames and plaintext passwords on a workstation fails this requirement at the storage layer. A secrets vault, a password manager, or even an OS keychain would satisfy the control.
Unsanctioned external sync (3.1.20). The control requires verifying and controlling connections to external systems. Personal GitHub for file synchronization is exactly the scenario it was written for. The contractor’s intent was operational, not malicious, but the absence of a sanctioned cross-device sync path is the underlying gap. If the approved option is friction-heavy, engineers will invent unsanctioned ones.
Overridable configuration controls (3.4.2, 3.4.6). GitHub’s secret-scanning push protection is the kind of control that should be enforced at the organization tier and not overridable by an individual user. Federal contractor security assessments look specifically for whether security configurations are persistent across users, not optional preferences toggled in a personal settings page.
Public repository (3.1.22). NIST 800-171 dedicates a control specifically to information posted on publicly accessible systems. A repository containing infrastructure credentials should not be reachable from the public internet, full stop. An organization-level GitHub setting can prevent any user in the org from creating public repositories.
No outbound DLP or behavioral analytics (3.14.6). The credentials traveled over the network in plain view of an outbound boundary. A DLP or CASB rule matching on AWS key prefixes and CSV password columns would have flagged the push at the egress point. NIST 800-171 requires monitoring organizational systems and the use of those systems by authorized users.
What stands out about this list is that none of these controls are novel or aspirational. All have been required practice in NIST SP 800-171 for years and are echoed in FAR 52.204-21 for every federal contract. CISA itself publishes the Zero Trust Maturity Model and the SCuBA Secure Configuration Baselines, both of which codify the same controls in even more operational form. The failure is not in the framework. It is in the gap between framework adoption and operational enforcement.
The Forty-Eight-Hour Key Window
Even after CISA was notified, the AWS GovCloud keys remained valid for another 48 hours before being rotated. That is a separate failure worth examining on its own, because credential lifecycle discipline is one of the most under-invested areas of operational security across federal cloud environments.
Long-lived AWS access keys are an anti-pattern. AWS itself has been recommending against them for years. Modern architectures rely on AWS Security Token Service (STS) for temporary session credentials with lifetimes between 15 minutes and 12 hours, IAM Identity Center for federated human access, IAM Roles Anywhere for workloads authenticating with X.509 certificates from enterprise PKI, and GitHub OIDC federation for CI/CD pipelines so that no long-lived deployment keys exist at all. In an environment built on these primitives, the contractor would not have had a long-lived admin key to leak. There would have been a session token with a one-hour lifetime, an audit trail of every assumption, and a CloudTrail event for each call against GovCloud. Compromise would mean an attacker had a window of minutes, not months.
For the controls that do still require long-lived secrets, automated rotation should be the default. AWS Secrets Manager supports scheduled rotation for IAM access keys with a Lambda trigger. The infrastructure has existed for years. Adopting it is a configuration decision, not an engineering project.
A 48-hour key validity window after disclosure of a leak is not a tooling problem. It is a runbook problem. Every federal cloud program should be able to answer one question with a single number: how long does it take, from notification to revocation, to invalidate a compromised credential? If the answer is longer than fifteen minutes, the runbook needs work.
What Program Offices Should Ask This Week
For a contracting officer or program manager reading the Krebs piece, the natural next question is what to do about your own contractors right now. Here is a punch list, framed as questions to put to your prime and sub contractors handling CUI or operating in your cloud environments.
- Identity and credentials. Do you use IAM Identity Center or IAM Roles Anywhere for human and machine access to our cloud environment? If long-lived access keys exist, what is the rotation policy and who audits it?
- Repository governance. Is your enterprise GitHub (or GitLab) organization configured to block users from creating public repositories? Is push protection for secret scanning enforced at the org tier and not overridable by individual users?
- Sanctioned sync paths. What is your approved mechanism for engineers to synchronize work artifacts between machines? Is personal GitHub explicitly blocked or monitored at your network egress?
- Endpoint posture. Are credentials, tokens, and configuration files containing secrets stored only in approved secrets vaults on contractor endpoints? Is there a DLP rule that pattern-matches on AWS key prefixes, JWT structure, or CSV files with password columns?
- Egress monitoring. Do you have a CASB or DLP solution monitoring outbound git push, file upload, and webmail traffic for secret patterns? When were the rules last tuned?
- Revocation runbook. What is your contractually committed time from notification of a leaked credential to its invalidation across all systems, and what does the proof of execution look like?
- Audit logging. Are CloudTrail, GuardDuty, and equivalent SIEM feeds being actively monitored, not just collected? Who reviews the alerts and on what schedule?
- Configuration enforcement. For every security configuration that is technically overridable by an individual user, what is the compensating control and how is the override detected?
- NIST 800-171 evidence. If you claim conformance with NIST SP 800-171, can you produce assessment evidence for the controls referenced above? An assertion of conformance is not the same as assessed conformance.
- Incident reporting cadence. What is the contractually defined window for reporting an actual or suspected credential compromise? Is it 24 hours, 72 hours, longer? Most contractors will be able to answer the first five quickly. The last five separate the contractors who have done the work from the ones who have not.
Final Thoughts
The May 2026 CISA incident is going to be retold for a decade as a cautionary tale, and most of the retellings will focus on the individual who made the mistake. That framing is wrong. Individuals make mistakes constantly. The job of a security program is to make sure no single mistake produces a six-month exposure of administrative credentials at a federal cybersecurity agency. The controls that would have caught this exist, are well documented, and are required by NIST SP 800-171 for every federal contractor handling CUI. CISA itself publishes the Zero Trust Maturity Model and SCuBA Secure Configuration Baselines that operationalize the same controls. The lesson is not that contractors need more training. It is that program offices need to verify, on an ongoing basis, that the contracted security posture matches the assessed security posture. The May 2026 leak was not a controls gap. It was an enforcement gap.
If you’d like to learn more about how S2i2 can help, contact us at info@s2i2.com or call us at 1-844-946-7242. Follow us on LinkedIn for more updates from the S2i2 team.
