Apple today announced the global App Store ecosystem facilitated over $1.4 trillion in developer billings and sales in 2025.

A third of the way into a security-operations guide that Anthropic published in April 2026, wedged between a recommendation to patch CISA’s Known Exploited Vulnerabilities list and a suggestion to automate your deployment pipeline is a small recommendation: “Use EPSS to prioritize the rest.” For anyone who has worked on a vulnerability backlog in the last decade, the sentence is an acknowledgment of a widely felt but often unspoken fact about security programs: They have become machine-scale problems of signal to noise.

EPSS (Exploit Prediction Scoring System) is a statistical model that takes a known software flaw, runs it through a set of signals about what attackers are actually doing across the internet, and returns a probability that the flaw will be exploited in the next 30 days. It isn’t an LLM, and it does no reasoning or prompt engineering. It predicts. The company endorsing it is the same company whose newest model can surface thousands of novel, exploitable vulnerabilities in production software, many of them two or three decades old, most of them still unpatched.

As far as we can tell, this is the first time a frontier AI lab has publicly endorsed a purpose-built predictive model as the right tool for a defensive problem. LLM labs usually recommend LLMs. That Anthropic did not is worth noting, but the recommendation itself isn’t news to the practitioners it’s aimed at. It’s a description of what they’ve been doing.

The quiet consensus

The volume problem isn’t new. Anyone running a scanner against a large enterprise estate in 2015 was already generating hundreds of thousands of findings per month. Anyone running one against a cloud environment in 2020 was generating millions. Enterprises have spent the better part of a decade staring at dashboards where the number of open critical findings was larger than the capacity of the team supposed to fix them. In other words, cybersecurity has become machine scale.

Risk-based vulnerability management, as a product category, has existed since around 2018. EPSS, as a public resource, has been usable since 2021. More than 120 vendors embed it today into their products. The field has had access to a predictive baseline for years.

What has been missing is an external justification to change the status quo recommendations from auditors, model risk management teams, and even boards. Auditors want a clear set of expectations, making grading more objective and therefore easier to evaluate. Compliance frameworks like CVSS (Common Vulnerability Scoring System) because CVSS is easy, but implementing something more efficient has historically required that aforementioned external push. A working CISO could tell you she had stopped treating every vulnerability scored a severity 9.8/10 by CVSS as an emergency in 2019, but she would also tell you she still kept CVSS in the report.

Anthropic’s guidance is useful because it makes the private consensus public. Patch what you know to be exploited, then use EPSS above a threshold based on the team’s capacity or risk tolerance. DHS CISA’s practice of publishing known exploited vulnerabilities since November of 2021 is just additional proof that the existing methodologies were being overwhelmed by scale and lack of signal.

Why prediction, stated plainly

In 2014, at Black Hat, Dan Geer, then the chief information security officer of In-Q-Tel, asked the first principles question: Are vulnerabilities in software sparse or dense? Sparse meant finite, meaning every fix measurably shrank the attack surface. Dense meant weeds in a field. Geer could not answer the question because the data were not in.

Eight years later, Jonathan Spring at Carnegie Mellon’s Software Engineering Institute tied vulnerability enumeration to the halting problem and showed, in theory, that for any sufficiently complex piece of deployed software, there are always more undiscovered flaws.

The AI-driven discovery results of the last 18 months have made the density argument impossible to wave off even in a compliance review. A 27-year-old bug in OpenBSD. A 16-year-old bug in FFmpeg that five million fuzzing runs never caught. Disclosed findings, by the developers’ own accounting, are less than 1% of what has been found. But again, the volume was already a problem. With the coming release of its newest model, Mythos, Anthropic is telling teams to plan for an order of magnitude more findings over the next 24 months.

Static severity scoring can’t survive the volume problem, because it’s a human-scale solution for a machine scale problem. Neither can any process that treats every critical finding as an emergency. The threshold for action has to be probabilistic, measurable, and defensible. That’s what a predictive model is for, and that’s what working teams have been using in noisy large enterprise environments.

Pointing machines and knowing machines

