is it just me, or does the a. i. companies’ recent focus on automating exploit finding read as an “engage with us Or Else” ploy against the projects that wouldn’t take generated code contributions but can’t ignore security issues
-
is it just me, or does the a. i. companies’ recent focus on automating exploit finding read as an “engage with us Or Else” ploy against the projects that wouldn’t take generated code contributions but can’t ignore security issues
-
is it just me, or does the a. i. companies’ recent focus on automating exploit finding read as an “engage with us Or Else” ploy against the projects that wouldn’t take generated code contributions but can’t ignore security issues
@joe it's more "this is actually a thing it can do" i feel as fuzzing does produce results
but, well, after the burst of low hanging fruit, i don't expect a regular crop of bugs
-
@joe it's more "this is actually a thing it can do" i feel as fuzzing does produce results
but, well, after the burst of low hanging fruit, i don't expect a regular crop of bugs
@tef @joe They seem to avoid talking about solid defensive remedies (some of which LLMs likely will also be able to do well, such as translation and theorem proving — there are already results), for some reason. Until that strong medicine is applied, I think they'll continue producing new bugs and new kinds of bugs. Underestimating them is unwise for defenders. Keep in mind also they are military contractors.
-
is it just me, or does the a. i. companies’ recent focus on automating exploit finding read as an “engage with us Or Else” ploy against the projects that wouldn’t take generated code contributions but can’t ignore security issues
@joe it absolutely comes across as a protection racket
-
is it just me, or does the a. i. companies’ recent focus on automating exploit finding read as an “engage with us Or Else” ploy against the projects that wouldn’t take generated code contributions but can’t ignore security issues
@joe the "we found a local privesc in Linux" seemed particularly silly to tout... we have local privesc in Linux at home
-
@tef @joe They seem to avoid talking about solid defensive remedies (some of which LLMs likely will also be able to do well, such as translation and theorem proving — there are already results), for some reason. Until that strong medicine is applied, I think they'll continue producing new bugs and new kinds of bugs. Underestimating them is unwise for defenders. Keep in mind also they are military contractors.
-
-
is it just me, or does the a. i. companies’ recent focus on automating exploit finding read as an “engage with us Or Else” ploy against the projects that wouldn’t take generated code contributions but can’t ignore security issues
-
-
-
@tef @joe Which is: not fully true! Defenders get to define the territory, including audit and observability. Finding a vuln, developing an exploit — way too easy. Making it operational and maintaining the capability over time: somewhat to substantially more fraught. (Still way, way too easy, of course)
-
is it just me, or does the a. i. companies’ recent focus on automating exploit finding read as an “engage with us Or Else” ploy against the projects that wouldn’t take generated code contributions but can’t ignore security issues
@joe it’s finding real issues. Anything that finds real issues and costs money will feel like an “engage with us Or Else” situation
-
@joe it's more "this is actually a thing it can do" i feel as fuzzing does produce results
but, well, after the burst of low hanging fruit, i don't expect a regular crop of bugs
-
@pozorvlak @joe alas, "secure programing in C" turns out to be more than just yelling at linux developers
-
@pozorvlak @joe alas, "secure programing in C" turns out to be more than just yelling at linux developers
to be clear, if you believe openbsd has a lower defect rather than any other of the bsds, you're absolutely being taken for a ride
-
R relay@relay.infosec.exchange shared this topic
