Having the security team redirect the report to the HackerOne program is wild.
At least someone had enough thought to eventually forward it to someone who could fix it.
In my experience post-training mainly deals with "how" the model displays whatever data ("knowledge") it spits out. Having it learn new data (say the number of screws on the new supersecretengine_v4_final_FINAL (1).pdf) is often time hit and miss.
You'd get much better results with having some sort of RAG / MCP (tools) integration do the actual digging, and the model just synthesising / summarising the results.
I mean, consider The Boring Company sell a "flamethrower" despite being theoretically about… boring.
But they sold a blowtorch aka not a flamethrower. The difference being a flamethrower actually "throws flames" like 10+ feet.
I put quotemarks around "flamethrower" because that's what it was originally sold as before obvious and predictable legal issues with real flamethrowers and the fact it was obviously mimicing the prop in Spaceballs.
My point is: neither weed burners nor actual flamethrowers have anything to do with digging tunnels nor any adjacent aspect of civil engineering.
Just saying. It's kinda on brand by not being on brand because the whole network of companies... well I'm trying off topic.
It doesn’t matter how the person got access to dual-use info, like basically everything to do with large rockets, it’s 100% forbidden.
Of course Elon hires only based on 'merit'...
https://www.gitguardian.com/monitor-internal-repositories-fo...
GitGuardian's public report on secrets sprawl talks about their methodology of scanning any commit https://www.gitguardian.com/state-of-secrets-sprawl-report-2...
Definitely not how I would run an organization (even a military organization), but it's not _conceptually_ wrong. If you were a general and you had lieutenants expressing "hostility to" your agenda, would you keep them on? Again, I'd probably say yes up to a limit, but it's not outside of a generals purview to concern themselves with this.
People still don’t know how LLMs work and think they can be trained by interacting with them at the API level.
Unless they are logging the interactions via the API, and then training off those logs. They might assume doing so is relatively safe since all the users are trustworthy and unlikely to be deliberately injecting incorrect data. In which case, a leaked API key could be used to inject incorrect data into the logs, and if nobody notices that, there’s a chance that data gets sampled and used in training.
I agree that’s unlikely, but not astronomically unlikely
i know, you probably just meant it as a fun comment. but i don't get how this is funny. this person probably relies on income, might have a family to feed... and just made a mistake. a type of mistake, that is not uncommon. i mean i have seen corporate projects where senior engineers didn't even understand why committing secrets might be a bad idea.
yes, of course, as a engineer you have responsibilities and this is clearly an error. but it also says a lot about the revolutionary AIs that will apparently replace all engineers... but the companies claiming it are not using it to catch stuff like this.
and let's keep in mind– i am surely not the only one making this experience: every single time i am using an LLM for code generation, i have to remove hardcoded secrets and explicitly show them how to do it. but even then, it starts to suggest hardcoding sensitive info here and there. which means: A. troublesome results made by these models, presented to inexperienced engineers. and people are conditioned to believe in the superiority of LLM code, given all the claims in the media. but also B: that models suggest this practice, shows just how common this issue is.
yes, this shouldn't happen at any company. but these AI companies with their wild claims should put their money where their mouth is. if your AI is about to replace X many engineers, why is it not supervising at least commits? to public repos? why are your powerful, AGI-agentic autonomous supernatural creations not able to regex the sh outta it? could it be that they don't really believe their own tales? or do they believe, but not think?
of course, an incident like this could lead to attempts of turning it into a PR-win– claiming something like "see, this would have never happened with/to our Almighty Intelligence. that's why it should replace your humans." but then: if you truly believe it and have already invested so much resources, you believe to foresee the future so surely, why ignore the obvious? or are is this silent, implicit testimony, that you got caught up in a hype-train and got brainwashed into thinking, that code generation is what makes a good engineer? (just to be safe: i am not saying LLMs are not useful).
also: that something this could even happen at a company like that, is not the fault of one engineer. it indicates either bad architecture or conventions and/or bad practice and culture... and... a l s o: no (human) code review process in place?
the mistake was made by one engineer, yes. but as though it's made to seem like this mistake is the root... it's not. the mistake is a symptom, not the cause.
i honestly hope the engineer does not get fired. and i really don't understand this mentality. if this person is actually good at their job and takes it seriously, it's certain: he or she is not going to leak a secret again. someone who replaces him or her, might.
If they were good at their job, they wouldn't have leaked the secret in the first place. The correct workflow is to:
1. Create commits that only change do one thing. Not possible to "forget" there were secrets added alongside another feature.
2. When adding secrets, make sure they're encrypted or added to the project's `.gitignore` equivalent.
I'm so sorry for a first-world engineer incompetent enough to commit a secret in a GitHub repository. They'll probably have to downsize from their mansion to a regular house. Meanwhile in the third world, many more competent people are starving or working some terrible menial job because they didn't have the right opportunities in life...
I once put secrets on a wiki page because I copied log snippets and a third party library naively dumped HTTP headers into the logs without filtering out their own API key. I shouldn’t have assumed the logs were secret free, but it’s also not an unreasonable assumption.
Or you don't by simply firing the engineer and assume everyone in the entire workflow is perfect.
* # Default block all
/*
# Specifically allow files and directoriesBut, my comment was clearly not about making excuses for the mistake of the engineer. I wanted to express that it's insane that such a common mistake can happen in a company like that. And i don't get how people let the ceos & leads off the hook so easily.
But some apparently don't think that way.
In my opinion: the mistakes that are common, and severe, and very easy to avoid, have to be expected and hence circumvented through industry standard behaviour. And that is not (solely) the responsibility of one committing engineer. Any good team has best practices to prevent these type of basic, potentially fatal mistakes from happening, and usually at least a glance-over review process where these mistakes should be found by another team member on first sight... and now, when it's an "AI making devs extinct"-type of company... and they're not catch this type of error, is ridiculous. That an individual can screw up something potentially so critical, is an organizational failure.
But anyway, i think my points were clear in the first comment already.
It is also possible that the author's guess is right and that these were to contain sensitive data.
Noone really knows, but honestly, these kinds of mistakes are happening all the time. Who hasn't accidentally leaked their own .ssh dir on github? lol
Leaking the directory through other avenues is a different matter though. Almost all package managers provide post install and compile scripts. Hence doing (as an example) "npm install" can potentially leak it. That's something not many people actually pay attention to (you would have to basically jail every command, which sadly isn't the norm today)
Not quite the same thing, but also a leak: https://blog.gitguardian.com/github-exposed-private-ssh-key/
I guess all these folks saying professionals would never make a mistake like this will also have insulting names for github engineers. :shrug
I'd guess that most of us wouldn't do it by just "git init" in the home directory. There are many safer ways than that.
But we were all newbs once, and often even the newbs have access to various keys and credentials.
But mistakes happen all the item. It's very easy to fat-finger a line in .gitignore - one char off and you're toast.
I have often thought it would be nice to have a good tool to retroactively view and tidy them, but everything I've seen has not quite hit the nail on the head.
And at a certain level of criticality, you do not do this at all
You have security measures in place to prevent this.
Not that the ketaman cares about it.