{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreibxxcwwyzfpih56zt6tmeouhbbeuas27j7eesiaxajsbjxvo2izfu",
    "uri": "at://did:plc:haakkg7y3xdghcdmprxeexso/app.bsky.feed.post/3mm643isrjrz2"
  },
  "path": "/t/cisa-admin-leaked-aws-govcloud-keys-on-github-krebs-on-security/38004#post_1",
  "publishedAt": "2026-05-18T23:48:16.000Z",
  "site": "https://discuss.privacyguides.net",
  "tags": [
    "krebsonsecurity.com",
    "CISA Admin Leaked AWS GovCloud Keys on Github – Krebs on Security"
  ],
  "textContent": "krebsonsecurity.com\n\n### CISA Admin Leaked AWS GovCloud Keys on Github – Krebs on Security\n\nUntil this past weekend, 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...\n\nI don’t blame the human(s) here. This should not be technically _possible_ today. We have to change the way we create and manage machine secrets - and then our tools should reject committing them to public code repositories. This is happening way too often.\n\nLikewise, it should not be possible to have an unencrypted, public “data bucket” (like AWS)… but that’s a different story.\n\nMachine secrets don’t have to be human-friendly… which means they could be strongly typed, self-identifying, scope-aware potentially, and (crucially) machine detectable. Some secrets already are doing this.",
  "title": "CISA Admin Leaked AWS GovCloud Keys on Github – Krebs on Security"
}