Running an open source registry means fighting fires. Another maintainer’s account gets popped, another malicious package. The takedown is always one upload behind. The job never ends, and most registries, run by small teams with little cash, are often too stretched to do much beyond keep up with it. But lately, we’ve been seeing more positive changes in the open-source world, with ecosystems making the structural changes that stop a kind of attack from working at all.

The small team that maintains Packagist.org and Composer, the registry and package manager behind the PHP world, has been doing deliberate, preventative security work and making meaningful improvements. Aikido is a big supporter of the effort. Aikido’s Intel feed powers malware blocking in Composer for downloads. It’s enabled by default for Composer 2.10 and higher for everyone. This sits alongside a stack of other changes Packagist made and is making, each one working to end entire categories of attacks instead of chasing single packages. 

We’re starting to see this trend of improvements across package registries, and we’re excited to be able to support these initiatives. PHP developers can rest easier now, knowing there are more guardrails in place to prevent them from accidentally installing malware. 

Malware blocking in Composer

The easiest win is to prevent users from installing a package version that is already known to be malicious. Thanks to Aikido Intel, Composer now knows which versions have been flagged and won’t install them. 

When Aikido flags a malicious package version, that flag lives inside the package metadata Composer downloads. Composer 2.10's dependency policy framework pulls the flagged version out of the resolution pool, so `composer update`, `composer require`, and `composer create-project` won't select it. The most important check is the one on `composer install`, because a version flagged after your lockfile was written fails on the next install. If, for some reason, a user still wants to download a blocked package, they can manually override it.

This integration works because it's:

• Open: The feed Aikido provides to Packagist is CC-BY licensed, so the protection isn't tied to a six-figure contract, and the door stays open for other data providers to plug in. Security that only the well-funded can afford doesn't protect us.
• On by default: A protection that needs people to opt in protects almost nobody (because it's hard to get people to opt in). Defaults are where ecosystem security lives, and the 2.10 default requires nothing from users for them to benefit.
• Fast enough: Malicious versions usually get taken down within a few hours, so a feed that flags them in minutes protects users in the window between detection and removal. Because the block only works when something is detected, slow detection wouldn't help much.
• Automated: Because the malicious package gets blocked as soon as Aikido detects it, there’s no extra delay in waiting for someone to manually blacklist or remove the package, so users are protected faster.

Wiring Aikido’s detection into every install was just one of the improvements Packagist has shipped recently.

Closing doors instead of patching holes

Next, re-tagging. Publishing to Packagist has always meant pushing a git tag, and the registry pulls whatever that tag points at. That system allowed attackers who hijacked a trusted account to re-tag a published version and point it at malicious code, so that version number now carries some payload (which we saw in the recent attack on Laravel-Lang). Packagist's answer, stable version immutability, means a published stable version can no longer be rewritten. That ends the re-tagging attacks as whole. GitHub has the equivalent, but they made it opt-in. Packagist made it mandatory.

Finally, trying to get people to update software is like pulling teeth. A default block only helps the people running a current Composer, and many people aren’t. A CI image or an AI agent often runs a version from years ago, so Private Packagist can require a current Composer to connect. It also refuses to serve a flagged version's files to any client at all, old or new.

Packagist.org isn’t done yet, and they have a few security improvements coming. They’re planning a minimum release age, which would blunt attacks that rely on a short window before detection catches up (in the meantime, you can get similar protection with Aikido Safe Chain, also free). They’re also creating organizational ownership, which will allow for mandatory MFA, as well as staged releases, which npm recently shipped.

Moving toward safer package registries

This is not only a PHP story. As we mentioned, npm is moving the same way with staged publishing, but also turning off automatic install scripts. PyPI made 2FA mandatory and built a quarantine system, and crates.io and RubyGems adopted trusted publishing through a shared OpenSSF design. Ecosystems are moving in the right direction. We want to see a lot more of it, faster, and we keep supporting where we can. 

Are you a PHP developer? Composer clients older than 2.10 don’t have this feature, so make sure you update today if you haven’t. Not using PHP? Aikido Safe Chain is an open-source tool that also prevents you from installing new or malicious packages before they get installed on your device.

Regardless of the ecosystems you depend on, you can check out what Aikido Intel is flagging across the interwebs. The feed is public and free at intel.aikido.dev.