There is a particular kind of institutional irony in the fact that the United States Cybersecurity and Infrastructure Security Agency, the body nominally responsible for setting federal cybersecurity standards, has now had its own AWS GovCloud administrative credentials exposed in a public GitHub repository for months. The incident, first reported by Brian Krebs at KrebsOnSecurity, represents a failure at nearly every layer of a defence-in-depth model: technical controls, procedural hygiene, organisational oversight, and incident response.
The repository in question, named Private-CISA and maintained by a contractor from Nightwing, a government services firm based in Dulles, Virginia, was created on November 13, 2025. It remained publicly accessible until mid-May 2026, a window of roughly six months. During that period it contained, among other things, a file called importantAWStokens holding administrative credentials to three AWS GovCloud accounts, a CSV file of plaintext usernames and passwords for dozens of internal CISA systems, and what appears to be configuration and build artefacts from the agency's internal DevSecOps environment.
What the Exposure Actually Contained
To assess severity, it is worth being precise about the categories of data involved rather than treating this as a single monolithic leak. Based on the reporting, the exposed material falls into at least four distinct risk tiers:
- High-privilege cloud credentials: Administrative keys to three AWS GovCloud accounts, validated by security researcher Philippe Caturegli of Seralys as still-active at the time of discovery. GovCloud accounts are isolated AWS regions specifically designed for US government workloads subject to ITAR, FedRAMP, and related compliance frameworks. Administrative access to these is, by definition, access to sensitive federal infrastructure.
- Internal system credentials: Plaintext passwords for dozens of internal CISA systems stored in a CSV, including access to what appears to be the agency's Landing Zone DevSecOps environment, referred to in the files as LZ-DSO.
- Artifactory credentials: Perhaps the most structurally dangerous element. Access to an internal Artifactory instance, the package repository used in software builds, creates a supply chain attack surface. An adversary with write access to Artifactory could inject malicious packages that would be silently incorporated into every subsequent build, propagating a backdoor across CISA's software estate without any single obvious intrusion event.
- Build and deployment metadata: Files describing how CISA builds, tests, and deploys software internally. Even without active credentials, this information substantially reduces the reconnaissance burden for a targeted attacker.
The password hygiene revealed in the repository is independently alarming. Multiple credentials followed a pattern of platform name concatenated with the current year, a scheme that would be trivially defeated by any credential stuffing or targeted brute-force campaign, even without the external exposure.
How This Happens: The Scratchpad Anti-Pattern
Caturegli's hypothesis that the repository was used as a synchronisation mechanism between a work laptop and a home computer is both plausible and well-documented in the security literature as a recurring failure mode. When developers lack sanctioned, low-friction tools for cross-device file synchronisation, they improvise. Git repositories are familiar, version-controlled, and free. The problem is that the cognitive model required to keep secrets out of version control is non-trivial, particularly under time pressure or when working across environments with different toolchain configurations.
What makes this case particularly egregious is the evidence that the contractor actively disabled GitHub's secret scanning feature. This is not a passive oversight but a deliberate action to suppress a safety control. GitHub's push protection, when enabled at the repository or organisation level, will block commits containing recognised secret patterns and alert the user. Disabling it requires navigating into repository settings and explicitly toggling the protection off. The commit logs, according to Guillaume Valadon of GitGuardian, show this was done intentionally.
This points to a failure of organisational controls rather than purely individual negligence. In a well-governed environment, repository-level security settings for accounts associated with sensitive projects should be enforced at the organisation level, not left to individual discretion. The fact that a contractor could create a public repository named Private-CISA, disable secret scanning, and commit plaintext credentials repeatedly over six months without triggering any automated alert or human review is a systemic failure.
The 48-Hour Key Validity Window
One of the most operationally significant details in the Krebs report is that the exposed AWS keys remained valid for approximately 48 hours after CISA was notified and the repository was taken offline. This is not a minor procedural delay. It is a direct measure of the organisation's incident response capability for credential compromise scenarios.
Standard practice in credential compromise response is immediate rotation, not eventual rotation. AWS IAM provides mechanisms for disabling access keys without deleting them, allowing for forensic investigation while eliminating active risk. The fact that this did not happen promptly raises questions about whether CISA had a documented, rehearsed runbook for exactly this scenario, which is a scenario that CISA itself advises other organisations to prepare for.
The 48-hour window also has concrete threat implications. Automated scanning of public GitHub repositories for exposed cloud credentials is not a novel capability. Tools like TruffleHog, Gitleaks, and GitGuardian's own platform operate continuously, and threat actors run equivalent tooling. It is not possible to determine from public reporting whether the credentials were accessed by malicious parties during the exposure window, but the exposure window was long enough that the question is not merely theoretical.
Institutional Context and Structural Risk
CISA's current operational state is relevant to this analysis. The agency has lost close to a third of its workforce since early 2025 through a combination of forced retirements, buyouts, and resignations. Reduced headcount in security operations directly affects the capacity for code review, access control auditing, and anomaly detection. It also increases reliance on contractors, who may operate with less oversight and fewer enforced controls than direct employees.
The contractor relationship here is worth examining carefully. Nightwing declined to comment, directing inquiries back to CISA. This deflection is unhelpful but not surprising. Government contracting arrangements frequently create ambiguity about which party is responsible for enforcing security controls on contractor-maintained systems. A robust contractor security programme would typically include: mandatory use of organisation-managed GitHub accounts rather than personal ones, prohibition on public repositories for any work-related code, automated secret scanning enforced at the organisation level, and periodic access reviews. Whether any of these controls were specified in the Nightwing contract is unknown.
The use of both a CISA-associated email address and a personal email address on the same GitHub account, noted by Caturegli, suggests the contractor was operating in a grey zone between personal and professional tooling. This is a well-known risk in environments where bring-your-own-device or remote work practices are common without corresponding policy enforcement.
Implications for Federal Security Policy
This incident sits within a broader pattern of credential exposure incidents affecting government and critical infrastructure organisations. The 2020 SolarWinds compromise demonstrated that supply chain vectors, exactly the kind of attack that Artifactory access would enable, are among the most consequential available to sophisticated adversaries. CISA produced extensive guidance in the aftermath of that incident. The gap between the guidance CISA publishes and the practices evidenced in this repository is difficult to overstate.
Several concrete technical recommendations follow from this analysis:
- AWS GovCloud accounts should be configured with short-lived credentials via IAM Identity Center or similar, reducing the blast radius of any single credential exposure to hours rather than months.
- GitHub organisations managing sensitive work should enforce push protection and secret scanning at the organisation level, making it impossible for individual members to disable these controls.
- Artifactory and similar internal package registries should require multi-factor authentication and maintain detailed audit logs of all package publish operations.
- Contractor-managed repositories should be subject to the same automated scanning that GitGuardian applied externally, but applied internally and continuously.
- Incident response runbooks for credential compromise should specify maximum acceptable time-to-rotation measured in minutes, not days.
CISA's statement that there is currently no indication that sensitive data was compromised is the standard response to this class of incident, and it should be read with appropriate scepticism. Absence of evidence of compromise is not evidence of absence, particularly given that the exposure window was six months long and the credentials provided administrative access to federal cloud infrastructure.
The deeper problem is not the individual contractor's mistakes, though those are real and serious. It is that an agency responsible for advising the rest of the federal government on cybersecurity practice apparently lacked the automated controls, monitoring, and incident response procedures that would have caught this exposure within hours rather than months. Rebuilding that capacity, under current budget and staffing constraints, is the actual challenge that this incident surfaces.