Two decades ago this August, AWS – itself four years old at that point – launched the Elastic Compute Service, or EC2. Between that and the earlier March release of their Simple Storage Service (S3), Infrastructure as a Service (IaaS) – more commonly referred to as primitives these days – was born. Within a year it was an emerging force. Within five it was an eight hundred pound gorilla in market, reshaping the industry around it.

While it’s often forgotten now, there was a competing vision for the cloud almost from the start. Heroku was founded in July of 2007. Salesforce introduced Force.com in September of ’07, and Google followed with App Engine in April of ’08. These platforms and others that followed became a new category called Platform as a Service (PaaS). PaaS was positioned as a simpler alternative to IaaS. Instead of having to pick the building materials to host an application, one simply deployed it and left the rest to the platform.

Of these two potential approaches that emerged two decades ago, IaaS won.

There were many reasons for this. For one, IaaS looked much like what enterprises in particular were used to: compute instances were servers, storage was storage and so on. PaaS, by contrast, was somewhat alien. It didn’t look like what came before it. It was, instead, a black box that couldn’t be taken apart and inspected. Developers didn’t necessarily care about that opacity, but their employers did.

PaaS also necessarily involved tradeoffs. Building with the primitives of IaaS, enterprises could construct virtually anything from websites for strip mall petstores to high speed trading platforms. PaaS, by contrast, was only appropriate for a subset of workloads due to constraints either cost, technical or both. Being a general purpose platform in a world of highly specialized applications is a challenge.

The technology industry landscape, therefore, was dominated by primitives for nearly two decades. And from an adoption and spending perspective, it still is.

But the market has also changed in recent years. A few key factors:

• First: the number of available primitives multiplied. As such, it traced a parabola of utility. Initially, as the number of available primitives increased, the platforms usefulness increased in direct proportion. More primitives meant more possibilities. At some point in the last decade, however, it hit the down arc of that parabola and started declining in its appeal, with the ever expanding array of services transitioning from toolbox to burden. Six years in, the Developer Experience Gap remains an issue.

• Second: the PaaS core approach was reconsidered. If PaaS originally failed to achieve real scale in its adoption in part because of its general purpose focus, what if ambitions were narrowed and the platform were to target a particular workload or set of adjacent workloads? A specialized platform for a particular task is much more achievable than a Jack of All Trades. This realization has triggered a wave of market innovation in less generalized, and more specialized providers.

• Third: the rise of coding assistants is dramatically accelerating the number of applications created, and as a consequence, lines of code being deployed. It is at the same time gradually putting more distance between developers and the construction and deployment of the application itself. Not just with code creation – which will at times involve programming languages the developer has never learned – but from the underlying infrastructure. In more and more cases, technology selection is being delegated to coding assistants, and left to their own devices those coding assistants have a preference for abstract platforms, platforms that might once have been termed PaaS.

Given these and other factors, the market for abstractions that sit above the original primitives of IaaS has both fragmented and grown. To be clear, IaaS – or primitives, today – remains the dominant approach and will for the foreseeable future.

But the more complicated infrastructure becomes, the more appetite there is for simpler alternatives. Especially if the virtual, 24/7 pair programmers ubiquitous today are putting their proverbial fingers on the scale in favor of abstractions because they’re easier to programmatically manipulate and require less explanatory context (and thus fewer tokens).

All of which explains the great unbundling. In response to developers and enterprises seeking abstractions but frustrated with limitations of general purpose platforms for their workload of choice, a diverse array of different tools emerged to attack different problems via specialized abstractions sitting above primitives. A few rough categories have emerged.

• AI app builders (“vibe coding”): (e.g. Bolt.new, GitHub Spark, Lovable, Replit Agent , v0). App writes the code, and increasingly determines the hosting and backend too.
• General-purpose PaaS (“Heroku-like”): (e.g. Cloud Run, Fly.io, Render, Railway). Code written independently, deployed to abstract servers/containers/scaling.
• Front End: (e.g Cloudflare Pages/Workers, GitHub Pages, Netlify, Vercel). Code written independently, abstracted hosting/CDN/edge.
• Backend-as-a-service: (e.g. Convex, Firebase, Supabase). More than just DBaaS primitive: abstracted DB + auth, storage and other pieces.
• Internal Developer Platforms: (e.g. Backstage, Crossplane, Humanitec, etc). Highly specialized, internal developer-focused platform.

There are caveats to the above categories, of course. Some products belong in multiple categories. In other cases the lines in between individual categories can be less than distinct, as with the app centric examples. The reverse can be true as well, with some categories having little in common: see IDPs vs BaaS as one example.

But in an effort to understand how, where and how quickly the market for abstractions above underlying primitives is growing, we’ve been tracking over 70 projects – a number which will undoubtedly grow by the week, if not day. Their breakdown is here:

Unsurprisingly, the second largest category, and category with the longest history, is general purpose app PaaS platforms, topped only by – what else? – AI. The list makes rough subjective judgements about which are core to the market, somewhat adjacent, possibly dead (watching) and excluded (dead or disqualified for one reason or another). From a macro perspective, however, what the list demonstrates – along, arguably, with Heroku’s deprecation – is that the days of a one size fits all abstraction are over for the time being.

The unbundling has inevitably come for PaaS, just as it once did for databases in the first decade following the millennium. What’s equally inevitable – again, just as it was with databases – is that the unbundling will ultimately give way to bundling. Bundling which arguably has already started. A few examples:

• Convex Chef: from BaaS to app builder
• GitHub Spark: from front end to app builder
• Lovable Cloud: from app builder to PaaS
• Replit Agent: from PaaS to app builder
• Vercel v0: from front end to app builder

This is a market at work. Bundled product limitations are identified, unbundled products tactically attack them. The survivors then turn their eyes towards adjacent unbundled markets in search of growth. Normally this is a process that takes time; it took the database market well over a decade to fragment with the rise of NoSQL only to return to the multi-workload databases in demand today. It’s not clear that timeframe will hold here, though.

Consider the list of collisions above. It took seven plus years for Vercel (née Zeit) to introduce v0. It took Replit a little over 8 years to get to Agent, and GitHub over 15 to get to Spark. But those were companies founded, at the latest, in 2016. The newer market entrants tell a different story. Convex reached out of market in a little less than three years; Lovable took ten months.

Perhaps most importantly, in the aggregate, all of the above transformations took place within a 25 month window.

Between this re-bundling of previously distinct workloads, then, and the pragmatic reality that market will not support near two dozen large platforms let alone the new options arriving by the day, it seems reasonable to expect consolidation in the market for abstractions, and soon. The growth opportunities for the winners, however, should be substantial.

Disclosure: Cloudflare, GitHub, Google (Cloud Run/Firebase), Heroku (Salesforce) and Render are RedMonk clients. Bolt, Convex, Crossplane, Fly.io, Humanitec, Lovable, Netlify, Railway, Replit, Spotify (Backstage), Supabase and Vercel are not currently customers.

In addition to being an important specialty runtime for enterprises, then, it was load bearing infrastructure for AI companies large and small.

Load bearing or no, its commercial prospects at the time of the acquisition – like so much of the open source the industry relies on, unfortunately – were less than clear. This Q&A from Jarred Sumner’s acquisition announcement was blunt:

Q: Is the same team still working on Bun full-time?
A: Yes. And now we get access to the resources of the world’s premier AI Lab instead of a small VC-backed startup making $0 in revenue.

On the whole, the acquisition was fairly straightforward for both parties. Bun receives an immediate capital return and a viable, long term path for support, while Anthropic gains direct control of a project strategic to their offerings. By going the inorganic acquisition route, it spent money to save time in a market with plenty of the former but precious little of the latter. Curious about how the project has fared post-acquisition, we’ve evaluated some of its metrics.

The high level takeaway is that the acquisition does not appear to have slowed the project. The below chart drawn from npm is merely a subset of Bun installs, and doesn’t reflect those installed directly, via Homebrew, binary or otherwise. Even the subset we’re able to access here tells a clear story however.

It is necessary to caveat the above and similar charts by observing that it’s difficult to precisely tease apart Bun’s success from that of projects that leverage it like Claude Code. Still, growing 16X from 445K/month to 7.3M in less than 30 months is impressive for a runtime in a field full of them. And if the runtime growth sounds impressive, the TypeScript type definitions for it are even more impressive – bun-types (the first party native definition) grew at 53X while its TypeScript wrapper jumped 234X.

Bun is growing, in other words. It may even be growing faster post-acquisition. But the question is: how sustainable is that growth? To answer it, it’s necessary to look under the hood at how the project is being built, by whom and how that’s changed over time. There are many different conclusions to be drawn from the resulting datasets, but there are two particularly worth highlighting.

AI and Bun

As has been discussed elsewhere, the most obvious takeaway in looking at Bun’s commit data is the glaring transition from primarily human to primarily AI contributions. This is certainly no secret; a month ago, Sumner said on Twitter:

“We haven’t been typing code ourselves for many months now. Even pre-acquisition this was pretty much accurate.”

The commits chart confirms this.

As early as last August, over half of the project commits at a given time were authored by a bot. Post-acquisition, it’s rarely less than that, and has peaked north of 80%.

Here are the total commits per month, AI vs human.

The trend line here is unambiguous: in approximately 12 months, Bun has transitioned from a project maintained by humans to one primarily authored by machines. To break that out in a little more detail, here are the commits per contributor: AI, but splitting up internal and external contributors.

We’ll get to the secondary trend there momentarily, but again, the conclusion is unavoidable. Just as Bun is core AI infrastructure, AI is now the core contributor to Bun.

This raises a host of questions that for the most part can’t be answered yet. How maintainable will the project be over the long term? What if any tech debt and learned helplessness is being accrued by the Bun team by relying so heavily on AI? Will AI continue to increase its percentage of code committed at the expense of humans, or will a natural equilibrium evolve over time?

