RubyGems Open Source Supply Chain Security and OpenAI

Over the weekend it has been widely reported that OpenAI agents attacked RubyGems on May 11, 2026, two months before Hugging Face, including by mainstream wire service Reuters. The use of Artificial Intelligence frontier models both for good and for evil is happening now regardless of what any particular individual or company wishes were the case. In this case, OpenAI saying that it did not have the intent to perform the particular attack does little to show that its amoral agent (as in a computer system with no moral agency) did not pattern match and actually perform malicious activity. The bombshell report by Spencer Kitts, Thomas Larsen, and Sydney Von Arx, titled OpenAI agents carried out an undisclosed cyber-attack on RubyGems, covers it well that the agents: Attempted to steal RubyGems user API keys by exploiting a novel vulnerability in the RubyGems server Abused RubyDoc.info to execute arbitrary code Continued to use RubyGems in June 2026 As a company, we’re quite involved with RubyGems and security. We covered supply chain vulnerabilities in 2019 and made a typosquatting defense to the open source project itself as pull request Update GemTypo to use the -/_ variation detection - #2341. The RubyGems team did the best they could shutting down registrations, getting a handle on what was being submitted, and tightening security precautions. The introduction of untrustworthy packages and package variants is a continuing and escalating problem. For years I have taught the Six Pillars of Dependency Management, and the first of them, minimize dependencies during development, matters more now than it ever has. The crypto mining of the 2019 period is giving way to automated attacks where the models are driven towards their goals without the limitations of sleep or boredom with tedium. Budgets can be a factor, but the timeline is shrinking. Bruce Schneier reported today that tomorrow’s Microsoft’s Patching will include roughly “972 vulnerabilities fixed and 112 of them meeting the high critical-severity threshold.” He concludes this is a good example of AI helping defenders more than attackers. I disagree in part. Our own ActiveStorage incident data supports Mr. Schneier’s closing caveat that “AIs are also good at reverse-engineering exploits from patches, which means that these vulnerabilities will be weaponized as soon as the update is published.” Yes, it helps defenders long term but in the short term it is a weapon most are not ready for. It does not matter open or closed source in terms of automated vulnerability analysis. AI agents can execute binary decompilers and patch diffing as well as they can read open source code for analysis. Our current postures have been built with a now outdated threat model that looked at what a team of people with time and resource constraints could do. Our security is often built on a house of cards where the insecurity of any component can mean the exploit of the entire system. Cryptography is designed on the assumption that the adversary knows everything about the system except the key, a rule known as Kerckhoffs’s principle, and a few constructions are provably secure in that mathematical sense. This is not the case in production software, where our systems are not provably secure in a mathematical sense and yet that is the direction we will need to go long term. There is no hiding anymore and the defender is not awarded rest on the assumption that a human is not sufficiently motivated or lacks the time to look deeply into breaking our particular system. Their robot agent will do it for them. In the shorter term, if you thought you had a month or more to patch your production when a critical CVE is published impacting a publicly accessible system, think again. You have hours at most. All organizations have to process changes to match this reality on the ground.