Geer returned to his 2014 question in the summer of 2025, writing with Dave Aitel in Lawfare. The piece gives the industry a vocabulary for a distinction it has been fudging:

A vulnerability in the code isn’t automatically a threat. A buffer overflow is a hazard. It becomes a risk only if an attacker can exploit it reliably, in this environment, against these controls, through this traffic. Bugs are abundant but the ability to weaponize a particular bug against a particular target is much rarer.

The industry, they wrote, has built a pointing machine. It enumerates.

Even children learn early to point and name—but knowing the word “dog” doesn’t reveal whether the animal might bite. In cybersecurity, we’ve built systems that similarly point and name vulnerabilities without understanding whether they’re truly dangerous. By embracing AI solely for pattern recognition, we’ve created a powerful “pointing machine” that identifies possible threats but does not comprehend their actual impact. What we need instead is a “knowing machine,” capable of understanding how code functions within complex, real-world environments, recognizing not just hazards but the full context of how and whether those hazards might become genuine risks.

A knowing machine is a system that understands how code behaves in a particular environment and recognizes the context that turns a hazard into a risk. A predictive model is how you build a knowing machine. EPSS is the clearest public example: It covers every published CVE and is updated daily.

Global isn’t local

EPSS is a global model. It sees what attackers are doing across the whole of the internet. It picks up patterns in exploitation activity that severity scores never could. What it can’t see is any particular organization’s environment. It doesn’t know which assets carry the data the business actually cares about. It doesn’t know what compensating controls are in place, where remediation is risky, or how your telemetry and history change the odds.

A 9.8 with a 97% global probability of exploitation and a 9.8 with a 0.1% probability are not the same animal. Neither are two organizations applying the same EPSS threshold to the same CVE on different assets. One has the vulnerable code path exposed to the internet, behind a web application firewall that doesn’t inspect the relevant protocol. The other has the same CVE on an internal system that accepts authenticated input from a single service account. A scanner can’t tell them apart. A global model can’t tell them apart. Their actual risk profiles are orders of magnitude apart.

Local context is where most security teams have been stuck the entire time, and where the next decade of the field is going to be fought.

What a local knowing machine actually requires

Pair a better pointing machine with a faster remediation engine and all you’ve done is increase the speed at which you produce churn, breakage and wasted effort. You’ll also spend a king’s ransom in agent tokens fixing vulnerabilities that were never dangerous in your environment.

In contrast to an omniscient scanner, a local model trains on the specific environment being defended: asset inventory, application topology, reachability, deployed controls, attack telemetry observed on-site, and the history of the organization’s own remediations and their outcomes. The model produces probabilities specific to the enterprise. Most organizations already have the inputs, scattered across CMDBs, endpoint agents, firewall logs, ticketing systems and scanner output. This context is precisely what attackers (whether they’re using good old fashioned metasploit or Mythos with an infinite budget) are lacking in their models. The context becomes an asymmetrical advantage for defenders, perhaps the only one that exists.

The policy shifts that actually matter

The interventions that will decide whether a security program survives the next 24 months aren’t purely technical. A CISO can put most of them in motion without buying anything.

Rewrite the SLA. Most vulnerability-management SLAs are organized by severity. Criticals in 15 days, highs in 30, mediums in 90. That structure was built for a world where the count of open criticals was small enough to matter. It’s now actively harmful, because it forces teams to spend the same effort on a 9.8 nobody is exploiting and a 7.5 that’s under active attack. SLAs should be rewritten in terms of probability of exploitation and asset exposure, not severity. A CISO who can’t get that past her GRC team can at least add a second tier that makes the probability-based cut enforceable alongside the severity-based one.

Change what the board sees. If the monthly security report counts the numbers of vulnerabilities, exposures or findings in different buckets (“critical,” “open past 30 days,” etc.), the organization is being managed to the wrong metric. The metric should be exploitability-weighted exposure over time, with a second line for predicted versus observed exploitation. Boards will accept this once somebody explains it. This beats showing them a number that has no relationship to risk and is growing exponentially as new LLM models are released. More to the point: A great team can do amazing volumes of remediation work, and risk can still rise because they’re measuring and remediating the wrong thing. An efficient, context-rich team can do far less work and meaningfully move the probability of an event down.