It’s been barely a year of AI contributions, and half that as employees of one of the most visible and important AI companies on the planet. We won’t and can’t know the answers to these questions for some time, because the sample is insufficient.

But it seems clear that when looking at how core infrastructure products might be impacted by rising AI contributions, Bun will be an important datapoint to monitor.

Open Source and Bun

Arguably more interesting than “project includes more and more code written by machines” is what the acquisition means for Bun as an open source project. Bun was and is MIT licensed, and the acquisition announcement made four related promises around the project:

• Bun stays open-source & MIT-licensed
• Bun continues to be extremely actively maintained
• The same team still works on Bun
• Bun is still built in public on GitHub

Three of those promises have undeniably been kept. Bun remains open source and MIT licensed. It is actively maintained, and built on GitHub. The team, on the other hand, appears to have gone its separate ways.

First, let’s look at a macro picture of the number of human contributors to the project, total, in the wake of the rising AI contributions.

That number is roughly half of what it was. The number of external contributors, for its part, has dropped off significantly.

Just as the number of human developers big picture has declined, so too has the number of external developers.

To put that in context, however, while their numbers appeared to be more robust, the actual code contributions from external contributors has always been relatively modest – even acknowledging the problematic nature of measuring actual contributions by commits.

After dipping immediately post-acquisition, internal commits have climbed back into the same rough number they occupied prior. External commits, however, have not. Their contributions have significantly declined. This is unsurprising. Contributing to a project maintained by a small, independent startup is a different matter than one maintained by a large, well capitalized AI juggernaut.

Getting back to the original promise of keeping the team together, we can see the above metrics manifested in a detailed list of the original committers.

Of ~7 identifiable pre-acquisition Oven employees, at least 4 have clearly departed or at least stopped contributing. Another active committer went from 745 pre-acquisition commits to 1 post-acquisition. There are many potential reasons for this mini diaspora, and they may have little if anything to do with the project, AI, the acquisition or any of the above. The motivation, interest – or permission – to work on a large open source project can change for a variety of reasons.

But it is certainly not the same team that originally built Bun. Humans left, AI has moved in – whether that replacement cycle was deliberate and intentional, or not.

The Net

The fact that the number of human contributors to Bun is down while the number of machine contributions up would be less interesting if it wasn’t a relatively high profile open source infrastructure project. It’s unclear how Anthropic will navigate its stewardship of the project moving forward, or whether in fact they care about their role as project steward. Bun is an opportunity to ask questions of Anthropic: how does it value open source? What are its intentions for the project?

Consider the case of another open project out of Anthropic, MCP. First launched in November of 2024, consensus within three months was that it was a clear industry standard – which is an absurd, unprecedented timeframe. It was difficult, even shocking, to be told by competitive vendors that they were effectively granting this status to MCP the January after a November release.

In spite of this early and unprecedented success, it took another ten months for it to be donated to a neutral foundation. For the unfamiliar, this is a necessary step for standardized technologies that will be jointly developed by otherwise fierce competitors. Few if any commercial organizations will contribute to a project solely owned by a third party because it’s tantamount to subsidizing their development with your labor.

To be fair, this timeframe is not totally unreasonable. Kubernetes likewise took thirteen months from initial release to donation. But Kubernetes was also one amongst multiple competitive container orchestration projects, and very far from an obvious industry standard at the time. The delay and ultimate donation, then, was appropriate and strategic. MCP was a much more obvious candidate for standardization, however, earlier even than Docker, the most rapidly adopted technology we’d seen up until MCP. But it still took over a year for an obvious open source standard to be permitted to ascend.

Which begs the question: where is Anthropic, and its counterparts like OpenAI, on the corporate open source maturity curve? Startups understand open source code as consumers because they are built on it. They generally understand contributions, governance and the like because they have to. But as a rule, startups focused on moving as quickly as possible are far less familiar with how open source works on a corporate or enterprise level.

Not that Anthropic stands out in this regard. Microsoft spent decades verbally assaulting open source. Google’s early years were marked by publishing open papers about software without releasing the code behind them. And AWS’ reputation amongst open source communities was arguably worse than Microsoft’s until relatively recently when it learned to more peacefully coexist and contribute back.

These vendors and those that preceded them have had to learn about open source on a macro, rather than micro-scale. About license choices, the role of foundations and how to run open source projects that encourage rather than discourage external contributions – as well as the benefits of same.

An argument that could be made is that Anthropic won’t have to learn these lessons because it doesn’t need to standardize Bun. Certainly any flow of would be external contributions to the project from competitors is arguably now coming from AI. Why bother amortizing development costs across competitors and giving up control of a project to a foundation when the project’s owner has a bunch of software genies in a bottle that it can release at any time?

That assumes, of course, that the primary value resulting from the standardization of a project is code contributions. Which is a fundamental misunderstanding of the purpose of standardization. External code contributions are not the primary incentive to donate a project to a foundation: preventing needless and unproductive market fragmentation is. As is reassuring potential users. Enterprises, for one, do not embrace software from a foundation because it’s written more quickly. They do so because they prefer their key infrastructure not be controlled by a single vendor.

In any event, those curious about whether and how well Anthropic understands open source would be well served by watching their stewardship of Bun and how it evolves over time. The project, to its credit, is growing apace even as it’s hosted at a non-neutral single party. But assuming it’s a priority, and that Anthropic has ambitions for Bun to be more than a project that just undergirds Claude Code and its offerings, that growth is likely to be challenged by questions about stewardship and long term project futures. If that growth, meanwhile, is not a priority, and Anthropic has no intentions for the project to be more than just a piece of internal infrastructure, it will have negatively impacted its open source reputation as a poor steward of a popular project. Does Anthropic and their highly capable software creation machine, then, take on the world alone? Or do they trade some control for wider, swifter adoption?

How that question is answered, and whether Anthropic carries forward Bun’s wider mission or abandons its external users and turns inward, will tell us much about how quickly Anthropic is moving along the open source learning curve, and how much it has learned from the companies that have gone before it.

Disclosure: AWS, CircleCI, Docker, GitHub, Google, Microsoft and Salesforce (Slack) are RedMonk customers. Anthropic, Cursor, Figma, Lovable, OpenAI, The New York Times and Windsurf are not currently customers.

The term “open source” was coined in 1998, at least in part, because the term that preceded it was unclear and required explanation. Free software was descriptive and understood within technical communities familiar with it, but misleading to newcomers who understood free in commercial rather than philosophical terms. It was clear, in other words, that a new descriptor was required, and open source was the result.

Two years after the introduction of a proposed definition for open source AI, adoption has been minimal and there is an increasing awareness that unlike with pure source code, the assets that make up an AI model cannot be reduced to a single, binary open and closed definition.

It’s not that the licenses and promises of open source as they pertain to source code are simple. They can be complex, nuanced and difficult to explain. But they are, at least, that binary. Code is either open source or it’s not. By contrast, it’s now clear that open source AI – of which code is only a small part – is going to have to be defined along a spectrum from closed to open.

The G7 nations – with input from parties like the OSI – apparently concur. Their paper published this week, “G7 Vision on AI openness opportunities and shared language,” has several important takeaways. Among them:

• First, it clearly and unambiguously states that both open source and AI openness have immense societal benefits. It calls the latter, in fact, “an essential contributor to our economies.”

• Second, it acknowledges the risks and potential future harm that can result from the lack of clear, consistent definitions. “This lack of clarity in the field of AI tends to cast doubt on the degree of openness of such technologies, thereby undermining their benefits.”

• Third, it explicitly rejects a strict open or closed definition – “the openness of an AI is not binary.”

• Fourth, it implicitly rejects existing definitions – “the meaning of Open-Weight or Open Source AI remains contested.”

• Lastly, it proposes a four tier system for categorizing AI projects that sit along a spectrum of open.

The proposed classifications are similar in some respects to existing attempts like the Linux Foundation’s Model Openness Framework. Both are built for a landscape in which projects will differ in what specifically is made available, the terms its made available under and what restrictions, if any, are placed on use. But where the MOF is quite granular, grading projects around 17 components across an entire development lifecycle, the G7 vision is simpler. It defines four tiers based on five components (weights, deployment code, training code, training data and use restrictions).

In rough terms, those tiers can be described as follows ranging from most open to least:

• Open Source AI with Open Data: everything is open and under an OSI license – code, data, weights, every asset.
• Open Source AI: what’s available is open, but it may or may not include training data, though it must include full training code.
• Open Weights AI: weights and code are available and under an OSI license, but nothing else.
• Weights Available AI: weights and code are available and open for inspection, but are released under a license which cannot be called open source due to use restrictions or other prohibited limitations.

It remains to be seen whether or not the industry can adapt to a definition of open that depends on a sliding scale rather a fixed yes/no. But it also doesn’t have a choice. Two years of development and discussion and two years of living with a proposed definition have gotten us no closer to an industry consensus. Subtly, however, what the G7 nations have done with this document intentionally or unintentionally is to both acknowledge that fact, make it irrelevant and implicitly propose their alternative.

The challenge for any single definition of open source AI is that it is not possible to please both definition purists and definition pragmatists. The former point out that any definition that allows for any omission of training data is effectively granting the term open source to a project that cannot ever be independently replicated. Which is legitimate. The latter, on the other hand, point to issues with datasets ranging from the byzantine nature of data licensing to the sheer impracticality of the size of these datasets. Which are also legitimate. You can please one of these groups about an open source definition, but not both.

What the G7 is proposing serves as a recognition that that debate is a lost cause. Instead, for all intents and purposes, the G7 is proposing to deprecate the term open source AI in favor of open weights.

It is true, on the one hand, that there are not one but two different tiers in the G7’s framework that explicitly cite the term open source. So the deprecation is not literal. There is a definition of open source AI in existence.

But if no major competitive models can satisfy that definition, does the definition matter?

