The problem with Mythos and Glasswing related hype is that finding vulnerabilities isn't the problem for most organizations. It's great that Mythos and similar models can find vulnerabilities that remained undetected (and hopefully unexploited) for years. That's valuable, especially in open source projects, but it's never been the real challenge for software companies.
The real problem is balancing the need to fix vulnerabilities with the mandate of shipping new products and features. At every organization I've worked for or with, this has been the natural friction point. That's good: Product should make customers happy, and Security should keep the customers and their data safe.
Ultimately, the whole business should share these goals: everyone should strive for a resilient, useful product shipped quickly that delights customers. Easier said than done, but the friction should be tactical ("how do we spend engineering resources?") rather than strategic ("are security fixes important? do we care?").
Which is why I'm much more interested in automated (or semi-automated) PRs to actually fix discovered vulnerabilities rather than just identify them. But, as this project implies, it's not always that simple. It's easy to fix vulnerabilities if you don't care about breaking other functionality.
In my opinion, it's currently still necessary to have a human developer in the loop to make sure functionality in product is maintained, and potentially security in the loop to make sure the vulnerability is actually fixed and not just obfuscated.
Once this technology is sufficiently advanced -- and I think we're getting close -- my hope is that developer and security time will be spent thinking about resilient software design and architecture, not code-level vulnerabilities.
The problem with Mythos and Glasswing related hype is that finding vulnerabilities isn't the problem for most organizations. It's great that Mythos and similar models can find vulnerabilities that remained undetected (and hopefully unexploited) for years. That's valuable, especially in open source projects, but it's never been the real challenge for software companies.
The real problem is balancing the need to fix vulnerabilities with the mandate of shipping new products and features. At every organization I've worked for or with, this has been the natural friction point. That's good: Product should make customers happy, and Security should keep the customers and their data safe.
Ultimately, the whole business should share these goals: everyone should strive for a resilient, useful product shipped quickly that delights customers. Easier said than done, but the friction should be tactical ("how do we spend engineering resources?") rather than strategic ("are security fixes important? do we care?").
Which is why I'm much more interested in automated (or semi-automated) PRs to actually fix discovered vulnerabilities rather than just identify them. But, as this project implies, it's not always that simple. It's easy to fix vulnerabilities if you don't care about breaking other functionality.
In my opinion, it's currently still necessary to have a human developer in the loop to make sure functionality in product is maintained, and potentially security in the loop to make sure the vulnerability is actually fixed and not just obfuscated.
Once this technology is sufficiently advanced -- and I think we're getting close -- my hope is that developer and security time will be spent thinking about resilient software design and architecture, not code-level vulnerabilities.
We'll see where it goes.