When you pay for anything you basically exchange money so that someone else take care of a problem you have. Obviously if you are paying you expect the result to be of good quality. Software is no different, AI won't change that fact and engineering is about creating robust solution at the cheapest price. Just my 2 cents.
The app automated pentest scanners find the bottom 10-20% of vulns, no real pentester would consider them great. Agents might get us to 40%-50% range, what they are really good at is finding "signals" that the human should investigate.
I agree with you about scanners (we banned them at Matasano), but not about the ceiling for agents. Having written agent loops for somewhat similar "surface and contextualize hypotheses from large volumes of telemetry" problems, and, of course, having delivered hundreds of application pentests: I think 80-90% of all the findings in a web pentest report, and functionally all of the findings in a netpen report, are within 12-18 months reach of agent developers.
I agree with the prediction. The key driver here isn't even model intelligence, but horizontal scaling. A human pentester is constrained by time and attention, whereas an agent can spin up 1,000 parallel sub-agents to test every wild hypothesis and every API parameter for every conceivable injection. Even if the success rate of a single agent attempt is lower than a human's, the sheer volume of attempts more than compensates for it.
They also don't fatigue in the same way humans do. Within the constraint of a netpen, a human might be, say, 20% more creative at peak performance than an agent loop. But an agent loop will operate within a narrow band of its own peak performance throughout the whole test, on every stimulus/response trial it does. Humans cannot do that.
Honestly I'm just trying to be nice about it. I don't know that I can tell you a story about the 90% ceiling that makes any sense, especially since you can task 3 different high-caliber teams of senior software security people on an app and get 3 different (overlapping, but different) sets of vulnerabilities back. By the end of 2027, if you did a triangle test, 2:1 agents/humans or vice/versa, I don't think you'd be able to distinguish.
I see this emoji thing being mentioned a lot recently, but I don't remember ever seeing one. Granted I rarely use AI and when I do it's on duck.ai. What models are (ab)using emojis?
I'd say I agree with you there for the low-hanging fruit. The deep research (there's an image filter here but we can bypass it by knowing some obscure corner of the SVG spec) is where they still fall over and need hand holding by pointing them at the browser rendering stack, specs, etc
It doesn't even need to be trained. Just feed parts of the spec. I found some interesting implementation edge cases just by submitting the source and pdf spec of a chip to Claude. Not even in a fancy way.
Bootstrap founder in that field. Fully autonomous is just not there. The winner for this "generation" will be with human in the loop / human augmentation IMO. When VC money dries out there will be a pile of autonomous ai pentest compagnies in it.
Yes because all the valuations right now are based on a bet that this will replace a huge chunk of the service/consulting budget toward an AI budget for pentest. This will not happen.
I have no stake in this market, but: human-in-the-loop AI-mediated pentesting will absolutely slaughter billable hours for offensive security talent. Hell, if Fortify and Burp Scanner were actually good, you wouldn't even need the last few years of LLM advancement to accomplish that; the problem is that current automation is not very good. LLM-augmented automation happens, as a weird quirk of fate, to be almost laser-guided at the weaknesses of that technology.
That markets been slaughtered for a while. Pretty much every big tech company has built up strong internal security teams and automated as much as possible. Look up what happened to NCC Group post Matasano acquisitions, I joined within a year of the isec/matasano/intrepedus acquisitions and saw a slow ride down. After 5 years the rate was still $2500 a day and everyone with real talent left to internal teams for much much higher pay. NCC Group is now a scan shop operating out of the phillipines, I still have one friend that works there from the isec days! The exception being some leet places like Trail-Of-Bits.
Late-period NCC doesn't look great. But I've been a buyer of these services for the past 5 years (a seller, of course, for the 15 years leading up to that) and rates have not gone down; I was shocked at how much we ended up spending compared to what we would have billed out on comparable projects at Matasano.
I don't know enough about the low-end market to rebut you there (though: I saw what my muni paid for a bargain-basement assessment and was not OK with it), but the high end of the market definitely has not been slaughtered, and I definitely think that is coming.
Yes and no, it will kill the "I ran a nessus scanner and charged you 8k for it" kind of pentests but not the core of the service market IMO. Pentesters will be more efficient so I guess this could be considered a slash in hourly rate if they kept the same pace. LLM are good at getting signals but actual hacking it is still meh.
Juniors will have a hard time that I agree. The current level of findings of LLM is at their level.
I disagree with you about the first paragraph but have to say that, distinctively to the security and the services markets, you can't say "juniors will have a hard time of it" without also saying "this is going to fundamentally disrupt services budgets". The two statements mean the same thing.
Exn looks very interesting, but to be actionable we need a compatibility layer with thiserror and anyhow since most are using it right now. Moving the goalpost a little we mostly need a core rust solution otherwise your error handling stops at the first library you use that doesn't use exn.
`thiserror` helps you define the error type. That error type can then be used with `anyhow` or `exn`. Actually, we have been using thiserror + exn for a long time, and it works well. While later we realize that `struct ModuleError(String)` can easily implement Error without thiserror, we remove thiserror dependency for conciseness.
`exn` can use `anyhow::Error` as its inner Error. However, one may use `Exn::as_error` to retrieve the outermost error layer to populate anyhow.
I ever consider `impl std::error::Error` for `exn::Exn,` but it would lose some information, especially if the error has multiple children.
`error-stack` did that at the cost of no more source:
Because it used to be the "best" dating app out there for "serious" people wanting long term relationships. Now all the apps are trash and have predatory monetization.
Correct, I was reading a very interesting blog post [1] on how the rust compiler will change the LLVM annotaions like sending noalias for mutable pointer. This changes a lot the generated machine code. Disabling the borrow checker won't enable those LLVM flags.
Cursor has been annoying me lately with their updates breaking ever further away from vscode UI. Might give copilot another shot. Needs a plan mode though, it really is necessary for complex operations.
Another one that is missing in the article is &raw mut/const but it is purely for unsafe usage when you need a pointer to an unaligned field of a struct.
&raw T/&raw mut T aren't pointer types, they're syntax for creating *const T/*mut T.
These aren't included in the article because they are not borrow checked, but you're right that if someone was trying to cover 100% of pointer types in Rust, raw pointers would be missing.
I'm hoping that languages move away from the sigil-ified legacy of C treating pointers as special syntax and just start calling these `Ref<T>`, `PtrConst<T>`, etc.
I am sure why people are so terminally online to care about this. Like Rust for Linux is also here to stay and we can expect that in 10-20y a large portion of the kernel will be in Rust. Obviously the post was boasting, it was meant as a recruitment ad. They actually probably got a few decent candidates from it.
Adding rust to the kernel makes sense. Porting a million lines of code per engineer month is insane, regardless of language (it works out to ~600ms per line total, including review, testing, etc). Anyone who heard about that expectation and thought it sounded good is the opposite of decent candidate.
It has been approved as the same standing as C and assembly, it is there to stay despite what the haters say [1]. Linus is behind the push and for good reasons. Android keeps demonstrating year after year the benefits, at some point I don't know what else to say.
Just because something is beneficial does not mean it will be taken up by the community. My question is (and that is what I'm most interested in atm) what makes Rust's adoption inevitable? Are there people paying to make that happen? Are kernel level security bugs that big of a concern now that migrating to Rust is a pressing issue? Do you see what I mean?
(Again, just to clarify my comment: I'm not challenging anyone. It's just that there are hundreds of programming languages out there. Rust's been around for a good while. So, why now? And circling back to my original question, what makes its adoption inevitable?)
I think fundamentally it's because it's a better language than C and more pleasant to write.
Sure there will be a lot of old codgers who don't want to learn new things (surprisingly common in the tech industry), but eventually they'll retire or die, and new kernel devs will be very unlikely to pick C over Rust.
The security thing is definitely a driving force but I think probably not that much just compared to how much easier and more pleasant it is to write correct Rust than correct C (in most cases).
Absolutely. If Linus had said "Rust for Linux might go away" then you would have said "See! The creator and leader of Linux says Rust is going to go away!" but because he said it is here to stay you're saying "Pff, Linus isn't that important."
I won't quit my day job to become a detective because actual detective work isn't this trivial.
Do you think everyone you speak to online is this misinformed or has these takes?
I’ve read and listened to enough of Linus to know he says this himself. The Linux kernel is nothing without the maintainers, this is easily observable and everyone knows it.
You see the reason you shouldn’t go into detective work is because you’d be terrible at it, not because it’s non-trivial.
Hey let’s not put the Rust fanatics in the same bucket as the LLM bros. One is a safe programming language, the other is an overgrown lorem ipsum text generator. We’re not the same :)
reply