Two weeks ago, we surveyed a large, representative sample of relevant models. Since then we’ve added a few new models to track. A quick survey of the licensing terms for this sample are suggestive. 28 of the surveyed models are closed, and thus irrelevant in a discussion of openness. Of the 40 remaining in our sample, half are Weights Available AI (non-OSI license) and half are Open Weights AI (OSI license). Which in turn means that none are Open Source AI and none are are Open Source AI with Open Data.

To be clear, there are borderline cases: IBM publishes detailed training documentation and methodology, but not the code. Meta has released fine-tuning recipes and scripts (llama-recipes) alongside Llama, but again not the code. Deepseek, meanwhile, arguably went furthest, providing reinforcement learning training code and distillation scripts – but not the full pipeline. None of these, therefore, are considered open source AI by the G7’s definition.

Outside of our sample, meanwhile, there are models that provide data, code and weights: AI2’s OLMo and EleutherAI’s Pythia most notably. But they aren’t particularly competitive with the selected open and closed models tracked here and thus are not considered.

Put simply, the G7’s proposal at once codifies the open source AI definition while simultaneously making it irrelevant. Open weights becomes the de facto term of art, then, by default – at least until such time in future that truly open source models become more competitive. Instead of blurring the definition of open source AI to meaninglessness, a new, more descriptive term in open weights seeks to mitigate the shortcomings of its predecessor – much as open source itself once did for free software.

It is not clear whether even an august body like the G7 can compel adoption of their proposed framework, and there are questions about who should be defining industry terminology: governments, or industry bodies? But if this effort is successful, and the term open source is effectively relegated to just describing source code, that could be the best possible outcome. Vendors who wish to benefit from the halo of open can do so with a term separate and distinct from open source, and thus one insulated from contamination from use restrictions, lack of training data and other issues that would violate the original spirit and intent of the open source definition.

In past debates between open source purists and pragmatists, the latter would frequently argue that a definition of open source that was too strict would never be used.

The mistake all along may have been assuming that that was a bad thing.

Disclosure: neither the G7 nor the OSI are RedMonk clients.

Over the past 12 months, vendors across cloud-native infrastructure have converged on the same conclusion: the market wants image hardening. Docker went GA with Docker Hardened Images last May, then made the whole catalog free and open source in December 2025. In July, Broadcom’s Tanzu division launched Bitnami Secure Images. Chainguard built its Assemble 2026 conference in March around the same theme. Google Cloud Next 2026 put Wiz, now part of Google, front and center with WizOS leading the security story with its hardened container base images. On May 12, Red Hat used its Summit keynote slot to GA Red Hat Hardened Images. A week later at Open Source Summit North America, Edera and Minimus announced a partnership bundling hardened images with hypervisor-level workload isolation.

So, what’s going on here? If you ask my colleague James Governor he would likely point you to his LinkedIn post from last year where he wrote “talking to Chainguard. dear lord they’ve apparently established a license to print money”—a sentiment he then expanded into a blog post. But in addition to the possibly obvious financial motive, it is worth exploring this exploding market for hardened images in light of rapidly improving LLMs. Container base images create a centralized supply chain risk surface, yet the inherited vulnerabilities they introduce are often pushed downstream to developers who have little practical ability to remediate them—thus, the need for subscription-based solutions.

So let’s talk about image hardening in 2026. Why hardened images blew up, why images don’t come pre-hardened, and why developers are paying attention.

What does “hardened” even mean?

When practitioners say “hardened image” in 2026, they usually mean a number of properties mapping closely to what the major security-standards bodies have been recommending for years. The foundation is a minimal base, often distroless, so there’s no shell, no package manager, and little else for an attacker to live off. This is the oldest and least controversial piece: NIST’s container security guidance, SP 800-190 recommends base layers be minimalistic distributions with the OS kernel omitted, noting that a stripped-down image yields a much smaller attack surface with fewer opportunities to attack and compromise it. On top of that base sit a handful of runtime hardening defaults: a non-root user, and a read-only root filesystem where the workload allows. Both trace back to the same NIST guidance, which calls for least-privilege execution and describes the read-only filesystem design as a way to keep an attacker from persisting data inside the image.

The remaining pieces are about provenance and upkeep. A hardened image is expected to ship with an SBOM enumerating its contents—what CISA, building on the original NTIA work, defines as a formal record of the components and supply-chain relationships used in building software—and with some form of cryptographic provenance, typically signed attestations following the OpenSSF’s SLSA framework, which specifies cryptographically signed provenance generated by the build system to detect tampering (in practice, often via Sigstore Cosign). Finally, there’s a maintenance promise in the form of a service-level commitment that whoever ships the image will rebuild and republish it when an upstream CVE lands. This last element is the newest and the least standardized; it’s where commercial “secured image” offerings go beyond the baseline, with vendors like Wiz describing images that are continuously maintained at near-zero CVEs under an SLA.

Why now?

Three primary pressures converged to make 2026 the year of image hardening.

The first is that the National Vulnerability Database stopped being a reliable single source of truth. CVE submissions grew 263% between 2020 and 2025, with Q1 2026 running another third higher year-over-year. NIST enriched almost 42,000 CVEs in 2025 (a 45% jump over its previous record) and still could not keep up. On April 15 they formally moved to a prioritized model. Only CVEs on CISA’s KEV catalog, in federal software, or in executive order 14028 critical software get full Common Vulnerability Scoring System (CVSS) scoring and CPE mapping. Everything else gets a “Not Scheduled” label. VulnCheck’s analysis puts ”approximately 10,000 vulnerabilities from 2025 without a CVSS score.” If your scanner used to tell you what to prioritize based on the National Vulnerability Database (NVD), that pipeline has a hole in it now.

The second pressure is that the open source registries are openly under siege. The Shai-Hulud worm started chewing through npm packages in late 2025, came back as a more aggressive 2.0 in November, and in April 2026 a variant called Mini Shai-Hulud started compromising packages with valid OIDC-signed provenance, slipping past 2FA entirely. By May 11 it had hit TanStack (12 million weekly downloads on React Router alone), Mistral AI, UiPath, and OpenSearch. OpenAI disclosed credential theft from two employee workstations. TeamPCP, the group behind much of it, open-sourced the worm and announced a $1,000 contest for the largest supply-chain attack built on top of it. The attack surface is no longer just your package.json. It is every package any base image pulls in by default.

The third pressure is that AI is doing vulnerability discovery at machine speed. Anthropic released Claude Mythos to vetted security researchers as part of its Project Glasswing. OpenAI did the same with GPT-5.4-Cyber. The Edera-Minimus announcement was explicit about why the timing mattered, referencing Mythos by name. Whatever you think of threat-intel framing, the empirical claim is straightforward: novel vulns are being found and weaponized faster than human-scale CVE triage can absorb them.

So where do hardened images come into this? While image hardening does not solve any of these problems individually, it shrinks the surface that all three of them attack.

How we got here

Container images started out as the worst version of themselves, on purpose. Early Docker tutorials taught developers to build containers on top of a full Linux distribution like Ubuntu or Debian. You got a familiar filesystem, a shell, a package manager, and the ability to debug a running container with the same tools you use on your laptop. That convenience came with everything else the distribution shipped, useful or not, and base images stayed bloated for years.

Google’s distroless project was the first serious push in the other direction, starting around 2017. The idea was stark: ship your app and its runtime dependencies and absolutely nothing else. No apt. No sh. Bazel built it. The smallest distroless image is about 2 MiB, roughly half the size of Alpine and less than 2% the size of Debian. Adoption has been significant. The Kubernetes ecosystem treated distroless as best practice, and it has been “employed by Google and other tech giants.”

Chainguard, founded in 2021 by several ex-Google engineers (including the people who built Sigstore), came at it from a different angle. They built Wolfi, a Linux “(un)distro” designed specifically to be the building block for hardened images rather than a general-purpose OS. Apk-based, no kernel, packages compiled with hardening flags, SBOMs at build time, Sigstore signatures on everything. By February 2026 they had passed 500 million unique container build manifests and a catalog of more than 2,000 projects, on roughly $40 million in 2025 ARR.

There have been several other approaches to the problem that hardened images address, each tackling a different layer of the stack. Notably, AWS’s Bottlerocket is a hardened host operating system rather than a hardened application image. It minimizes the attack surface of the underlying node by shipping only the components needed to run containers, but it leaves the security of the application images themselves up to the user. A closer analogue is Replicated’s SecureBuild, which targets the application layer directly by providing zero-CVE container images for open source software. Rather than repackaging upstream binaries, SecureBuild rebuilds everything from source using an ephemeral build system and distributes the results through a hardened registry. Notably, Replicated also shares a majority of image subscription revenue with the open source maintainers whose projects it secures. Taken together, these efforts illustrate that “hardening” can happen at multiple points, from the host OS down to the individual application image, and that the most effective strategy often depends on which part of the supply chain poses the greatest risk.

What developers actually care about

A base image is a shared dependency, which means it’s also a shared liability. Whatever vulnerabilities ship inside an image are inherited by every application built on top, and they land on developers who are rarely in a position to fix them. You can’t patch a flaw in a system library you didn’t choose and often don’t control. The gap between who inherits the risk and who has the will and ability to actually remediate it is the whole reason a market for subscription-based hardened images exists.

The mechanism behind that liability connects directly to the flood of CVEs that AI-assisted vulnerability discovery has unleashed. Every package inside an image is a line in its SBOM and, potentially, a vulnerability waiting to be surfaced. A container built on a full Ubuntu base carries ~100 packages before your code is even added, and some of them—the shell, the package manager, assorted system libraries—never execute at runtime. Yet each is still a row your scanner checks against the vulnerability databases, and each can light up red when a new CVE lands upstream. Distroless skepticism aside, a distroless image cannot inherit a software vulnerability that it doesn’t contain. Stripping the image down was never really about disk size; it was about carrying less code that can turn into a CVE in the first place.

Why isn’t “hardened” already the default?

