191–200 of 230 posts
I don't understand the nature of the supposed security incidents found by LLMs: Are these totally previously unknown security holes or are they still generally within the umbrella of our understanding of cybersecurity itself? If it's the latter, why can't we systematically find and fix them ourselves?
Looks similar to the halting problem to me ( https://en.wikipedia.org/wiki/Halting_problem )
There's still the question of access to the codebase. By all accounts, the best LLM cyber scanning approaches are really primitive - it's just a bash script that goes through every single file in the codebase and, for each one and runs a "find the vulns here" prompt. The attacker usually has even less access than this - in the beginning, they have network tools, an undocumented API, and maybe some binaries. You can d…
> it's just a bash script that goes through every single file in the codebase and, for each one and runs a "find the vulns here" prompt. This really is not the case. You have freedom of methodology. You can also ask it to enumerate various risks and find proof of existence for each of them. Certainly our LLM audits are not just a prompt per file - so I have a hard time believing that best in class tools would do this…
And using an LLM to audit your code isn't necessarily a case of turning it into perfect code, it's to keep ahead of the other side also using an LLM. You don't need to outrun the bear, just the other hikers.
Earlier quoted context omitted.
> Web Serial why in the absolute fuck would I want random web pages to be able to control all the devices connected to my computer?
It's essentially for programming microcontrollers, ESP32's and the like. It's really handy. You have to confirm the connection every time.
Earlier quoted context omitted.
I think this is so relevant, and thank you for posting this. Of course it's trivially NOT true that you can defend against all exploits by making your system sufficiently compact and clean, but you can certainly have a big impact on the exploitable surface area. I think it's a bit bizarre that it's implicitly assumed that all codebases are broken enough, that if you were to attack them sufficiently, you'll eventually…
Problem is, the way economic activity is organised in general, there is no transition path from complex bloated systems to well designed completely human auditable systems. For example given the inherent (and proven) security risks of the Wordpress ecosystem, nobody should run WP anymore.
Earlier quoted context omitted.
Commercial infosec is deleting firefox from develop machines, because it's not secure and explaining to muggles why they shouldn't commit secret material to the code repository. That and blocking my ssh access to home router of course.
I mean, often, yep. The real reason why they are unhappy with you having an unsupported browser is simply that it's much harder to reason about or enforce policies across bespoke environments. And in an enterprise of a sufficient scale, the probability that one of your employees is making a mistake today is basically 1. Someone is installing an infostealer browser extension, someone is typing in their password on a p…
Developers usually need elevated privileges, executing unverified arbitrary code is literally their job. Their machines are not trustworthy, and yet, they often have access to the entire company internal network. So you get a situation where they have both too much privilege (access to resources beyond the scope of their work) and too little (some dev tools being unavailable).
There's still the question of access to the codebase. By all accounts, the best LLM cyber scanning approaches are really primitive - it's just a bash script that goes through every single file in the codebase and, for each one and runs a "find the vulns here" prompt. The attacker usually has even less access than this - in the beginning, they have network tools, an undocumented API, and maybe some binaries. You can d…
One defender, many attackers, I don't see how the economy of scale can be positive for the defender. Assuming your code is inaccessible isn't good for security. All security reviews are done assuming code source is available. If you don't provide the source, you'll never score high in the review.
Earlier quoted context omitted.
> Taken to an extreme, the end result is a dark forest. Sorry, how does that work?
since the suggestion is that the new security bug finding LLMs will increase protection because it will have access to the full source code then, the dark forest fear would be, if it is possible for an attacker to get all the source the attacker will be in a better position. This seems wrong however, as it ignores the arrow of time. The full source code has been scanned and fixed for things that LLMs can find before…
And in a world where companies begin to suffer from attacks as a result - can the ones who are willing to invest in security defend themselves, not just against cyberattackers, but against a broader investor and customer backlash that believes that startups that build their own technology stacks are riskier due to perceptions about cybersecurity?
An angel investor or LP who sees news articles and media about cyberattacks, then has a portfolio company get hacked in a material way, may simply decide the space has become too risky for further investments, no matter how much prospects get on better security footings.
The dark forest hypothesis, at its core, is about a decision of whether to put your neck out in the universe; if the weapons and countermeasures being used are too horrifying to fathom, the risks unquantifiable, one chooses not to extend one's neck. And that is how an industry begins to dry.
I don't understand the nature of the supposed security incidents found by LLMs: Are these totally previously unknown security holes or are they still generally within the umbrella of our understanding of cybersecurity itself? If it's the latter, why can't we systematically find and fix them ourselves?
"why isn't everything that could be discovered already discovered"
Big if true. Can you cite an example? I'm all ears.
Earlier quoted context omitted.
It's great news for developers. Extra spend on a development/test env so dev have no prod access, prod has no ssh access; and SREs get two laptops, with the second one being a Chromebook that only pulls credentials when it's absolutely necessary.
Yes, having a good development env with synthetic data, and an inaccessible, secure prod env just got justification. I never considered the secondary SRE laptop but I think it might be a good idea.