Software security heavily favours the attacker (ex. its much easier to find a single vulnerability than to patch every vulnerability). Thus with better tools and ample time to reach steady-state, we would expect software to remain insecure.
If we think in the context of LLMs, why is it easier to find a single vulnerability than to patch every vulnerability? If the defender and the attacker are using the same LLM, the defender will run "find a critical vulnerability in my software" until it comes up empty and then the attacker will find nothing.
Defenders are favored here too, especially for closed-source applications where the defender's LLM has access to all the source code while the attacker's LLM doesn't.
That generally makes sense to me, but I wonder if it's different when the attacker and defender are using the same tool (Mythos in this case)
Maybe you just spend more on tokens by some factor than the attackers do combined, and end up mostly okay. Put another way, if there's 20 vulnerabilities that Mythos is capable of finding, maybe it's reasonable to find all of them?
"Most security tooling has historically benefitted defenders more than attackers. When the first software fuzzers were deployed at large scale, there were concerns they might enable attackers to identify vulnerabilities at an increased rate. And they did. But modern fuzzers like AFL are now a critical component of the security ecosystem: projects like OSS-Fuzz dedicate significant resources to help secure key open source software.
We believe the same will hold true here too—eventually. Once the security landscape has reached a new equilibrium, we believe that powerful language models will benefit defenders more than attackers, increasing the overall security of the software ecosystem. The advantage will belong to the side that can get the most out of these tools. In the short term, this could be attackers, if frontier labs aren’t careful about how they release these models. In the long term, we expect it will be defenders who will more efficiently direct resources and use these models to fix bugs before new code ever ships.
"
This is only true if your approach is security through correctness. This never works in practice. Try security through compartmentalization. Qubes OS provides it reasonably well.
Thunderbolt is its own protocol, electrically incompatible with PCIe. Its purpose is to encapsulate data traffic from multiple other protocols (PCIe, DisplayPort, USB) and multiplex that over the same wires. It cannot function exactly like an external PCIe port because it's solving a bigger, more complicated problem.
I am currently implementing S3, with correct error handling for edge cases. Its been about a month and I have almost the whole API surface done, with some gaps (you actually need a broader surface eg some IAM, KMS encrytion needs a persistence layer so only done sse-c so far). Close to the point where you could drop it in as a local emulation tool, its a sub 9MB binary (Rust).
Literally as I write this the AI code review said "suspended-bucket current-version selection is still wrong when the numbered version and the newer null version land in the same millisecond." - thats the level of detail you have to deal with.
Actually no, because they actually have to worry about their millions of customer deployments not randomly breaking every other week. So, they are generally very good about not breaking compatibility unless they have a really good reason to. And when they do, they typically give people years of time to deal with any backwards compatibility breaking changes. Because otherwise they are dealing with lots of support overhead and angry customers. That and the multiple independently developed s3 compatible clients or alternatives make this probably the easiest thing to simulate in the AWS universe as it is probably the most widely used thing in AWS.
Not really, the main thing they could change is the order in which errors are checked when there are multiple errors, but even a lot of that is not likely to change, eg html based stuff comes first. There are actual reasons for a lot of the subtleties, plus they have to have a stable contract for all the success cases as people rely on it. And its not hard to update, I have 800 or so tests against AWS that run in a few minutes.
reply