As I have been following the image hardening market in vendor briefings and conference keynotes, the question of why hardening isn’t the standard was one I struggled with. Here’s what I learned: container base images grew up as a developer convenience tool, not a security artifact. Installing extra packages from the command line is one of the first things any Docker tutorial teaches—Docker’s own Dockerfile guide includes apt-get install—and many of the most popular official images ship a full toolchain by default, with -slim and -alpine variants offered precisely because the defaults carry more than most workloads need, and changing them would have broken enough downstream workflows that it was never going to be a routine upstream decision.

There is also an incentive split. The upstream distribution maintainers and the developers using their images are different people with different priorities. Debian wants to ship a usable general-purpose OS. The developer pulling the Debian Bookworm OS into a container wants a runtime for one specific application. Hardening for the second use case requires throwing out things the first use case depends on. Vendors stepped in because upstream maintainers generally lack strong enough incentives to harden on the downstream user’s behalf. Docker, Chainguard, Minimus, Google/Wiz, and Red Hat all appearing in roughly the same window is the industry’s attempt to make hardened the new default without waiting for upstream to change.

Conclusion

To sum up, the reason behind 2026’s influx of hardened images is the increasing cost of extraneous code: transitive dependencies, unused packages, etc. As automated tooling drives up the rate of vulnerabilities, both publicly disclosed and black market exploits, the triage pipeline is necessarily straining under the volume, so that it has ceased to be a tolerable annoyance for developers, and has graduated into a serious liability. With increasingly malicious supply chain worms targeting the build pipeline directly, with AI accelerating both sides of the discovery-exploitation cycle, the price of shipping a whole distribution’s worth of software inside every container went up. Hardened images are the market finally pricing that in.

Disclaimer: Red Hat, Bitnami by VMware/Broadcom, Google, AWS, and Chainguard are all RedMonk clients.

This is a video I recorded with Simon about the show this year.  Xcelerate London 2026 is on June 10th this year – get your tickets here.

disclosure statement- Fastly sponsored the video.

In the wake of O’Reilly’s decision to exit their events business, including OSCON, a void was created. Among its other functions, OSCON served as the de facto annual gathering of forces within open source. While it’s distinct in some critical ways and can’t necessarily replicate the traction of its spiritual ancestor (in part because of OSCON’s densely packed venue), the Linux Foundation’s (LF) OSS Summit is arguably the best approximation of OSCON that exists in 2026. It transcends product categories, corporate boundaries and seniority levels to attract a mixed audience of young, old and everything in between.

It also, as mentioned, serves as a nexus for various powers within open source to meet – often accidentally – and exchange notes. It is, in the words of several open source people this week, a “favorite event.”

It’s also, by virtue of its attendees and focus, a valuable vantage point for observing macro trends and issues across open source at scale. Here are five takeaways from this year’s event.

AI and Data

When the OSI and other parties attempted to determine how and whether the term open source should be applied to AI models, data inevitably was the sticking point. The relationship of open source licenses to the source code components of the models was well understood. With data, not so much. Data licensing, unfortunately, is fractally more complex than for mere code.

It was not surprising, therefore, to see data singled out as one of the last holdouts to an open AI landscape. The LF has targeted this as an area of research and investment, with its CDLA family of licenses as one example.

There is, however, no consensus around data licenses, or even which entity should be the arbiter of same. The LF is appropriately focused on this as an area of necessary attention and investment, but how data licensing does or does not progress will certainly not be up to them alone.

Open Models

Research from the LF has apparently reached a similar conclusion to RedMonk’s own analysis: specifically that open models not only continue to compete with their closed, frontier counterparts, but that the gap between the two is closing over time.

This is interesting in the abstract, because having open alternatives to closed products has generally been beneficial to users. But it is of particular interest because of the stakes involved. Building and advancing frontier models, to date, has been fantastically expensive, and pushed startups in the space to pursue private capital investments in amounts previously unheard of. The return on these investments is predicated on several expectations, among them that the private models will become so indispensable that not paying the cost – even as costs rise – is unthinkable.

Open models that are becoming more aggressively more capable at faster and faster rates introduce questions around these valuations, and the expectations of return. It will be interesting to monitor the tension between open and closed models in the year ahead, because it’s possible there’s a threshold of capability at which users individual and enterprise alike regard as “good enough,” and that that threshold may be met by open models soon.

Security

Casting a pall over the success of open source more broadly were questions of security. As Jim Zemlin’s keynote quoted, the bill for deferred security investments for the industry as a whole is coming due. And we are not collectively prepared to pay it.

AI is both sides of the blade here. Via Project Glasswing, enabled by early access to Anthropic’s most capable model, security researchers are attempting to stay one step ahead and identify and patch vulnerabilities faster than they can be exploited.

But that is not scaling across the industry. AI is being used and used well by attackers, who are able to dial back the cost of the creating exploits to near zero and – coupled with decades of social engineering expertise – to attack broadly, at scale and with velocity.

This has led to fundamentally misguided efforts like that of the NHS to close source hundreds of open repositories in an effort to protect them. Notwithstanding the fact that this type of action both doesn’t work and has no defensible academic foundation underneath it, it is inevitable that we’ll see more of it.

Open source is likely, in other words, to have to prove its security bona fides all over again.

Maintainer Burnout

One popular topic of conversation at this event was maintainer burnout. From user entitlement to security worries to infrastructure not built for the volume of inbound AI contributions, life for project maintainers has never been more challenging. Asked if AI was helping to mitigate that, one maintainer bluntly answered, “No.”

Maybe it will in time, or perhaps other process and infrastructure adjustments will ultimately result in improvements, but for now maintainers are faced with an increasing number of challenges with no commensurate adjustments in the resources at their disposal. The number of would be contributors has skyrocketed in many cases; the number of maintainers has not.

This isn’t an LF problem, or at least it’s not strictly their’s to solve, but it is and remains very much an industry problem. One that does not get nearly the attention it deserves.

Who is the Next Generation of Open Source Defenders?

For decades, open source has found for itself new generations of advocates and defenders. Drawn to it by different paths, whether that was personal benefit, commercial opportunities or garden variety idealism, generations of technologists metaphorically handed off the responsibility for actively protecting open source to those coming up behind them who shared their sentiment.

It’s not clear, however, how much longer that shared responsibility can be sustained.

Open source has become, to a degree, a victim of its own success. Its ascension and then dominance made it something to take for granted, not something that needed to be cared for, nurtured and actively defended. Many developers today cannot remember a world not only in which open source didn’t exist, but one in which it wasn’t the dominant approach to building software. As a result, things like the ardent and assiduous defense of the literal definition of the term open source itself seems quaint at best and pedantic at worst. ”Ok, boomer,” is one common response.

As those who have been around long enough to understand that, like democracy, open source needs to be guarded with vigilance age out and retire, the question is who will step up to take their place? The OSS Summit didn’t provide many answers in that regard, but if would be defenders are out there, it’s presumably where they will first appear.

And if they don’t, maybe the event will have to recruit them more actively.

I am old enough to remember when people questioned whether Google Cloud even had a future within Alphabet. Well now we have a pretty clear answer – yes. I originally began this post as a quick roundup of news from Google Next 2026, but given Google’s results dropped the following week, let’s look at them first.

In the first quarter, Google Cloud revenue jumped 63%, year over year, to $20 billion, in the parlance of the day – absolutely crushing it. To the moon, etc. Growth rates like that on an already hyperscale business is quite something. Google Cloud now accounts for 18% of Alphabet’s total revenue. Which is to say, it’s a keeper.

Sundar Pichai, Google CEO said:

“Google Cloud is differentiated because we are the only provider to offer first-party solutions across the entire enterprise. Our growth in revenue, operating margin and backlog highlights this differentiation.”

AWS and Azure also had excellent quarters, but Google’s growth, even though from a lower base, was still a clear marker of substantial progress. I often say the best packager in any tech wave wins and wins big, and Google is looking increasingly well positioned. Packaging and integration go together hand in hand – you want an offering that makes things easy for the customer, reducing cognitive and organisational overheads. But packaging and economies of scale are also closely entwined – Google is well placed here because it owns technology up and down the stack.

Google also really pushed its position as a “full stack” AI infrastructure provider- it has technology leadership that spans from custom silicon to productivity apps, and unlike Microsoft and AWS it has its own capable frontier model in the shape of Gemini.

It is agents and harnesses however that are really going to drive model growth.

The agent platform

At Cloud Next Google announced tools for agent management and orchestration, and demonstrated continuing strength and depth in data infrastructure. It also apparently reintroduced Knowledge Management as an enterprise concern for the AI era.

The agent story is on point because, frankly, agents are finally capable enough to do some real work (on their own). Developers noticed a step change in coding agents around the turn of the year, as big a leap forward for LLM capabilities as the launch of ChatGPT in November 2022.

You just have to use the tools to see the clear difference in capability, or listen to AI-savvy developers across the industry. We’re in a fundamentally different environment now – the code being generated now is of a much higher quality.

Devs also began to better understand the value of brute force, and iterative loops (see the “Ralph Wiggum” pattern, invented and popularised by Geoff Huntley) in getting agents to do what they wanted. Harnesses are also becoming more effective, for example in providing consistent developer experiences as models evolve. If agents are getting this good at building and deploying software, other business processes are also going to be affected. The infrastructure we rely on just wasn’t built with agents and models in mind though – scale, security and management challenges are all massively increasing.

Google introduced Gemini Enterprise Agent Platform, building on and replacing its Vertex AI platform, with new features in its Agent Development Kit, scale and memory improvements for its Agent Runtime, but most importantly from a manageability perspective – Agent Identity, Agent Registry, and Agent Gateway. The central idea of Agent Identity is that you can assign every AI agent a unique cryptographic identity. Google also announced Agent Simulation, Agent Evaluation, and Agent Observability. Evals are as important to LLM apps as unit tests are to current software development. Observability is of course more important than ever, given we need to understand outputs and behaviours in production.

Google’s Dev Rel team did a solid job explaining how all of these tools play together in a demo during the developer keynote on day two – with a scenario of planning a marathon in Las Vegas. Each step in the development process was outlined and explained during the keynote.

