[grayhatter]

> I don't know what methods where used to find these exploits but I am starting to think security through obscurity might not be a bad thing in this day and age, where someone can just let bots loose on your codebase.

I'd love to hear why you think obscurity is bad, if you now think maybe it's good in the LLM age?

I'd also be interested if you could describe exactly what or how you think security through obscurity works, or doesn't?

I've been thinking a lot about how to better teach this concept, so I'm looking to understand exactly how everyone thinks/understands how it currently works, or should work, or what it should do. I don't care about the "correct" answer, (I have ddg too :P) I'm interested in general expectations from SWE's that I might teach at work, instead of opinions of security eng speaking about theory.

[GTP]

Security through obscurity can make something a bit more secure in practice by annoying an attacker IF AND ONLY IF you're not relying on the hidden information remaining secret in order to the system remaining secure. E.g., if you're using a broken cipher and assume this is ok because no one knows which cipher you're using, you're gonna have a bad time.

In the case of FOSS software, it is generally recognized that the small advantage of keeping the source secret is far outweighted by the contributions and vuln reports you get if you publish the source.

[merelydev]

"one ought to design systems under the assumption that the enemy will immediately gain full familiarity with them" - Claude Shannon

https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle

[grayhatter]

If you believe this, then why did you say?

> starting to think security through obscurity might not be a bad thing

[merelydev]

Because of asymmetric differences, I don't have access to powerful LLMs but attackers might. And also the complexities of software dependencies (supply chain vulnerabilities), my software depends on packages not in my control and I don't have time to audit the entire stack.