obviously leaking the credentials itself is crazy, given that its (a contractor to) CISA, but to not respond when notified? crazy crazy.
but wait! it gets worse somehow
"“AWS-Workspace-Firefox-Passwords.csv” — listed plaintext usernames and passwords for dozens of internal CISA systems"
while i understand and sympathize with the fact that CISA is kind of being gutted, a passwords.csv with weak passwords is inexcusable incompetence. not much budget is required for a password manager.
embarrassing all around.
The real story here is a big gap in existing implementations where shared credentials are needed and used pretty much across all the systems but there are no good solutions for managing such use cases. People are naturally more sensitive about their personal secrets than something thats shared across the company/group
This strikes me as so wrong, I wonder if I’m misreading your comment. For instance, team password managers are a thing. And IT teams at many large corporations are not passing around an unsecured CSV files full of passwords.
A group was working on Diebold voting insecurity, and foreign implant hacking. Gone.
It is a bad plan that has and will continue to harm people, but it is intentional.
https://techcrunch.com/2025/03/11/doge-axes-cisa-red-team-st...
> Elon Musk’s Department of Government Efficiency (DOGE) has fired more than a hundred employees working for the U.S. government’s cybersecurity agency CISA, including “red team” staffers, two people affected by the layoffs told TechCrunch.
The spreadsheet of passwords is a tad more common than it should be because the password managers don't meet whatever arbitrary checklist of invented cyber security requirements they blindly follow. But Excel does.
Lol
The not-responding-when-notified part makes me think it's not just incompetence.
Strong disagree. The person in question probably thought it was a private repo on Github and had a massive deer in headlights reaction when they got contacted. Whoever this is, lost their job, possibly security clearance and more. This was 100% life altering "mistake"/gross incompetence decision they made.
That doesn't support the theory that it was a mistake. That was intentional action. Maybe he was being blackmailed, and was coerced to do it. Or maybe he was a foreign agent or sympathizer who had infiltrated the organization.
I've been a government contractor before, it does not employ best and brightest, it employs the average and below generally.
For some people, yeah, this could be a career killer. For some other people, it might just precipitate a flight back to Moscow or Beijing or something.
Your LLM will happily read the entire file, ship it off to be training data for future versions of ChatGPT, and not raise any flags, because let's be fair it was on ok thing to check if all the env vars were set, or it you had set up the database password for the app.
It's time for orgs to audit and rotate secrets wherever they are stored in disk or in logs, and switch to SOPS or Vault or whatever to keep these out if plaintext except exactly when needed.
But not everyone is where they need to be. For instance, railway doesn't let you access AWS resources via roles/OIDC. I filed a ticket[0] but haven't seen movement.
0: https://station.railway.com/feedback/allow-for-integration-w...
Additionally provides pre commit scanning, log redaction, and much more.
Here's one interaction, when I was planning through ways to finally get away from the dreaded .env file, I told Claude that it had already read my secrets, and it said:
> This is an important point and I want to be straight with you first.
> ## What already happened in this conversation
> Yes — the Explore agent read your .env and returned the full plaintext contents into the conversation, which means:
> 1. Sent to Anthropic's API — those credentials passed through Anthropic's servers as conversation context
> 2. Cached locally — Claude Code stores session transcripts; your secrets are likely sitting in ~/.claude/projects/ right now
> 3. In this context window — they're in active memory for this session
...
Which I already knew, but it was funny how it suddenly took it very seriously when told what it was doing.
Anything that's in your .bashrc, .zshrc, any environment variables in shells you provide to the LLM, all those are now in the training data of very large overvalued corporations that are desperate to increase their revenue and IPO very soon.
Varlock is a great and flexible way to do this.
But what AI really does is shine a spotlight on all the flaws folks like OWASP have been talking about for decades.
Secret rotation and short lived credentials don't require AI to implement, nor does their lack require AI to exploit.
And in this particular case of CISA secrets, they are definitely stored inside of LLMs for future retrieval, even if no bad actors ever directly downloaded this obscure GitHub repo.
During early stage dev Claude will happily gobble up API keys and DB passwords from .env files. Perhaps not such a big deal for early stage dev, but getting Claude to cough up precisely memorized tokens in the future by asking it to produce a "random" key of a certain sort will probably be an entertaining pastime for people in the future.
user data is always paraphrased for training. what do you mean, not raise any flags?
look... Google is running your browser, Apple your messenger, Amazon your backend. They already have all these keys in the same way, are they misusing them? Why doens't it raise any flags then?
localhost reading env from the cloud and other solutions
to me it suggested that I’m already late on that idea, but I can understand how that puts me deeper in a bubble than others
[1] https://www.politico.com/news/2026/01/27/cisa-madhu-gottumuk...
Seems like no big deal for CISA. Defunded really paying off now.
Workload identities and passwordless auth are the one true path.
It's the first time I hear about replacing API keys
Infrastructure - https://dev.azure.com/byteterrace/Koholint/_git/Azure.Resour...
Server - https://dev.azure.com/byteterrace/Koholint/_git/Web.Function...
Client - https://dev.azure.com/byteterrace/Koholint/_git/Web.Portal
IAM roles/workload identity.
Even time-limited or signed JWT, though has a separate issues.
Maybe you'll say 'those are both just text values passed like an apikey' though api keys don't frequently rotate/time limited, which is an important security feature.
Then the LLM slurps up your refresh token. What's next?
Sure, a leak would be bad but I'd argue that it's orders of magnitude less likely compared to the accepted norm.
The server still does authorisation on top. And unless you control the private keys, you cannot mint JWTs that are accepted as legitimate.
So the "info" leaking is really not a problem.
Turns out those standards writers knew something!
If you're going to call people a bunch of dopes and generally assault their intelligence, you might want to spell things correctly.
>shit it down
Nov 2025 was also when most of us learned about the acting Chief Security Officer at DHS, whose name AND photo seem exactly like the calling card of someone who had these "keys to the kingdom". https://bsky.app/profile/andylevy.net/post/3m6ivhnthts2o
I want to believe...