For example a demo featuring Agent Studio – a collaborative workspace for building new agents. Key to the demo flow as whole was making it clear that different tools will be used by different personae, including “low code” developers using natural language, people living in markdown for specs, specs that cover business rules, not just software guardrails. Prebuilt agents include code modernisation, financial analysis, and deep research.

We’re going to see a lot more marketing around agent capability from platform providers as agents become more capable and widely deployed – indeed it’s pretty much the 2026 summer keynote.

The agent permission, security and identity play

With agents you have a bunch of autonomous systems using non-deterministic models to try and achieve outcomes. These agents are capable of taking action – sometimes very bad actions, such as deleting production databases. They absolutely need guardrails, and a markdown file just isn’t going to cut it. That’s where tools like Agent Identity come in. Permissions will need to be tightly managed. Role based access control (RBAC) will be essential for this agent buildout. But things are made even more challenging because most agents are ephemeral. RBAC systems were built for employees, and perhaps contractors, not agents you spin up and dispose of in minutes. New scale challenges everywhere you look.

Simon Willison coined the phrase the lethal trifecta:

• Access to your private data—one of the most common purposes of tools in the first place!
• Exposure to untrusted content—any mechanism by which text (or images) controlled by a malicious attacker could become available to your LLM
• The ability to externally communicate in a way that could be used to steal your data (I often call this “exfiltration” but I’m not confident that term is widely understood.)

“If your agent combines these three features, an attacker can easily trick it into accessing your private data and sending it to that attacker.”

Threats are growing all the time, partly because the tools are so powerful. Take OpenClaw, for example, designed as an AI personal assistant, arguably the fastest growing open source project in software history. OpenClaw reached 250,000 GitHub stars in about 60 days, surpassing React, which took over a decade to reach the same milestone. OpenClaw drove a spike in Mac mini sales as developers clamoured to use the software with a modicum of safety. The project went from launch to explosive growth to acquisition by OpenAI in about three months. Peter Steinberger, the lead developer, is now at the forefront of the movement to create agents that can do a range of tasks on behalf of the individual. For now it’s a developer play, but in the longer term it will be for enterprise users as well. It is a capable autonomous agent, built for messaging and integration to third party systems. But deploying it on your corporate network without a huge amount of supporting security infrastructure would be extremely foolish. It’s definitely not ready for the enterprise at this point. It’s simply too powerful as a lethal trifecta accelerant.

Agent sprawl drives the need for orchestration platforms

Orchestration platforms are increasingly a necessity because software developers are using teams of autonomous agents, sometimes working in parallel, but requiring asynchronous communication for handoffs and state management (memory) in the service of tasks and workflows.

This pattern reminds me of the evolution of containers and microservices. The container revolution began with devs running Docker locally on their laptop. As complexity compounded we needed an orchestration layer to manage all of these containers in production, which is how Kubernetes came into being. We’re now at a similar point with agents.

Agents as the primary driver of scale

Agents also drive much higher scale requirements. Look around the industry and you can see existing players and startups crushing it, or being crushed by, agent generated workloads. GitHub’s reliability issues are being exacerbated by agent-based software growth. There’s just so much software being built. Just look at Jarred Sumner of OpenAI, who just rewrote the entire Bun Javascript runtime in Rust, replacing the Zig implementation. One million lines of Rust code, all AI-generated. Regenerated is probably a better word than rewritten. Open Source projects are like Doctor Who now. Across the industry there are thousands of Sumners, also building huge code bases and new applications at an entirely new speed.

Token Economics and the Full AI Stack

Being an end to end stack player matters because it means you’re in control of costs of goods sold. You’re not reliant on third parties to serve customers, which is a clear economic advantage.

Control of cost is so important because the future of AI is going to be defined by token economics – that is, who can offer the greatest range of capabilities at the lowest cost. Anthropic and OpenAI are both going to raise prices in order to meet their sky high valuations. In recent months it’s become clear that the cheap token era is ending, even as some developers crow about “tokenmaxxing” as a badge of honour or productivity.

OpenAI and Anthropic need third parties to provide chips – NVIDIA. They also need cloud providers to provide compute, network and storage – business for the hyperscalers, as well as Coreweave and to some extent racle. Meanwhile AWS, Azure and GitHub are reliant on OpenAI and Anthropic (and their eye-watering balance sheets) to provide frontier models and associated services to their customers.

Owning a capable first party model is a crucial competitive advantage. At Next 2026 Google Cloud CEO Thomas Kurian announced that Google Gemini would be powering the next generation of Apple’s Siri service – see my post about it here. Gemini is now powering both Siri and AI services on Android phones worldwide — an almost incredible cloud win, given it covers most new phones being sold in the two key mobile ecosystems. Neither AWS nor Microsoft Azure could have won this deal given their reliance on third-party models.

What about the lower level stuff? Google has its TPU microprocessor architecture, which means that it’s not reliant on NVIDIA. AWS and Microsoft are investing in their own architectures optimised for model training. AWS will likely get there with Trainium, given the engineering process of its chip business – Graviton for general compute has been, and will continue to be, a huge differentiator for AWS as it seeks to lower the cost of compute for customers.

Google labelled its hardware advantage the AI Hypercomputer but we’ll largely stick to the agent story for the purposes of this post. It’s enough to say that AI is very specific in terms of compute patterns, and that’s why being in control of technology up and down the stack matters. And we haven’t even talked about the fact that Google Cloud also has a huge installed base of customers using its productivity tools. There is so much upside potential for integrations there.

But let’s cut to the chase. Enterprises are not going to take seriously the proposition that they should spend thousands of dollars per week per developer or agent. That’s not going to fly in Illinois, let alone Nairobi, Paris or Jakarta. I am old enough to remember enterprises balking at paying an extra $30 per calendar month per user for GitHub Copilot. So thousands of dollars per developer just seems unlikely at this point. Model choice is going to become more important, in this environment.

Data, Context and the new Knowledge Management

Data was the first business that Google Cloud landed in the enterprise, with companies making deep and strategic bets on Big Query, seeing Google as their “data cloud”. This beachhead is now increasingly realising gains in the AI space.

Google is world class at managing, and managed databases – Spanner is a globally distributed database offering near absolute transaction guarantees. It’s unique. It’s also increasingly appropriate for AI workloads, with multimodel capabilities including Spanner Graph, vector search and built-in full-text search. Google also offers Postgres in a couple of flavours, and Valkey for caching. You can have CloudSQL for MySQL if you’re looking for it, and for those so inclined of course you can get managed Oracle databases.

So what did Google announce at Next in the data space, to build on these strengths?

The key announcements were about what Google is calling the Agentic Data Cloud – key components of which are Knowledge Catalog, the cross-cloud Datalake, and the Agent Data Kit (meeting devs where they are, ensuring that Claude Code, Codex etc can do a solid job of accessing Google data services).

The Knowledge Catalog is essentially an AI-maintained index of all your enterprise data, structured so agents can actually use it. This is a modern, AI-inflected take on the classic Knowledge Management projects of the early web era.  We’re talking about Ontology with a capital O again.

Yasmeen Ahmad, managing director of Agentic Data Cloud at Google Cloud, is one of the best communicators in the industry. She introduced the data infrastructure section of the keynote, bringing the announcements to life with… Frozen Yoghurt. Yep – not a holiday booking, or revamping a camping company e-commerce site, but Froyo.

When you’re a food retailer you want to make sure you can meet people’s dietary needs – gluten and dairy free are both growth markets. Allergy information however might all be in a bunch of PDFs – it’s classic unstructured data, or what Ahmad calls dark data.

So what if the system identifies potential allergens? That’s new knowledge you can take advantage of for product management. So AI has enriched the knowledge catalog. But then you want to correlate that with a bunch of customer information about allergies. That might be in your system of record. But what if that database was hosted in AWS?

With Google’s Cross Cloud Datalake you can access data directly in third party clouds, using the Apache Iceberg standard. Finally you want to query the data before making a new product decision, so you use your favourite agent, and it’s ready to provide the correct answers based on your enterprise data via the Agent Data Kit. Great demo.

So the idea is that first you build a Knowledge Catalog. You don’t even build it. AI does.

I talked to Andi Gutmans, who runs Google’s data infrastructure and storage businesses. He said that humans are not going to be able to scale to the amount of data and events we’re talking about. Ontology is going to have to be machine learning based. Given the failure of Ontology efforts in corporations over the last few decades, partly because it’s just a hassle to annotate enterprise data with technologies like RDF, it would be hard to argue with him. Ontology, he argued, is actually an agent problem, so he has put together an “AI forward team to work on enrichment”.

The product design goal is essentially smart storage – a file lands, it’s instantly tagged, enriched and made agent ready. Every file or interaction should help the model learn about your business semantics. That’s where valuable context comes in. Google cited Virgin Media O2 as an early customer of the Knowledge Catalog, which it’s using across 20k different assets.

Of course you need a really good search engine on top of that ontology. Apparently Google has some proprietary search technology that is quite good.

We keep coming back to this question of human scale vs the scale that agents are going to drive. What does it look like to run an infrastructure business when a swarm of agents at a customer are going to spin up a hundred thousand databases in an hour and tear them all down again?

This is key to how Gutmans is architecting Google’s data products – agents take action, they don’t just make enquiries. Gutmans said Google Cloud is therefore now working towards an expectation of customers managing zettabytes rather than exabytes. Agents driving unprecedented data scale, just as they drive the need for compute, and transactions.

Rebuilding in flight

One thing I can’t stop thinking about that Andi told me:

“Now – I need to rebuild a lot of stuff we built a year ago.”

That’s the point. Everything – literally everything, is now about rebuilding in flight. You need to update your priors every day with AI, agent, and LLM progress, and that often means restarting projects because they simply don’t meet the new requirements. For an enterprise software business this is super hard. There are new product management disciplines required when the targets are moving so fast. This is going to find out a lot of companies, which are going to struggle with this rate of change and how to manage it. The days of ship it and then run it for the next decade are behind us. And if you don’t have an incredibly solid foundational platform, making these changes is all the more risky.

