Re: cheap - Anthropic’s write-up said it cost $20,000 of runs to find that bug (and a few others). So not that cheap compared to other tools - more similar in cost to human review/pentest, but probably more exhaustive.
> This was the most critical vulnerability we discovered in OpenBSD with Mythos Preview after a thousand runs through our scaffold. Across a thousand runs through our scaffold, the total cost was under $20,000 and found several dozen more findings.
They don’t talk about the other findings, so I’m guessing they are minor.
The proprietary/commercial TALA engine is really excellent too. I’ve been using it to do complex dataflow diagrams, and the results are so incredibly well laid out.
I guess. But it would only impact you if you’re using cookies with curl (I assume the middleware is only applied to requests with cookies?) — and it seems pretty easy to add a -H ‘sec-fetch-site: none’ in that case.
The article has a whole section about requiring those headers by forcing the use of TLS 1.3 — the theory being that browsers modern enough to support 1.3 are also modern enough to support the headers. But why not just enforce the headers?
Yes, in theory they are good. In practice they cause enormous amounts of pain and work for library maintainers with little benefit to them (often only downsides). So, many libraries don’t support them and they are very hard to adopt incrementally. I tried to convert a library I maintain to be a module and it was weeks of work which I then gave up and reverted. As one library author said to me “JPMS is for the JDK itself, ignore it in user code”.
Given how much of a coach and horses modules drove through backwards compatibility it also kind of gives the lie to the idea that that explains why so many other language features are so poorly designed.
Do you really think that in 26 years of professional Java programming I’d have never touched Spring? I’ve been using Spring since it was first released. I’ve found CVEs in Spring (https://spring.io/security/cve-2020-5408). Trust me when I say that my dislike for Spring (and annotations) is not based on ignorance.
> The first day I used it, Claude got stuck in a loop trying to fix a problem using the same 2 incorrect solutions again and again and burnt through $30 of API credits before I realized things were very wrong and I stopped it.
The worse it performs, the more you pay. That’s a hell of a business model. Will users tolerate that for long?
The improvements in programming are largely due to the adoption of “agentic” architectures. This is really a hybrid neural-symbolic approach: the symbolic part being the interpreter/compiler. Effectively the LLM still produces an almost-correct-but-wrong program and then the compiler “fact-checks” it and then the LLM basically local-searches its way from there to something that passes the compiler. (If you want to be disabused of the idea that LLMs on their own are good at programming, just review the “reasoning” log of one trying to fix a simple string | undefined error in Typescript).
It seems clear to me therefore that further improvements in programming ability will not come from better LLM models (which have not really improved much), but from better integration of more advanced compilers. That is, the more types of errors that can be caught by the compiler, the better chance of the AI fuzzing its way to a good overall solution. Interestingly, I hear anecdotally that current LLMs are not great at writing Rust, which does have an advanced type system able to capture more types of errors. That’s where I’d focus if I was working on this. But we should be clear that the improvements are already largely coming via symbolic means, not better LLMs.
This was before LLMs. It was a combination of unit and end-to-end tests and tests written to comprehensively test every combination of parameters (eg test this security property holds for every single JWT algorithm we support etc). Also bear in mind that the product did a lot more than just OAuth.
Thus creating a two-time pad, which is completely insecure…