Inside the PHP Foundation's Ecosystem Security Team: One Month In

Security work in open source usually happens out of sight. A maintainer gets a report, quietly ships a patch, and the rest of us update our dependencies without ever knowing how close we came to running vulnerable code. So it is a genuine shift to see the PHP Foundation publish a transparent, month-by-month account of an organized effort to scan the ecosystem for vulnerabilities and help maintainers fix them. On June 23, Volker Dusch posted the first progress update from the Foundation’s new Ecosystem Security Team, and the numbers are worth paying attention to.

If you ship anything to production on top of Composer, this work touches you whether you realize it or not.

What the Team Is and Where It Came From

Back in May, the PHP Foundation announced it had secured a grant from Alpha-Omega, administered through the Linux Foundation, to improve the security of the broader PHP open source ecosystem. The grant funds a new Ecosystem Security Team, with Volker Dusch (known to many as edorian, a longtime contributor and former PHPUnit maintainer) leading the charge. The initial funding covers six months, but the Foundation has stated it wants to sustain the team well beyond that, folding it into its new Community Special Interest Groups structure.

The premise is simple. PHP runs a huge share of the web, and the packages we all pull in through Composer form a dependency graph that almost nobody audits comprehensively. A coordinated team with funding, tooling, and access to capable AI models can scan that graph at a scale individual volunteers cannot match.

The First Month by the Numbers

In roughly a month, after a short setup period, the team:

Scanned and rescanned over 300 of the most-downloaded Composer packages, plus nearly all the major frameworks.
Talked with 35 project maintainers about the scanning effort and their security concerns.
Shared hundreds of potential vulnerability findings.
Saw nearly a hundred publicly available fixes land across the ecosystem.

There is an honest footnote in the report that I appreciated. In one case, roughly 200 repositories applied the same GitHub Actions fix because they share a central template. Rather than inflate the headline number, Dusch counted that as a single fix. That kind of restraint is a good signal about how the team intends to communicate.

The other detail that stood out: of all the maintainer interactions, only one was negative, and there was a single person the team is still trying to reach. For an unsolicited “hi, we found possible security issues in your project” outreach campaign across hundreds of repositories, that response rate says something healthy about the PHP community.

How the Scanning Actually Works

The team is not just running a static analyzer and emailing the output. The process leans heavily on AI models with extended security or “cyber” capabilities, but the human work is in triage: reproducing issues, doing impact analysis, deduplicating findings, and supplying validated fixes where maintainers want them.

Interestingly, Dusch reports he has not been flooded with requests to help process reports. The reason is encouraging. Maintainers say the quality of the security reports they receive has climbed sharply over the last several months, and many now run their own coding agents to validate and reproduce findings. Where the team adds the most value is the hard cases: complex vulnerabilities where off-the-shelf AI models either cannot help or outright refuse to assist with building a proof-of-concept exploit. That is exactly the gap a funded, trusted team can fill.

PHP itself is a special case. Because it is so popular, lots of people point their shiny new security tools at php-src, but a language runtime is far more complex than a typical userland library. The threat model is murkier and the attack surface is enormous, so agentic scanning produces noisier, lower-quality results there. Dusch notes he has not yet been able to help core PHP much due to time constraints, but plans to spend significantly more effort on php-src and extensions in the coming months.

Scrutineer: The Shared Tooling

Scanning hundreds of projects reliably is its own engineering problem. You need reproducible outputs, low false-positive rates, isolated and containerized execution so the scanning infrastructure stays secure, and the ability for multiple people to run agents in parallel without babysitting them.

To solve this, the team is collaborating with Ecosystem Security Engineers from other language communities and with Alpha-Omega on a shared tool called Scrutineer. It gives the effort structured results and a cleaner reporting pipeline, and it lets contributors who have access to different AI models or more compute capacity run scans on the team’s behalf. Crucially, the containers can be tailored toward the PHP ecosystem specifically, which improves result quality by building and validating reproducers automatically. Without that automated feedback loop, report quality drops and cleanup work balloons.

This is the part I find most promising for the long term. A PHP-tuned, container-based scanning tool that survives past the grant window is infrastructure the community can keep using regardless of who is staffing the team.

Why This Matters for Your composer.json

You do not have to maintain a popular package to benefit. The fixes landing across those 300-plus packages flow downstream into every application that depends on them. The practical takeaways are familiar but worth repeating in this context. Keep your dependencies current so you actually receive these fixes:

# See which of your dependencies have known advisories
composer audit

# Check what is outdated, direct dependencies only
composer outdated --direct

composer audit checks your installed packages against the PHP Security Advisories Database, and it belongs in your CI pipeline so a known-vulnerable dependency fails the build rather than reaching production. If you maintain a package yourself, the team has explicitly said it has capacity to scan and help more maintainers, so reaching out is worth it.

How to Get Involved

The team gathers in the #ecosystem-security channel on the phpc community Discord, where Dusch is reachable as @edorian. For sensitive disclosures, he can be contacted directly by email. He also called out specific contributors: Graham Campbell for early help with issue validation, Alexandre Daubois from Les-Tilleuls.coop for valuable work on Scrutineer, and Ilia Alshanetsky, who has joined the team to coordinate his independent security work.

Looking ahead, the stated goals for the next month are to scan another 250 projects and report the findings, perform deeper analysis of core projects and libraries, and put real time into php-src and extension issues.

It is easy to be cynical about security theater, but this reads like the opposite: concrete numbers, honest caveats, named contributors, and shared tooling meant to outlive the funding. For a language ecosystem as large as PHP’s, having a dedicated, transparent, well-resourced team doing this work is exactly the kind of investment the Foundation exists to make.