CISA Contractor Exposes AWS GovCloud Keys: A Supply Chain Reality Check
Just saw the write-up on Krebs about the CISA contractor leaking AWS GovCloud credentials. You can't make this stuff up—the agency responsible for our nation's critical infrastructure security had their own infrastructure keys sitting in a public repo.
The report mentions it wasn't just the keys; it was the blueprints for how they build and deploy software. This screams a lack of basic static analysis (SAST) in the CI/CD pipeline. If a CISA contractor can make this mistake, it's a safe bet your MSPs are doing it too.
For those managing orgs with external contributors, are you relying on manual reviews or forcing scanning?
If you aren't using pre-commit hooks for secret scanning, start now. Here is a quick setup for git-secrets to catch AWS keys before they hit the remote:
git secrets --install
git secrets --register-aws
git secrets --add 'private_key'
git secrets --add '"password": ".*"'
On the detection side, if this happened to you, would GuardDuty catch it fast enough? You'd likely see a `Discovery:S3/MaliciousIPCaller` or `IAMUser/AnomalousBehavior` if the keys were used immediately.
How are you handling credential rotation when a third-party repo is compromised? Is there a scriptable way to invalidate all active sessions tied to a leaked key instantly?
This is why we push hard for ephemeral credentials via OIDC rather than long-lived static keys. If you rotate a static key, the attacker might still have a valid session token. With OIDC, the token lifespan is short and defined by the role trust policy.
For detection, we set up a CloudWatch Event rule on Alert severity for any ConsoleLogin or API call originating from outside our known IP blocks in GovCloud regions.
We moved away from git-secrets because it was easy to bypass. Gitleaks is much more aggressive and has a configurable config.toml for custom regex patterns specific to our internal apps.
Regarding rotation, we automate the invalidation using a Lambda function triggered by GuardDuty findings. It parses the finding details and immediately calls DeleteAccessKey. It's a bit nuclear, but it works.
It's wild that the build/deploy pipeline was exposed too. That gives an attacker the roadmap for lateral movement without even needing the keys initially.
We audit our repos every quarter with this one-liner to ensure nothing slipped through the cracks:
git log --all --full-history --source --pretty=format:"%H" -- "*.tf" "*." | xargs -I % sh -c 'git show %:*.tf 2>/dev/null | trufflehog git raw --repo https://github.com/target/repo --commit %'
Paranoid? Maybe. Necessary? Apparently.
Validating Infrastructure as Code (IaC) locally before pushing is a layer many skip. While repo scanners catch the leak, preventing it from leaving the dev machine is better. We integrate tfsec into pre-commit hooks for Terraform files to catch exposed variables or secrets in state references early.
pre-commit run tfsec --all-files
It’s a cheap check that saves a massive headache later, especially when dealing with sensitive GovCloud ARNs.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access