• 0 Posts
  • 17 Comments
Joined 3 years ago
cake
Cake day: July 5th, 2023

help-circle

  • Yeah, the smarter way to use LLM-based agents is carefully defined tasks. Mozilla describes their vulnerability assessment processes in this blog post.

    Mozilla describes the process they’ve used: building a harness that instructs a model to find a specific category of vulnerability on a specific interface, and then write up its findings. It’s a narrow enough context that the model gets specific instructions, and a simple definition of success, and it sets up many such tasks that can be fed into the existing process for verifying and triaging bugs. Note that the output for this LLM pipeline basically feeds into the same interface for accepting bug reports from the public, or from their human contributors within the project.

    There’s a couple of takeaways here, too:

    • This pipeline is model agnostic. Mozilla set it up before Mythos was released, and its description of other models (Opus 4.7, Codex) confirms that Mythos is better but not a true game changer. The ability to swap out other models provides some assurance that the work done to develop the pipeline will be useful when cheaper or better models come along, or when a model becomes unavailable (like when a provider decides a particular model is too expensive to run, or a provider goes under).
    • The increase in automated output (and presumably automation-assisted contributions from the public) has given the humans more work to do. Automation in this context actually increases the demand for human labor.
    • Other projects will need to develop their own custom pipelines, specific to their project, to get good results from LLM based agents.

    There are ways to use these tools, but none of it really seems like a truly revolutionary/disruptive change to how large projects are managed.



  • One real concern I have is that there are now automated tools that can read a patch, and the maintainer’s release notes with a description of a security vulnerability fixed by that patch, and then create a working exploit of the pre-patch vulnerability.

    In that particular moment, you know that a vulnerability exists and that it was serious enough to be described in release notes, and you can compare two code versions, one that is secure and one that is not. From there, any AI coding agent is working towards something that definitely exists, with a bunch of description of what it might be.

    So that means that the window between when a patch is released and when users actually apply that patch is going to be more important than ever. Downstream maintainers will be under a lot of time pressure to implement changes from upstream, because every new security patch will create a race to create 1-day exploits for everyone using that software.








  • Jevon’s Paradox is that when there’s more of a resource to consume, humans will consume more resource rather than make the gains to use the resource better.

    More specifically, it’s when an improvement in efficiency cause the underlying resource to be used more, because the efficiency reduces cost and then using that resource becomes even more economically attractive.

    So when factories got more efficient at using coal in the 19th century, England saw a huge increase in coal demand, despite using less coal for any given task.