This summer, the White House rolled out the Gold Eagle Initiative, billed as an “unprecedented” effort to coordinate cybersecurity vulnerability disclosure across government and industry. It was easy to miss this news with all of the other safety concerns in the world of AI, but the timing isn’t a coincidence — and neither is the terminology. Gold Eagle is just one in a fast-growing category of security clearinghouses. Although it has already been scaled back once, recast in an August CISA fact sheet as a narrower triage layer rather than the sweeping coordination system first announced, it still indicates a trend we’re seeing in the world of cybersecurity.

To understand what a clearinghouse is, and why the number of them is increasing, it’s important to understand what has broken — namely (and hugely), the vulnerability disclosure process. For many years, vulnerability disclosure worked like this: A researcher found a bug, reported it privately, and honored an embargo period that gave vendors time to patch quietly (and hopefully quickly) and ship the fix before the bug was made public. This gave the good guys a chance to patch before the bad guys had a chance to use the vulnerability for bad guy things. The process was tedious, but it worked because the economics worked — historically, only nation-states had the resources to hunt for — or reward teams of experts to hunt for — undisclosed vulnerabilities at scale.

Of course, AI has changed all that — all of that. The average gap between the discovery of a vulnerability and its weaponization has collapsed from something measured in years to negative seven days. The bad guys are finding CVEs and exploiting them long before the good guys have had a chance to patch them. A terrifying prospect, to be sure. And it’s something I embarrassingly admit has happened to me personally several times recently.

Frontier AI models are democratizing the finding, chaining, and weaponization of flaws faster and cheaper than any team of human experts. Indeed, it’s the chaining — and AI’s mastery of it — that may be the most debilitating. In chaining attacks, two or three low-severity and moderate-severity bugs get stitched together by an AI system. On their own, these bugs are pretty unremarkable. However, by joining the “right” ones together (something AI is very, very good at), a model can achieve a full compromise.

Several major AI labs have already disclosed that their own models were used to breach unrelated systems, evidence that the old assumption about who can afford to hunt for exploits no longer holds. Anyone with API access to frontier models can now run what amounts to a small (and very efficient and intelligent) hacking team. Worse, these models can be resold illicitly to embargoed countries, and there’s an entire ecosystem of jailbreaking models to get them to do even more nefarious things.

Why clearinghouses?

