He’s talking about AI scanning tools collectively, not specifically Mythos.
If you read his own top comment on that LinkedIn post he clarifies:
“The simple reason is: the (AI powered) tools are this good now. And people use these tools against curl source code.They find lots of new problems no one detected before. And none of these new ones used Mythos. Focusing on Mythos is a distraction - there are plenty of good models, and people who can figure out how to get those models and tools to find things.”
Wait, 11 vulnerabilities were discovered entirely in the timeframe after Mythos found 1? That seems like it would effectively debunk the theory that curl was so uniquely hardened that only 1 vulnerability even existed for Mythos to find, which I read numerous times back on the HN thread for the curl/Mythos blog post.
As one of those commenters on the previous post - yep, that theory appears to have been comprehensively trounced. Unless anything comes to light that mythos was applied poorly to curl, the evidence suggests that it’s not uniquely effective vs other AI-assisted approaches. I’ll be interested to see what’s reported in the next curl release.
Is it? It would be incredible if the government didn’t have specific requirements for critical infrastructure.
Say you’re an energy company and an incident could mean that a big part of the country is without power, or you’re a large bank and you can’t process payroll for millions of workers. They’re ability to recover quickly and completely matters. Just recently in Australia an incident at Optus, a large phone company, prevented thousands of people from making emergency calls for several hours. Several people died including a child.
The people should require these providers behave responsibly. And the way the people do that is with a government.
Companies behave poorly all the time. Red tape isn’t always bad.
# From a specific branch
gem 'my_gem', git: 'https://github.com/user/my_gem.git', branch: 'development'
# From a specific tag
gem 'my_gem', git: 'https://github.com/user/my_gem.git', tag: 'v1.2.3'
# From a specific commit (ref)
gem 'my_gem', git: 'https://github.com/user/my_gem.git', ref: 'a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0'
If supply chain integrity is the issue specifically for Shopify, couldn’t they run their own private, internally facing gem repository and whitelist everything that goes there? It’s not a requirement to use the public rubygems.
They probably thought it would be easier to takeover rubygems than ensure every dev and every machine for every possible ruby tool could be and is pointed at the internal gem repository.
Let's be paranoid for a moment. What if there's a supply side attack on a gem used by Homebrew. That's basically installed on every dev machine, auto-updates automatically/silently, could have sudo, that no one would care or even know how to point at a private gem repository.
I too am scratching my head at this. If the problem is the outside community could be a risk, just do not drink from the firehose. Have processes in place to slowly vet and bring the outside world indoors.
Then again, that is not a very web scale suggestion.
That's not what I said. I was responding to the parent comment's statement that "I’m assuming there’s a ton of reputational risk in this move" by noting that, in relative terms, this likely isn't something people are paying attention to outside a very, very narrow universe.
“1,000,000,000,000, i.e. one million million, or 1012 (ten to the twelfth power), as defined on the short scale. This is now the meaning in both American and British English.”
reply