Related to this is the need to meet customers where they are. If enterprises thought shadow IT was hard, just wait til they start getting their heads around the new rates of tool adoption.

In a conversation at Next Peder Ulander, VP of marketing said:

“Years ago you could say here is an enterprise tool, and here is what you use at home.
It used to be – find a tool you like to work with, and maybe bring it into work two years later. Now it’s now the next year, it’s the next day.”

That’s the reality, and it’s a reality that agents are only accelerating. The tools are more capable than ever, the opportunities to improve business processes using autonomous agents is increasingly clear. People aren’t going to wait for traditional enterprise sales cycles to start using the tools. Vendors are going to need to respond with strong product led growth plays from the bottom up, supported with the usual large deal size top down procurement. The market is moving incredibly quickly, and Google Cloud is very well positioned for the agent era.

Ever since, software has been in constant tug of war between open and closed. With operating systems, virtualization software, mobile and other categories, closed software led the way and open gave chase. For big data, containers, programming languages and web servers, the roles were reversed. Open source typically led, while closed and proprietary models have had to keep up.

Models, for all that they are built and utterly dependent on a foundation of open source, are very much in the former camp. What began open became closed. “Frontier” models – which is to say models that push the “frontier” – are universally proprietary or closed, OpenAI’s name notwithstanding.

Ever since Chat-GPT was unleashed on the world on the 22nd of November, 2022, however, there have been – inevitably – efforts to counter the dominance of proprietary models with “open” alternatives (we’ll come back to what open means in this context). The technology industry has a long history of both dominant players, and federated resistance to those dominant players.

At a recent industry event, an AI executive likened the open models chasing their closed frontier counterparts to a “pack of wolves.” Casual observers of the industry could be forgiven for not knowing open alternatives existed, because almost all of the media’s attention is consumed by coverage of Anthropic and OpenAI’s latest achievements – though arguably that is in part because of the latter’s notable tendency to strategically time its releases around Google AI announcements to minimize their impact.

Whether open will compete with closed, then, is not the interesting question. It always has, it always will. The question to ask is instead: how well? Put another way, will the “pack of wolves” ever catch their prey, and if so, how quickly?

Evaluation of AI models is challenging for many reasons. Anecdotal experimentation is useful – anyone who used models before and after November of last year would be struck by the difference in capability – but it obviously doesn’t scale. The only real standardized quantitative measurement available, however, is industry benchmarks.

Given that benchmarks were gamed almost to the point of irrelevance decades ago during the TPC-C wars, they would not otherwise be the first choice for evaluation, but at this point they are the least worst method of measuring performance model vs model.

That being said, there are many other specific concerns for benchmarks generally and those selected here. Among them:

1. Contamination: models can be trained on data that includes benchmark test questions, either accidentally or deliberately.
2. Self-Reporting: models are typically self-reported by the labs that created them.
3. No Standardized Approach: benchmark scores can vary widely depending on scaffold, prompt, number of attempts, etc, and benchmarks typically don’t standardize the approach
4. Specificity: as will be seen momentarily, benchmarks typically have a specific area of focus. None can adequately cover or represent the breadth of actual real world use cases, and notably the benchmarks here are text in, text out – not multi-modal.
5. Difficulty: to measure progress over time, the benchmarks selected for this analysis had to have actual history. This means that more difficult or challenging benchmarks that have emerged more recently and may be more strenuous tests of ability are not represented here because they would not reveal any real trendlines worth noting.

In addition to those caveats, it’s important to note that there are dozens of potential benchmarks – some general, some specialized – that could be used. The selection process here prioritized consistently available scores across a wide variety of models and a reasonable history to evaluate. This, in other words, is a snapshot of benchmarks and other selections might produce different results.

One last necessary clarification before proceeding is the definition of “open.” This analysis includes both closed and open models. Closed is closed, but open includes two distinct subsets of models: open weight, and fully open. Fully open refers simply to models that are licensed according to a known and OSI-approved open source license: Apache, MIT, etc. “Open weight,” on the other hand, refers to the emerging industry consensus term for models that are mostly open, but include some restrictions on use that prevent them from being called open source – the most common example of which in this dataset is Llama.

With that context out of the way, let’s start with a simple glossary of the benchmarks selected.

Notably, the benchmarks here are arranged in an order of most to least “saturated.” Saturated refers to benchmarks that have effectively been solved by all or most models, and thus are no longer useful at measuring relative capabilities. In spite of their lack of utility today, saturated benchmarks are included in this analysis because they demonstrate the historical progress open models have made in catching up with their proprietary counterparts.

We’ll begin by examining one of these fully saturated benchmarks, GSM8K.

From GPT-3.5’s performance in December of 2022, within 16 months GSM8K’s grade school math problems were effectively solved. And importantly, by both open and closed models. By late 2024, fully open Deepseek effectively matched Claude Sonnet’s ~96% score. It’s also notable that the 7B Llama released in July of 2023 was basically guessing at 15%, but the 8B Granite model released in May of 2026 was at 93% – meaning that even small models performance was improving rapidly.

Next, we’ll look at a slightly less saturated benchmark, HumanEval.

The “Pass@1” in the above means the model only gets one shot at the question, and it’s excluding other related benchmarks like LiveCodeBench. Again, we see the same pattern playing out, with both open and closed models alike largely solving HumanEval, though the scores are slightly lower than GSM8K.

Also worth noting is that the 30B Granite 4.1 matches the 405B Llama 3.1 from two years ago, proving that open but restricted license models are not outperforming purely open alternatives – regardless of size.

Slightly less saturated than HumanEval is MMLU.

Smaller models aren’t faring as well with the broader set of 14,000 questions: 7B Mixtral represents the peak a bit over 70% and that hasn’t been exceeded since. The larger tier, 70B+, has for its part stalled around a GPT-4o level of capability. The larger open models like Deepseek have peformed well, though nothing close to the closed Opus 4.6.

It’s also worth noting while open weight models lead the way performance-wise, fully open models follow quickly after and now claim the highest scores.

Next up, MATH.

This is whether things begin to separate. The frontier models score around 90%, while the best open models tap out at 83%. Some of this admittedly might be an artifact of the fact that newer models are more commonly reporting against the AIME and MATH-500 benchmarks rather than classic MATH. Two other things to note: model size doesn’t seem to play a major role in performance, and the older fully open Qwen model still outperforms newer open weight Llama alternatives.

Now we’ll see even more separation in GPQA Diamond.

There are a number of interesting takeaways here.

For one, Deepseek R1 was ahead of all models, open or closed, when it debuted. But closed models made a big jump in the form of Gemini a few months later, and it took almost a year for open models to close the gap. Earlier this year, Deepseek, GLM, Kimi and Qwen have approached the performance of Anthropic and OpenAI, but not quite matched it.

Lastly, let’s look at SWE-bench Verified – 500 human-validated real GitHub issues.

From May of last year through early this year, all progress came from closed models. In February, however, things began to speed up. Both open and closed – Gemini, GLM, Kimi, MiniMax, Opus, Sonnet, etc – models all landed within 73-81%. Opus 4.7, for all of its other launch issues, jumped to ~88%, while the Deepseek V4 Pro leads the open contingent at ~81%.

The pattern here is clear and consistent: closed leaps forward, open is hot on its heels. And the cycle appears to be getting faster.

To explore that, let’s look at the time it took open models to match the capabilities of saturated benchmarks we examined earlier.

It took 18 months for Qwen to match GPT-4’s capabilties within the MMLU benchmark, and 13 months for Llama to do the same for HumanEval and MATH.

The longest it took an open model to match GPT-4o’s capabilities on any of those benchmarks, however, was seven months, and Llama matched its peformance on HumanEval in two.

But what about the harder, non-saturated benchmarks?

It’s more of the same. Deepseek caught up to Opus 4.6’s capabilities on GPQA in three months, and MiniMax did the same on SWE-Bench in one. None have matched Opus 4.7 as yet, but it’s been less than a month.

Takeaways

There are any number of different conclusions to be drawn from this dataset – with the caveats noted above – but here are five that stand out.

1. Closed models are setting the pace of innovation, and constantly breaking new ground from a capabilities standpoint.
2. Open models are chasing them, and the cycle times seem to be getting shorter. There are no clear capability moats, and what is frontier today is table stakes tomorrow.
3. Closed beats open today, but there is effectively no advantage to restricted open weight vs fully pen models.
4. Small models are extremely competitive in specialized disciplines, but lag behind on general performance.
5. The United States has the largest contingent of surveyed models (42), and the largest proportion of closed models (64%). China, by contrast, features 17 models, and every single one is either open weight or fully open.

Having performed this base level analysis, it will be necessary to track how these models continue to evolve and how the benchmarks evolve with them.

During his Google Cloud Next 26 keynote CEO Thomas Kurian said:

“We’re collaborating with Apple as their preferred cloud provider to develop the next generation of Apple Foundation Models based on Gemini technology. These models will now power future Apple Intelligence features including a more personalized Siri coming later this year.”

This is a big deal. This news didn’t come from Apple, which is notoriously tight lipped about such things. There wasn’t a press release about it. But assuming it’s true, and there absolutely no reason to doubt Kurian, then its worth considering what it means.

Pretty much every phone on the planet is going to be powered by Google Gemini AI going forward – certainly Android services will be, and this now bring iPhones into the mix. This is an almost absurdly great position for Google to be in, as AI moves out to the edge.

Every phone on the planet. That’s potentially billions of devices.

As we know, model preferences are far from sticky. They change day to day. Who knows what Apple will be using in 2027 or 2028? On the other Apple building its own frontier model based on Gemini – that does feel kind of sticky. It certainly took a while for Apple to make Maps competitive, for example, after its initial use of Google Maps. Google Search is still the default on Apple devices (to be fair Google pays for this privilege, but I believe the point stands.) This is a landmark win for Google Cloud.