Invest in telemetry. The single most valuable instrument a security program can build is a feedback loop between what was prioritized and what was exploited. If the loop shows you were wrong, the model improves. If the loop does not exist, you will keep being wrong indefinitely (or just not being aware of misses).

Fix the compliance conversation. The reason CVSS survives is regulatory inertia. PCI, HIPAA, and most state breach-notification frameworks still reference severity. The CISOs who will come out of the next two years in the best shape are the ones who engage their auditors now, in writing, about what a probabilistic prioritization framework looks like under the existing rules.

Staff for the bottleneck, which isn’t scanning. The industry has spent a decade hiring people to find bugs. The bottleneck now is deciding which bugs matter, getting the fixes deployed, and measuring whether the prioritization was correct. The job descriptions should reflect this. A security-data engineer may be able to increase efficiency to meet SLAs more than increasing capacity would.

None of this requires a new product. All of it requires a CISO willing to say, out loud, that the old dogma is broken and that the new one will be managed by data and probabilities. That is the shift Anthropic’s five-word sentence was really announcing. The technology is available and the models are here—both the LLM-based ones to find the vulnerabilities and the predictive knowing machines to prioritize efficiently.

Postman can generate a fully documented, type-safe SDK directly from a collection or an OpenAPI spec, in nine languages, and it can also generate a CLI SDK that agentic tools like Claude Code can drive on your behalf.

We’ll work through it end-to-end against a public sample collection so you can follow along even if you don’t have your own API yet. If you’d rather watch it first, here’s the companion video:

What you’ll do

1. Fork the Book API collection in your own Postman workspace.

2. Generate a TypeScript SDK from the Book API Collection.

3. A CLI workflow to regenerate the SDK from a terminal.

4. Generate a Go-based CLI SDK that wraps the same API for Agents.

5. Claude Code calling your API through that CLI SDK

Before you start

You’ll need:

• The Postman desktop app.

• A Postman account.

• Node.js + Yarn (for running the TypeScript SDK).

• GoLang Installed(for building the CLI SDK).

• The Postman CLI installed and authenticated.

• A local Git repo and a GitHub account.

Step 1 — Create a blank workspace in Postman

First, fork this repository on GitHub and run the following commands to get started.

yarn install && yarn run dev

Once setup, open the Postman Desktop application. In the top-left Workspaces menu, click Create Workspace and give it a Name(e.g. Book API Playground). Select Internal as your Workspace Type. For your Workspace setup, select the From a Git repository option and choose the folder of the Book API repo you just cloned.

You’ll land in your new workspace, connected to your git repository, with the cloned folder opened in the left navigation menu. Postman creates two new directories in this folder:

• .postman/ (hidden) — internal mapping and metadata.

• postman/ — where generated SDKs and other artifacts will be written.

Step 2 — Generate the Book API Collection

Click the ask AI button in the right pane of the workbench. This will trigger Agent mode to peruse the codebase in your connected git repository, understand the exposed API endpoints and generate a Postman Collection based off of them.

In the top navigation menu at the left sidebar, on click on Local Items. This is the leftmost cube icon. You will see the generated collections which you can peruse and test against the locally running book API server.

Step 3 — Generate a TypeScript SDK from the UI

Now the fun part.

In the left sidebar, click the plus icon beside the search box. Scroll down and select SDK. Select a collection, give your SDK a name and select a Typescript as your language, the click the Generate SDK button.

Once the SDK is done generating, you will see a basic setup documentation for the SDK. The SDK should now be available in your local git repository under the ./postman/sdkfolder. You can navigate to the Local Files tab to view or open in your code editor. Alternatively, you can click on the Download SDK button at the top right of the documentation. The folder contains the SDK source, auto-generated docs, and an example/ directory with a runnable sample.

Note: If your Workspace is not connected to a git repo, Postman gives you a zip of the same folder to download and extract wherever you like.

