upvote

points

by merelydev5 hours ago |
comments
upvoteby serf5 hours ago|
next
[-]
llms are fantastic disassembly partners, they're quite good at labeling functions from various dissassemblers -- the net losses from losing the benefits of open source , imo , outweigh the protection afforded by hiding your source code in yet another layer that is more and more easily unrolled through automated procedures.
reply
upvoteby blensor4 hours ago|
parent|
next
[-]
And isn't it also mostly a transitioning issue. Those open codebases will be constantly scanned for potential security issues and getting more and more hardened. There are probably a lot of easy wins that are going to be discovered over the next few years but it should taper out after a while.
reply
upvoteby merelydev4 hours ago|
parent|
[-]
Fair point but it assumes we all have access to LLMs with the same capabilities.
reply
upvoteby yjftsjthsd-h4 hours ago|
parent|
[-]
I don't think that's exactly it. OSS only needs someone to have a strong LLM to check for bugs. If your software is proprietary, it's a competition between just you and whatever model you have vs any attacker and whatever model they can lay hand to.
reply
upvoteby GTP3 hours ago|
parent|
[-]
I don't see the difference.

> OSS only needs someone to have a strong LLM to check for bugs.

The same applies to propietary, closed-source code. It being closed-source means that the source isn't generally available, but the executable is. Hence, someone with a strong model can still reverse it and find vulns.

reply
upvoteby 4 hours ago|
parent|
prev|
next
[-]
deleted
reply
upvoteby spongebobstoes4 hours ago|
parent|
prev|
[-]
disassembly only applies to client side software

something like nginx could arguably be more secure if it was closed source

(I am a proponent of and contributor to open source)

reply
upvoteby gpm4 hours ago|
parent|
next
[-]
Only until a single server running nginx is hacked and the binary leaked though...
reply
upvoteby Hizonner4 hours ago|
parent|
prev|
[-]
Um, the nginx binary would have to be in the hands of hundreds of thousands of server operators. And the set of server operators is rich in the kind of person who would attack it. Not to mention the huge number of leaks you'd get.

Maybe if it's some server-side software that you only use yourself...

reply
upvoteby maxloh4 hours ago|
prev|
next
[-]
Open source is a good thing, but I don't think what you are proposing is accurate.

A different way to frame this would be that those bugs would never be surfaced or exploited if the software were proprietary.

reply
upvoteby derektank4 hours ago|
prev|
next
[-]
Presumably, one could let the bots loose on your own codebase first. The question is one of financing of course. If your end users are enterprises willing to pay for a support contract, they probably care enough about not getting hacked to endure the higher prices that would let you throw enough tokens at the problem. Other open-source projects might have a harder time.
reply
upvoteby IshKebab1 hours ago|
prev|
next
[-]
I think LLMs might actually have a bigger effect on closed source software - the tedium saved on open source bug hunting is significant, but on closed source software the tedium of finding bugs is extreme because of all the reverse engineering, but LLMs will chew through that. So there's probably a lot of low hanging fruit.
reply
upvoteby grayhatter3 hours ago|
prev|
next
[-]
> 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.

reply
upvoteby GTP3 hours ago|
parent|
next
[-]
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.

reply
upvoteby merelydev3 hours ago|
parent|
prev|
[-]
"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

reply
upvoteby grayhatter3 hours ago|
parent|
[-]
If you believe this, then why did you say?

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

reply
upvoteby merelydev2 hours ago|
parent|
[-]
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.
reply
upvoteby asadotzler48 minutes ago|
parent|
[-]
Perhaps the answer is to depend only on packages that come from people that are more competent than you so you can know if or when your program is compromised that it'll most likely be your fault and not theirs.
reply
upvoteby throwaway6137464 hours ago|
prev|
[-]
[dead]
reply