At its core, the AI hacking threat is a scale problem that software development, be it proprietary or open source, was never set up to handle. It’s not just big projects like Linux and Kubernetes that are targets; it’s every one of the libraries underneath every application. There are literally millions and millions of packages available on PyPi (Python), npm (Node.js), RubyGems (Ruby), Crates (Rust), NuGet (C#/.NET), and Packagist (PHP), along with tons of smaller language ecosystems. These are ecosystems that power almost everything built today.

AI-generated vulnerability reports arrive faster than volunteer maintainers can read them, let alone verify and fix them. A single, real bug can spawn a dozen duplicate CVE filings from different automated scanners, each with its own tracking number, essentially serving as a distributed denial of service attack on the upstream. And, this is from the good guys, trying to do the right thing.

This “gap” (to put it mildly) is what clearinghouses are designed to close. Historically, a bug fix loop looks like:

1. Discover bug
2. Report to maintainer
3. Honor embargo
4. Maintainer patches
5. Release fix to the world

In the world of clearinghouses, here’s what it looks like:

1. Discover bug
2. Report it to clearinghouse
3. Receive patch
4. Clearinghouse handles the rest (handle embargos, reporting upstream, etc.)

It could look even as simple as:

1. Sign up for clearinghouse
2. Receive patches from clearinghouse
3. Clearinghouse handles the rest

The clearinghouse is essentially a trusted intermediary, run by a vendor, an association, or other entity, which triages the flood of AI-generated reports, identifies which are real, accepts or builds a fix, validates it, sends it to customers and partners, and only then works to merge it back into the upstream project. This still must be done at a pace that the upstream can handle.

There are also ethical dilemmas to handle here. It is not fair to force upstream projects to operate at the speed that for-profit and gigantic public entities require, especially large, demanding organizations like Fortune 500 corporations and governments. Remember, many people participate in open source projects for “fun”. Working for organizations demanding responses to thousands of CVE patches, faster and faster, is not fun or it would not be called work.

Assessing clearinghouses

Not all clearinghouses work in the same way. Some efforts function as a permanent fork that patch (and keep patching) the vulnerable code with AI-generated maintenance, and never reconcile with the original project. Others push every fix back upstream so it becomes permanent, which benefits the whole community. The latter seems to be the more functional option because if you can’t get your stuff back upstream, things could be locked in a clearinghouse forever. That feels a lot like vendor lock-in, as much as dressing a proprietary product in “open source” clothing does. You simply can’t have an open source clearinghouse that’s proprietary.

What else should an enterprise security team be looking for in a clearinghouse? Some hard questions to ask include:

• Can it triage the noise?
• Can it correlate multiple reports into one confirmed vulnerability?
• Can it produce a working patch, and not just an alert?
• Does it have a credible path upstream, rather than trapping users on a permanent fork?
• And, most importantly, who’s paying for it, and will they keep paying? In a word: Is it sustainable?

Clearinghouses may or may not become a viable tool in the fight to stay ahead of (or maybe just keep up with?) vulnerabilities in the AI age. Regardless, the bigger and more uncomfortable question is whether software itself needs to change. There are initiatives in place to quash entire classes of bugs: memory safety, thread safety, etc. Some are looking to write new Linux kernel drivers in Rust, a memory-safe language that structurally eliminates entire categories of the chaining bugs AI is so good at identifying and exploiting.

Other tactics include looking at compiling C/C++ with tricky new methodologies (fat pointers, or auxiliary pointers) to, again, remove entire classes of memory and threading bugs. Whether decades-old languages such as Python, Node.js, and friends can be hardened in similar ways, or will need to be rewritten from the ground up, remains to be seen. The world of open source is ablaze with experimental solutions.

For now, it’s less about a silver bullet and more about recognizing that vulnerability response has become a team sport at a scale nobody planned for. Every major bank, utility, and software vendor is running its own AI-augmented triage operation, and those operations increasingly need to talk to each other. The organizations that ask hard questions about triage speed, upstream commitment, and funding durability rather than taking a clearinghouse’s staying power on faith will be the ones standing strong under relentless vulnerability fire.        

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

Many of the recent supply-chain attacks could have been caught earlier if defenders looked closely at the telemetry GitHub already provides, researchers said.

At their Black Hat USA 2026 presentation, researchers Yossi Weizman of Microsoft and Mor Weinberger of Echo argued the case, saying, “GitHub can tell you’re being hacked. You’re just not listening.”

The duo described an EDR-style detection approach built from GitHub’s own event stream rather than relying solely on conventional endpoint or network telemetry.

After studying recent supply-chain attacks, including Shai-Hulud, Trivy, and Megalodon, the researchers found that seemingly different incidents repeatedly used the same techniques, from forged commit identities and poisoned tags to workflow abuse, OpenID Connect (OIDC) theft, and attempts to erase evidence.

They said they turned those recurring techniques into behavioral detections, combining GitHub webhooks, API data, and Git repository inspection to build a historical view of activity.

Their new open-source tool, dubbed “GitHub Threat Detector,” reportedly includes 22 production detection rules and 12 beta rules, with compound detections designed to correlate individually weaker signals into high-confidence alerts.

Everything leaves evidence on GitHub

The central observation in Weizman and Weinberger’s research is that supply-chain attacks often repeat the same patterns even when the targeted projects are unrelated.

A compromised identity, for example, may not be obvious from the commit itself because Git metadata can be forged. An attacker can set the author name, email, timestamp, parent, and other metadata to make a malicious commit appear legitimate.

But GitHub separately records the authenticated user who pushed the commit.

When the commit author does not match the authenticated pusher, defenders have something worth investigating, they explained. Added to this, their analysis revealed that attackers sometimes reuse the same forged identities across multiple victims. Searching GitHub for the same author’s email can therefore help connect seemingly unrelated incidents into a broader campaign.

“Forged identities in the repo which appear in other repos as well-is a strong indication of compromise,” they said.

The research found “forged maintainer’s identity” used across many attacks, including Trivy, tj-actions, Megalodon, TanStack, and Red Hat.

Another detection pitched on the same principle included tracking “Mass tag poisoning.” Mass tag poisoning involves force-moving numerous release tags onto a malicious commit so that workflows using a version such as @v1 execute attacker-controlled code. Researchers recommended adding tracking GitHub tag history through the GitHub API and comparing old and new commit references to catch this out.

OIDC offers another signal. Attackers can modify workflows to generate short-lived identities for cloud or package registries instead of stealing long-lived credentials. Watching for new or modified workflows that enable OIDC token issuance can help, the researchers said.

Correlating weak signals for stronger detection

GitHub Threat Detector follows an EDR-like pipeline: collect activity, enrich it with context, detect suspicious behavior, and then investigate or respond. The signals it ingests include live GitHub webhooks, API events, commits, tags, and Actions activity, while Git inspection provides additional context such as tag provenance.

Additionally, a PostgreSQL-backed activity store keeps the history needed to correlate events over time.

The tool took over 30 detection rules and tested them against 52 attack simulations, including reproduction of Trivy, TanStack, Megalodon, and Bitwarden CLI incidents. A separate “noise lab” helped researchers measure detection prevalence and recall, while tuning rules through allowlisting and severity adjustments.

The system, however, is not without drawbacks. Some of the trade-offs it carries include possibly disabled webhooks, rate-limited APIs, and Git inspection not being real-time.

The article originally appeared on CSO.

Cisco has revealed a family of open-weight AI models called Antares that, it said, can help security teams isolate potentially vulnerable parts of a software repository before deeper investigation begins.

Rather than detecting a specific CVE or generating a patch, these models search a codebase using only a Common Weakness Enumeration (CWE) description and return the files most likely to contain that class of vulnerability.

“Its purpose is to reduce a large codebase to a focused set of files that a security professional or a downstream security workflow should investigate,” Cisco’s AI researcher Supriti Vijay said via email. “The goal is not to replace a security engineer’s judgement or send them on a wild-goose chase, but to reduce fatigue and workload by helping them triage an issue earlier and focus their investigation on the most relevant parts of the codebase.”

The Antares family consists of models with 350 million, 1 billion, and 3 billion parameters trained specifically for repository-scale vulnerability localization.

The company said its largest model approaches the performance of GPT-5.5 on its internal vulnerability localization (Vloc) benchmark while remaining small enough for low-cost local deployment.

A search assistant, not a vulnerability detector

Cisco is careful to define what Antares is, and what it is not.

“Antares outputs a ranked list of source files likely to contain a relevant vulnerability, along with the terminal exploration trace that led to that result,” Cisco Foundation AI Chief Scientist Amin Karbasi wrote in a blog post, adding that the models are not meant to replace the broader application security toolchain: Human analysts or downstream security tools will still be needed to confirm exploitability, identify vulnerable lines of code, assess severity and generate fixes.

Antares differs from conventional static analysis platforms such as Semgrep or CodeQL, which primarily rely on predefined rules or queries. Cisco instead describes Antares as an evidence-driven exploration agent that adapts its search as it traverses the repository.

Cisco’s argument is that large repositories often contain thousands of files, making manual reviews exhaustive and unrealistic. By reducing the search space to a manageable shortlist, the company hopes to reduce investigation fatigue without replacing human judgement.

Claims of specialization over scale

Cisco is also making a statement about how cybersecurity models should evolve.

Instead of pursuing larger foundational models, Cisco argued that specialized, task-trained models can outperform much larger open-weight alternatives for vulnerability localization. In its evaluation Antares-3B, the largest model intended for single-GPU deployments, produced results comparable to GPT-5.5 while outperforming several substantially larger open models by Google, OpenAI and Meta.

The family also includes Antares-350M for resource-constrained environments and Antares-1B for laptops and workstations, which Cisco has made available as open-weight models on Hugging Face.

The command line interface (CLI) on the models supports targeted CWE investigations, repository-wide scans, SARIF output and local inference, which Cisco said enables organizations to keep proprietary code inside their own trust boundary.

However, because Antares identifies candidate files rather than confirmed vulnerabilities, organizations will still need to understand how often such repository-wide searches should be run, how much they improve existing triage workflows, and whether the reduction in investigation effort ultimately translates into measurable security or cost benefits.