Step 4 — Install and run the SDK locally

Open the generated folder in your code editor and install the dependencies. Ensure you have the typerscript subfolder open as this is where the SDK ts code is located. It should look something like postman/sdks/Collection SDKs/book-api/typescript

Install dependencies and build:

yarn install && yarn build

Open example/src/index.ts. It imports the generated SDK, instantiates a client, and calls one of your endpoints. Run the sample code.

cd example/src &&tsx index.ts

You should see a real API response, through a generated client, with zero handwritten HTTP code.

Step 5 — Automate SDK updates with Postman + GitHub

You don’t want to regenerate by hand every time the collection changes. Postman can open a pull request against your GitHub repo automatically whenever the underlying collection is updated. This feature is available on the Enterprise plan, and the full reference lives in the Automated SDK generation docs.

Before you start, install the Postman GitHub app on the GitHub account or organization that owns the target repository.

From your collection’s generated SDK documentation page in Postman, click Publish SDK in the top right. In the dialog that opens:

1. Click Connect to GitHub.

2. Pick your provider (GitHub or GitHub Enterprise Server) and authenticate if prompted.

3. Select the GitHub organization, then choose an existing repository or create a new one (set the owner, name, and visibility).

4. Pick the target branch — main is the default.

5. Click Connect.

Postman opens an initial pull request containing the complete SDK along with a security scan summary. Review and merge it.

From that point on, any change to the Postman collection automatically triggers a new SDK build and a follow-up PR. Postman bumps the SDK version for you and posts a summary comment on the PR describing what changed.

Optional: distribute via npm

If you want each merged PR to also publish the SDK to npm, toggle Distribute SDKs via npm in the publish settings, then add an NPM_TOKEN GitHub Actions secret with Read and write scope for the package. Postman wires the publish step into the generated workflow.

To stop automated PRs at any time, open the SDK page and click Disconnect in the top right.

Step 6 — Regenerate from the Postman CLI

The UI is great for the first generation and the auto-PR flow handles the steady state, but for one-off scripts, local experimentation, or non-Enterprise CI you’ll want to use the Postman CLI.

postman sdk generate --help

The flags you’ll reach for most often:

• -l, –language: Target language(s). One or more of typescript, python, java, kotlin, csharp, go, php, ruby, rust, or cli.
• –all: Generate SDKs in every supported language at once.
• -o, –output-dir: Where to write the generated SDK.
• -p, –package-name: Name of the generated package.
• -v, –version: Version number to stamp on the build.
• –yes: Skip prompts (useful in scripts).
• –no-emit: Build server-side without downloading artifacts.

Regenerate the TypeScript SDK from a collection ID into a specific folder:

postman sdk generate <your-collection-id> \

 --language typescript \

 --output-dir ./sdk/book-api \

--yes

Grab the collection ID from the collection URL in Postman, it’s the segment after /collection/.

You can drop this same command into a shell script, a Makefile, or a non-Enterprise CI job (e.g. a plain GitHub Actions workflow) when you want to roll your own automation instead of using Postman’s built-in publish flow.

What about CLI SDKs?

There’s one more language target worth calling out: cli. Selecting it generates a Go-based command line tool that wraps every operation in your collection.

Why bother? Agentic systems like Claude Code, Codex, and Gemini CLI already interact with APIs the same way they interact with everything else on a developer’s machine, by running terminal commands. They reach for curl and bash scripts because the terminal is the universal interface they already have. A CLI SDK turns your API into that same native command-line surface, giving agents the abstraction layer humans get from an SDK without forcing them to invent a new way to talk to your service.

To try it, open the SDK generator dialog from Step 3 again, toggle on CLI (and toggle off other languages if you only want the CLI artifact), give it a name like book-api-sdk-cli, and click Generate SDK.

The generated folder ships with two important pieces:

• The Go source for the CLI binary.

• A .cl/ folder of skills — skill.md files that tell agents what each command does and how to invoke it. The top-level skill.md acts as an index so agents don’t need to read every subfolder.

Build and explore it:

go build

./book-api-sdk-cli health health-check

