You must be more cautious about having both a secure design and a secure implementation of the design of your software at the earliest possible stage of software development. This increases the time and effort to discover a vulnerability or can close out entire classes of vulnerabilities. We have seen how massive projects are weighted down from development standards of the late 90s and 00s that makes them have thousands of CVEs every release.
https://www.phoronix.com/news/Linux-Kernel-CVEs-Nearly-2000
Check out some of the open-source AI tooling from Cellebrite to improve their workflows and automate in researching mobile device vulnerabilities.
https://github.com/cellebrite-labs/ghidra-rpc
https://github.com/cellebrite-labs/ida-bridge
https://github.com/cellebrite-labs/ida-docs
https://github.com/cellebrite-labs/ida-porter
You can have opinions on the issues of LLMs (and I have several), but that comes with having to accept an adversary is accelerating how to harm you with that technology.
quotingYou can see the individual pull requests for how many people have worked on the app and that there's people discussing what to do. There's people involved in every step or the development testing for quality. Here's the largest:
nevent1q…ehec
https://github.com/GrapheneOS/Messaging/pull/109
The leading apps dev has around a decade and a half of experience in developing on the Android platform alone. His contributions so far have been incredible.
We have a broad access to many LLMs for security testing, including cyber-enabled models for dual-use. It's not actually writing the code of GrapheneOS much. It would be poor to willingly dumb ourselves down when companies such as Cellebrite are devoting teams to creating AI tooling to reverse engineer mobile devices to try and exploit them.