Questions from the Front Lines
After the Laravel-lang and Intercom compromises hit Packagist in April and May 2025, procurement Slack channels and TPRM team meetings buzzed with questions. These attacks followed a familiar pattern: stolen GitHub tokens, rewritten git tags, and malicious code pushed as "updates" to legitimate packages. What set these incidents apart was the rapid response and subsequent policy changes.
The questions below reflect what sourcing and procurement teams are asking as they translate open-source security improvements into vendor intake and continuous monitoring practices. The answers highlight capabilities in Composer 2.10 and changes on Packagist.org.
Q1: We source a lot of PHP-based SaaS tools. Should we care about what Composer is doing?
Yes, if your vendors use PHP frameworks or consume packages from Packagist.org. The security of the dependency manager your vendors use directly affects your organization's exposure to supply chain incidents.
Here's the connection: when a vendor's development team pulls a compromised package, that code can end up in the SaaS product you're paying for. The Laravel-lang incident on May 22, 2025, demonstrated this risk. Attackers modified existing git tags after publication, bypassing traditional supply chain controls because the version number stayed the same while the code changed.
Composer 2.10 introduces a dependency policy framework covering malware-flagged versions, vulnerability advisories, and abandoned packages. This framework is crucial for vendor assessments, allowing you to ask: "Which version of Composer do you run in CI/CD, and do you enforce dependency policies?" Vendors still using pre-2.10 versions lack this unified policy engine.
Q2: What's this "minimum release age" policy, and should we require it in contracts?
The minimum release age policy, or cooldown period, lets development teams configure Composer to refuse any package version published less than a specified time ago. With a 48-hour cooldown, composer install will skip versions released yesterday, even if they're the latest.
This policy isn't in Composer 2.10 yet, but it's the next addition to the dependency policy framework. The delay is intentional: Packagist.org needs to make release timestamps reliably immutable before Composer can treat publication time as a security input.
Should you include it in contracts? Not yet, since the feature doesn't exist. However, you can discuss it in vendor security roadmaps. Ask vendors: "Once Composer supports minimum release age policies, will you enable them, and what cooldown window makes sense for your release cycle?" A vendor that ships twice a week can reasonably run a 72-hour cooldown. A vendor that ships daily may struggle with anything over 24 hours.
The trade-off is clear: longer cooldowns give the ecosystem more time to detect and pull malicious releases. The Laravel-lang and Intercom compromises were flagged and addressed within hours, meaning even a short cooldown would have blocked them.
Q3: How do we verify that a vendor's packages can't be silently rewritten?
Check if they're pulling from Packagist.org and confirm that stable versions are immutable. As of this week, Packagist.org rejects upstream re-tagging of non-dev versions. If an attacker force-pushes a git tag to rewrite version 2.3.1, Packagist.org detects the change and refuses to update its metadata. The package maintainer gets an email notification instead.
This matters because immutability eliminates an entire class of attack. Before this change, attackers could modify existing versions without changing version numbers, causing SBOM tools, security scanners, and mirrors to hold different data for the "same" release. Now, once a stable version is published, it's locked.
During vendor intake, ask: "Where do you source your PHP dependencies, and does that repository enforce version immutability?" If the answer is a private mirror or an internal Packagist instance, ask whether it mirrors Packagist.org's immutability rules. If they're running Private Packagist, the answer is yes; the same protections apply.
Q4: What's in the transparency log, and can we build monitoring on it?
The Packagist.org transparency log records package ownership changes, maintainer additions and removals, and changes to version references. It's public (login required) and accurately recorded the git tag modifications used in recent attacks.
For continuous monitoring, the log provides an audit trail for any package your vendors depend on. If a critical package suddenly adds a new maintainer, or if version references change unexpectedly, those events appear in the log with timestamps.
Practical use: if you're monitoring a vendor's supply chain as part of your Fourth and Nth Party Management process, you can query the log for packages in their SBOM. Set up alerts for ownership changes on high-criticality dependencies. The Packagist team is open to API discussions for integrations; contact them at [email protected] if you're building tooling.
The next expansion of the log will include MFA-related events: when maintainers enable or disable multi-factor authentication, when recovery codes are used, and similar account security actions. This data will be public in about six months.
Q5: Should we require vendors to enable MFA on their Packagist accounts?
Yes, and Packagist.org is moving in that direction. MFA is not yet mandatory across all accounts, but the direction is set. Within six months, MFA status will be visible on maintainer profiles, and MFA events will appear in the transparency log.
This visibility shift changes the conversation. Today, whether a package maintainer uses MFA is private information. Soon, it will be a property of the package that anyone can inspect. Downstream consumers (including your vendors) will be able to see whether the people behind a dependency have MFA enabled.
For vendor intake, add this question now: "Do all maintainers of packages you publish or contribute to have MFA enabled on Packagist.org?" If the vendor uses a shared company account, flag it. Shared accounts are a known problem, and Packagist.org is building Organizational Package Ownership to replace them with proper multi-user management.
When MFA becomes mandatory (no fixed date yet, but it's coming), vendors without it will lose the ability to publish updates. Give your vendors advance notice so they can enable MFA without scrambling at the deadline.
Q6: How do we know if a vendor's dependencies are flagged as malware?
Packagist.org imports malware detection results from Aikido. When a version is flagged, the warning appears in the Packagist.org UI and in the package metadata Composer consumes. Aikido flagged the malicious versions in both the Laravel-lang and Intercom incidents.
Composer 2.10's dependency policy framework means vendors can configure how to handle flagged packages: block installation entirely, allow with a warning, or ignore. During vendor assessments, ask: "What's your dependency policy for malware-flagged packages?" The correct answer is "block" or "allow with manual override and incident escalation."
If a vendor is still running Composer 2.9 or earlier, they don't have access to the unified policy framework at all. That's a gap worth documenting in your risk register, because it means they're relying entirely on manual review to catch malicious dependencies.
Where to Go for More
Composer's release announcements cover dependency policy configuration in detail. The Packagist.org transparency log is at Packagist.org (login required). For vendors running Private Packagist, follow-up posts on organization-wide supply chain controls are coming this week.
If you're building continuous monitoring tools on top of the transparency log, reach out to the Packagist team directly. The API for the log is still taking shape, and practitioner input will influence what gets exposed.