There are all sorts of questions – not least architectural. Will Siri be running AI with local models, maybe something like Google Gemma, or is it about Siri’s back end running on Google Cloud with Gemma. Is this actually a client side win, or a cloud win. Given Apple’s strict approaches around privacy one assumes there will be a local component. Plenty to unpick though.

Model choices change quickly, but rolling these changes out at Apple ecosystem scale would be no mean feat. A ton of things would break.

Nobody chooses a model for life. But for this era of AI service buildout Gemini powering Siri is very notable. It’s a huge cloud win whichever way you look at it, and frankly neither AWS or Microsoft Azure could have done so, if it was based on owning a competitive frontier model. Unlike Google they lead with third party models.

I will be watching Google I/O closely next week to put this into further context.

disclosure: Google Cloud is a client, and paid for my T&E to the event.

Unless and until that occurs, then, it is useful to understand how open source licenses are being applied to models and in what proportions. To do this, inspired by a conversation on this subject yesterday, the approximately ~2.9M existing Hugging Face models were scanned for license information. There are some interesting takeaways from the data, but first it is worth noting that there are inherent issues with it.

• First, this analysis cannot account for licensing issues like an illegally licensed project. There are models, for example, that apply an Apache license but trained using Llama. That is not permissible, as you may not convey rights you yourself do not have – particularly if you’re performing actions a given license specifically and explicitly prohibits. This analysis would consider the project Apache-licensed, when in reality that license cannot not be applied.

• Second, this analysis can’t meaningfully discuss every one of the new licenses here, some of which were written by professionals and some of which were self-evidently not. Given the scale, it cannot guarantee that there are no falsely categorized licenses. The some Kimi and Mistral projects, for example, use a “Modified MIT License,” but the modifications make the project neither open source nor MIT. The good news is that projects using this license are typically categorized as “Other,” and are therefore properly not counted as open source here. The bad news is that we can’t guarantee that there might not be exceptions.

• Lastly, as will be discussed in more detail shortly, there is a rather large hole in the data.

With those warnings out of the way, we’ll start with the Top 20 licenses on Hugging Face.

This is a classic long tail distribution, but it is notable just how popular the Apache license is with ~2.5X more licensed projects than its nearest competitor, the MIT license. The next most popular licensing family, perhaps not surprisingly given its Hugging Face pedigree, is Open & Responsible AI Licenses (OpenRAIL). It is the largest single non-OSI, non-model-specific license category in this dataset.

Next, let’s look at the distribution of projects by category.

This is the hole in the dataset mentioned above. Just as GitHub historically reported that the overwhelming majority of repositories are unlicensed, almost seventy percent of Hugging Face models carry no license at all. This means that the data represented here about licensing distribution covers only a third of the models, though at almost a million the sample size is still large enough to be meaningful.

To better understand the distribution, let’s strip out the unlicensed projects and look at only those with one.

Notably, as was seen in our recent look at the state of open source software licensing, Hugging Face is displaying a systemic preference for permissive licensing models. If anything this data is under-representing the preference for permissive-style licenses, because while OpenRAIL licenses cannot be considered Permissive in the OSI-approved sense, in spirit they embody many of the same values.

Lastly, given the OSI context above, was to look at the specific breakdown of licensed projects carrying an OSI license vs an unapproved alternative.

Happily, among licensed projects, better than two thirds carried an OSI-approved license. We may not yet understand the exact role that open source will play within AI, but until there’s clarification a license style with a clear and unambiguous definition is proving to be the most popular choice – in spite or perhaps because of the contrasting styles of licenses that category contains.

It has not been a relaxing few months for software security teams.

In December, React disclosed its first critical CVE: an unauthenticated remote code execution flaw in Server Components. In March, not only was Aqua Security’s Trivy, a widely-used security scanning tool, compromised twice in three weeks through a GitHub Actions misconfiguration, but hackers also compromised a maintainer account for the Axios npm cURL package in order to publish backdoored versions containing a cross-platform remote access trojan that silently exfiltrated credentials. In April, Vercel disclosed a security incident originating from a compromised third-party AI tool, Context AI, used by an employee that gave attackers access to customer environment variables.

Many in the vulnerability space lay the blame for these cascading incidents squarely on AI—and they’re not wrong, though the story is more complicated than “AI bad.” AI-generated code is letting vulnerabilities slip into production at an alarming rate. Researchers at Georgia Tech’s Vibe Security Radar tracked CVEs directly attributable to AI coding tools and found that March 2026 alone produced more than all of 2025 combined. AI tools are also allowing bad actors to infiltrate systems in new and creative ways. The Axios npm compromise wasn’t a brute-force attack—it was “AI-enabled social engineering.” AI allows attackers to mount more elaborate and convincing campaigns against open source maintainers, while simultaneously flooding the ecosystem with code that is outpacing security teams’ ability to keep up.

In my previous post on the AI Slopageddon I covered the contribution quality crisis. AI-generated pull requests are overwhelming maintainers. The social contract between contributors and projects is breaking down. And AI platforms are making it worse.

This piece is a companion. It’s about the state of supply chain security in the age of AI. We look at slop vulnerability reports, a CVE database that may already be too slow to matter, and a software supply chain with security defaults designed for a world that no longer exists.

Meh-trics

_{Rachel Stephens’s laptop boasts a “Meh-trics” sticker.}

At RedMonk, we talk about metrics a lot, and often with suspicion. We’ve watched an entire ecosystem spring up around the monetization of perceived value in software—GitHub stars, contribution graphs, download counts, bounty payouts—proxy after proxy, each one promising to measure something real about the health and quality of a project, and each one an invitation to be gamed. Gaming isn’t new (Goodhart’s Law, amirite?). What’s new is the low cost of doing it well. AI has made it trivially easy to game software industry reward systems without delivering the outcomes they were designed for.

AI has collapsed the effort required to manufacture every signal of credibility the software ecosystem depends on, and the consequences are rippling through every incentive structure the community has built. Bug bounty programs are drowning in AI-generated reports that cost pennies in tokens to produce, but hours of expert time to debunk. Salaried internship programs like the Linux Foundation’s Mentorship Program, Google Summer of Code, and Outreachy are grappling with a murkier version of the same problem: maintainers I’ve spoken with are struggling to determine whether participants are actually doing the work or using AI to get their foot in the door without intending to meaningfully contribute afterwards. Even the resume-enhancing cachet of being an open-source contributor, a formerly reliable signal on a junior developer’s resumes, is losing its value as the cost of faking it approaches zero. AI is hollowing out the systems that once rewarded genuine effort from the inside.

What happens when the signals on which we’ve built our ecosystem stop meaning what we thought they meant, and what incentive structures we might build instead? To answer these questions, I looked at the vulnerability space, because that’s where the perverse incentives cut deepest and the money flows most visibly.

The Black, White, and Gray Markets for CVEs

Every vulnerability has a price. The question is who is paying, and for what?

There has always been a black market for exploits, so a white market emerged to balance it out (shout out to Bryan Boreham, Distinguished Engineer at Grafana Labs, for framing it this way in our recent conversation at Monki Gras). For this reason, a sophisticated, tiered global economy has emerged that is willing to pay for exploits.

At the bottom are the outright black market forums where weaponized exploits and stolen credentials trade hands with no pretense of legality. A threat actor claiming affiliation with ShinyHunters posted Vercel’s internal database on BreachForums that included customer API keys, environment variables, portions of source code at an asking price of $2 million. When suspected North Korean hackers from UNC1069 compromised a maintainer account for Axios, and shipped a remote access trojan to every developer who ran npm install during a three-hour window, that was a state-sponsored actor treating the open-source supply chain as an ATM for the North Korean missile program.

Above these sit the gray market brokers that purportedly sell to governments and intelligence agencies. Crowdfense offers “rewards ranging from USD 10,000 to USD 7 million for full exploit chains or previously unreported capabilities.” A UAE-based startup called Advanced Security Solutions launched in 2025 offering $20 million for “tools that can hack any smartphone.” Zerodium, arguably the most notorious broker in the space, spent years publishing a public price list for zero-days—up to $2.5 million for a full-chain iOS exploit—before quietly going dark in early 2025. These are the gray market players who sell to government and intelligence clients.

The bug bounty, by contrast, is the white market, or maybe more accurately, the counter-market. This time-tested resource at many companies exists to outbid the alternative. The entire premise is that if you pay researchers enough to disclose responsibly, they won’t sell to Crowdfense or post on BreachForums instead. Last year, HackerOne reported that 83% of surveyed organizations now use bug bounties, with total payouts reaching $81 million across all programs.

But bug bounties have become unsustainable at the exact moment they’re most needed, and even, in some cases, legally required. Bug bounty programs are being hit hard by AI—slop and non-slop. To begin, AI tools are finding all kinds of bugs.

The Arms Race

Security people love to call things an “arms race,” but in the case of AI the metaphor unfortunately fits. AI is the best weapon in both the attackers and the defenders arsenal, and the balance of power shifts depending entirely on who’s wielding it and whether anyone is paying them.

On the attack side: the cost of generating exploit code from a published CVE has collapsed just as thoroughly as the cost of generating a junk vulnerability report. The prt-scan campaign in March and April 2026 spent six weeks opening hundreds of pull requests against repositories with pull_request_target misconfigurations, rotating through throwaway accounts and using AI-generated, language-appropriate diffs to look like plausible contributions.

On the defense side: AISLE reported that their AI system discovered all twelve zero-day vulnerabilities announced in OpenSSL’s January 2026 security release, including bugs that had lurked undetected for 25 to 27 years, one of which predated OpenSSL itself, inherited from its 1990s predecessor SSLeay. Meanwhile, Anthropic’s Claude Opus 4.6 found over 500 high-severity zero-day vulnerabilities in well-tested open-source codebases without specialized tooling. These projects had fuzzers running against them for years, but the model found what the fuzzers missed. According to Stanislav Fort, AISLE’s founder and Chief Scientist:

AI is simultaneously collapsing the median (“slop”) and raising the ceiling (real zero-days in critical infrastructure).

Google, for its part, is betting that the answer is platform-level defense at machine speed. At Next ’26, the company unveiled what it’s calling “Agentic Defense“: a cybersecurity platform that merges Google’s Threat Intelligence and Security Operations with Wiz, the cloud security firm it acquired earlier this year. The headline numbers are sobering context for the investment: Google’s own M-Trends 2026 report found that the handoff time between an initial intrusion and a secondary threat actor has collapsed from eight hours to 22 seconds over the past three years (p. 55). At that velocity, human-speed triage is a rounding error.

Perhaps most relevant to the supply chain story, Wiz introduced an AI-Bill of Materials (AI-BOM) that automatically inventories every AI framework, model, and IDE extension across an environment: a direct response to the shadow AI problem that made the Vercel breach possible, where a single employee’s use of an unsanctioned AI tool cascaded into a platform-wide compromise.

But the strategic question isn’t whether AI is good or bad for security. It’s the incentive structure. Currently, the incentives reward finding over fixing.

Project Glasswing and the Bounty Crisis

When Anthropic announced Project Glasswing in April, they framed it as a response to a supply chain security crisis that had already arrived. Anthropic committed $100 million in usage credits for its Claude Mythos Preview model, along with $4 million in direct donations to open-source security organizations, explicitly to put frontier AI vulnerability detection into the hands of maintainers who otherwise couldn’t afford it. According to Jim Zemlin, CEO of the Linux Foundation:

I am optimistic but the urgency is real. We are in the most dangerous period, the transition when attackers might gain a significant advantage as the technology ecosystem digests the impact of AI.

Assuming we don’t write off Mythos as an elaborate marketing stunt, the subtext of Project Glasswing is that the white market for vulnerabilities—bug bounties, responsible disclosure, coordinated patching—will lose the economic argument without external incentivization. And the evidence for that subtext is already here.

cURL’s bug bounty program, running since 2019, found 87 confirmed vulnerabilities and paid out over $100,000. It worked until AI collapsed the cost of submitting garbage while leaving the cost of evaluating it unchanged. Daniel Stenberg, founder and lead developer of cURL, was forced to kill the program this January because his team was spending more time debunking AI-generated reports than writing code.

When I interviewed Viktor Petersson, co-founder of Screenly, he described the same dynamic from the other side. His company has received 331 vulnerability reports since launching its program less than six months ago. Thirty-nine were confirmed vulnerabilities. A huge proportion were duplicates. The volume got heavy enough that they had to build custom internal triage tooling and distribute review across multiple teams because no single person could keep up. After debating whether to kill the program, they decided to keep it—”it’s essentially an ongoing free pen test”—but Viktor was blunt about what he’s hearing from peers: more programs are going to be shut down. The teams simply can’t keep up.

The Node.js project tried to address this by imposing a minimum HackerOne Signal score to submit reports, eventually requiring new researchers to show up in the OpenJS Foundation Slack and talk to a human. It’s a reasonable filter, but every gate you build to keep slop out also risks keeping legitimate newcomers away. There is no clean solution here, only trade-offs.

Here is the core economic dysfunction: generating a plausible-sounding vulnerability report now costs pennies in tokens. Evaluating whether it’s real still costs an hour of expert time reproducing the steps, which are probably garbage, but which you can’t write off because what if.

You Can’t Just Shut It Down

_{Grace Hopper’s “First actual case of bug being found”}

Bug bounty programs are becoming unsustainable at the exact moment that reporting vulnerabilities is becoming legally required.

The EU Cyber Resilience Act takes effect in stages, and the first enforced milestone hits September 11, 2026. From that date, all manufacturers of products with digital elements sold into the EU must report actively exploited vulnerabilities to ENISA within 24 hours. You need a vulnerability disclosure program. You need SBOMs. You need continuous monitoring. You need all of this even for legacy products already on the market.

Stenberg could pull the plug on cURL’s bounty because it is a volunteer-maintained project with no fiduciary obligation to a regulator. A company selling software into the EU will not have that luxury come September. They’ll be legally obligated to maintain exactly the kind of intake mechanism that’s currently being firehosed with AI slop, and the penalty for non-compliance can run up to €15 million or 2.5% of global annual revenue.

And the CVE database itself? Although roughly 50,000 CVEs were published in 2025, up 22% from 2024, some security teams aren’t relying on lists of CVEs anymore (NIST CVE database, GitHub archived CVE records, Vendor-specific security advisories, OSV.dev, OpenCVE, VulnDB, CISA KEV Catalog) owing to (among other things) AI acceleration. By the time a CVE is published, the assumption is it’s already being exploited in the wild. All you need to do is point an LLM at it to write an exploit.

Some companies have responded by scanning package repositories like PyPI and npm in near real-time, using pattern analysis on code commits to detect compromises before a CVE is even assigned.

The implications for the VEX (Vulnerability Exploitability eXchange) and Common Security Advisory Framework (CSAF) infrastructure are uncomfortable. If the CVE is the lagging indicator everyone assumes it is, then the entire system of databases, scanners, and compliance checklists built on top of it is measuring yesterday’s weather. And the CRA is about to mandate that companies build their security programs around exactly these lagging indicators. That’s a perverse incentive of a different sort: regulatory compliance that optimizes for the appearance of security rather than its substance.

Paying for the Fix

The gap between “finding” and “fixing” is where money actually needs to flow, and a few models are trying to make that happen.

Sonar’s Tidelift pays maintainers directly to implement enterprise-grade secure development practices. Their 2024 survey data found that paid maintainers are 55% more likely to implement critical security and maintenance practices than unpaid ones. The mechanism isn’t complicated, pay people to do the work and more of the work gets done. Less clear is how “pay the maintainers” is going to intersect with “now my open source project has a fiduciary obligation under the CRA.”

Germany’s Sovereign Tech Agency has invested over €23 million in 60-plus open-source projects since 2022. Its Resilience program takes a notably different approach than traditional bounties: it reduces technical debt first through engineering contributions, then runs bug bounties, and crucially pays bounties to the maintainers who resolve these reported issues. The design was informed by Dr. Ryan Ellis’s research at Northeastern University, which found that bounties can actually undermine security for under-maintained projects by drawing attention and creating financial burdens the project can’t absorb. A 2025 feasibility study proposes a pan-European Sovereign Tech Fund with a minimum budget of €350 million building on Germany’s model.

Although models exist and work, they cover only a fraction of the ecosystem while the CRA is about to mandate vulnerability programs for everyone selling into the EU. Who pays for the assessment burden when the report-to-assessment cost ratio is this broken?

The Treadmill

Here’s where we are. Reports are cheap. Assessments are expensive. Bug bounty programs are simultaneously being killed and legally mandated. The CVE database may already be too slow to matter. The supply chain has consolidated around a platform whose defaults were designed for a different era. And AI is the best tool on both sides of the fight, with the outcome determined not by the technology but by whether anyone has the budget and the organizational will to use it for defense rather than noise generation.

The answer probably starts with flipping the ratio: making assessment as cheap as generation, paying for fixes instead of just finds, and treating supply chain security as the board-level priority it has been pretending to be. Until then, we’re on a treadmill that’s speeding up without an emergency stop button.

Disclaimer: GitHub/Microsoft and Google are RedMonk clients.

For most of the conversation’s participants, however, it had been some time since anyone – us included – had examined the numbers in detail, both for the slope of the trajectory and for the context around the spending itself.

While any analysis of this type is limited by the data that’s available – large important players like Anthropic and OpenAI for example are, for now, private companies and therefore don’t report their metrics publicly – it is nevertheless worth looking at the investments large cloud players have made in recent years, and how they might compare to non-infrastructure centric technology vendors like Apple.

For starters, then, here is the Plants, Property and Equipment (PP&E) spend for the selected vendors over the past decade. As a side note, these PP&E figures exclude operating lease right-of-use (ROU) assets because the point of interest here is actual capital build out.

Of note here are the relative rankings in PP&E spend of the investments, as well as the slope pre- and post-ChatGPT release. Additionally, as has been well documented elsewhere, Apple has not felt compelled to respond to this cycle’s frenzied wave of datacenter construction and its PP&E spend has remained static while that of its industry peers has soared.

Next, here’s a look at the changes in PP&E spend per company year on year.

The most important note here is to ignore the 2023 spike in Oracle’s PP&E; that’s an artifact of its 2022 $28B acquisition of the electronic health records company Cerner, with its datacenter, infrastructure and facilities hitting Oracle’s books in the following calendar year.

Other than random spikes in investments from Amazon, Meta and others, the only significant takeaway from this chart are the slopes again pre- and post-ChatGPT. Year on year growth in PP&E spend had plateaued and arguably declined heading into 2022, which is appropriate as the cloud market was maturing six years in. But these trends took an about face in the wake of ChatGPT’s breakout success, and increases in PP&E spend immediately accelerated.

Arguably the most startling chart, however, is that of PP&E spend as a percentage of annual revenue.

Apple and Meta bookend this chart as the opposite ends of the spending spectrum. But it’s notable how close the trajectories of Amazon and Google, and later Microsoft and much later, Oracle are as a percentage of revenue. It is eye opening that all but one of these companies – Apple being the notable exception – are spending at least half of their revenue figure, and most well north of that, on new infrastructure.

That level of investment would have been unthinkable a decade ago. Today, the chart suggests it’s table stakes unless you’re a commercial device retailer.

While PP&E spend is too blunt an instrument to perform a much more detailed analysis, it both points to the extreme level of investment required to be regarded as a credible player and raises significant questions about where, when and how the return on these outsized investments will arrive.

Disclosure: Amazon, Google, Microsoft and Oracle are RedMonk customers. Apple and Meta are not currently customers.