./book-api-sdk-cli --help

Every resource in your collection becomes a subcommand group with its own --help (create-book, delete-book, get-book, list-books, update-book).

Now open Claude Code from the same directory and ask, in plain English:

How many books are in my inventory?

Claude Code reads the index skill.md, picks the matching skill, runs ./book-api-sdk-cli books list, and answers from the response. Ask it to “create a new book titled Atomic Habits by James Clear” and it calls books create-book with the right flags. The SDK is the abstraction layer, and the CLI is how the agent reaches it.

Wrapping up

You now have three ways to ship a Postman-generated SDK, each suited to a different moment in the lifecycle:

• The UI for the first generation and quick experiments.

• The auto-PR flow for the steady state, so the SDK never drifts from the collection.

• The Postman CLI for scripts, local regeneration, and your own CI.

And with the cli target, the same collection becomes an interface that agentic tools can drive directly with no bespoke tool definitions, just commands.

The collection is the source of truth. Everything downstream(typed clients, docs, the agent-ready CLI) regenerates from it. Fork the Book API collection, point it at your own API when you’re ready, and let the generators do the rest.

The post Generating Client SDKs and AI-Ready CLIs with Postman appeared first on Postman Blog.

I have been attending Microsoft events in one form or another for a long time, and I have learned that the first wave of conference reactions is usually not where the real story lives. The first wave is always loud. It's the keynote clips, the social posts, the product names, the demos, and the inevitable rush to figure out which announcement is the announcement everyone should be talking about. That's useful to a point, but I usually find the more interesting story a little later, after I...

Cloudflare supports Vite's mission ​

June 4, 2026

Today marks the start of a new stage for Vite. VoidZero is joining Cloudflare. You can read the full story from Evan You in VoidZero's announcement. In Cloudflare's blog post, they explain why they are investing in the Vite stack, which has now become part of the web's foundational infrastructure. Vite's team governance, mission, and philosophy aren't changing:

• Vite remains open source under the MIT license.
• Vite remains vendor-agnostic, applications built with vite are meant to run anywhere.
• Vite continues to be stewarded by the Vite team, which includes members employed by different organizations and independent members.
• Vite's Open Collective funds are managed by the Vite team and are used to fund independent core team members, dependencies, and other key projects in the ecosystem.
• The Vite team members employed by VoidZero are all joining Cloudflare and will continue to work on Vite.

As stated in the VoidZero and Cloudflare announcements, the same applies to Vitest, Rolldown, Oxc, and Vite+.

Cloudflare's Vite Ecosystem Open Source Fund ​

Cloudflare is committed to helping Vite remain neutral and has also announced a new $1M open source fund for the Vite ecosystem. Alongside Vite's Open Collective (which stays managed by the Vite team), these funds will allow us to further improve Vite and its ecosystem, including:

• Fund more popular plugins and toolings in the ecosystem.
• Adopt a core team member stipend to support independent team members.
• Work closely with teams of the Vite stack, including Rolldown, Oxc, and Vite+.
• Work closely with the ecosystem maintainers from frameworks, plugins, and deployment platforms.
• Work with standard bodies and adopt new web platform features faster.
• Audit and release security issues more quickly.

Many of which we had already started working on, which will help accelerate the process.

Thank You ​

We want to thank our current sponsors through GitHub Sponsors and Open Collective, which remain invaluable to us. We'd also like to thank the teams from projects, ecosystem frameworks, and plugins whose collaboration helped Vite reach where it is today. And also to the 1250+ contributors to the Vite repo and the users who keep providing valuable feedback to improve Vite.

We talked about what's next in Vite 8's announcement. We have made good progress towards Full Bundle Mode and the new Ecosystem Sync Calls, that gathers members of different frameworks, deploy platforms, and plugins, have become a great motor for new ideas to further expand Vite's capabilities. We think we're on a good trajectory to stabilize Vite's Environment API on Vite 9. As Vite's story continues to unfold, we look forward to the long path ahead to keep building the web together.

Get ready for a summer of sport with our new personalizable merch.