Anna Filina

Composer Security Checker

June 9th, 2015

Stefan Priebsch made some very interesting points in his IPC talk about dependencies. Someone in the audience asked how often should we update our dependencies. Stefan recommends not to touch dependencies if everything is working and only monitor for security updates. However, monitoring security updates for a big dependency tree would be tedious.

Here comes my idea for Composer: package developers can mark release as "security" and then Composer can implement a check-security command. This way, developers can periodically (or even automatically) check for security patches to any dependencies, decide if they affect them and whether they would like to update that dependency.

I think that it would be of great benefit for the PHP ecosystem.


Speaking with Hans-Christian Otto, we came up with an idea that would not entirely rely on package maintainers. The package maintainers could mark versions as security patches, then we can sync that info into the security-advisories, to complement the efforts of the contributors. It might be easier for package maintainers to add a tag in their Composer file that to send pull requests.


Jordi Boggiano June 9th, 2015 This is already possible to some extent using either the security checker tool at or by requiring the roave/security-advisories package and then doing a partial update of it like `composer update roave/security-advisories`, that would then let you know if you're using anything that has a security vulnerability. The latter might not scale extremely well though we'll have to see how that evolves. Down the line though it highly depends on people reporting which versions of their packages are vulnerable. At least these tools allow for crowdsourcing of the information (and they both use the same data source).
Stephan Hochdörfer June 9th, 2015 Shameless plug: If one likes Phing I built a Phing task to query the Security Advisories Checker webservice:
Johannes June 9th, 2015 Too often I have seen (not only in the PHP world) that people don't upgrade and then start to manually backport individual fixes as they can't verify the proper update anymore, so by time they end up with a set of forked libraries to maintain.

I think it is vital to have a proper update process where updates can be verified and implemented with as little effort as possible to allow frequent dependency updates. This affects not only libraries used but the complete stack - from operating system and runtimes vi code and libraries to build tools etc. being used. Everything else leads to rusty dinosaurs.
Anna June 9th, 2015 It just gives devs more flexibility: they want to control when they upgrade. Since package maintainers already know that they just released a security fix, it would make sense for them to report that by tagging as "security".

I think that when it comes to security, it shouldn't be either/or. We can use all tools at our disposal and I think that this one is not very hard to do. I can help with the Composer code/documentation to make it happen.
Johannes June 9th, 2015 I don't see the big difference. If I don't have the infrastructure and process to verify an updated library quickly I also can't verify an security fix. Additionally: If I don't have a process to update libraries often I have outdated libs and therefore a big update in a critical moment.
Christophe Coevoet June 10th, 2015 Just flagging a release as security is not enough IMO. A security issue fixed in a release may not affect all older versions of the package. So the fact that there is a new security release does not mean that your own project not using it is affected at all.
This is why the security-advisory database contains a list of affected versions for each advisory.
Peter Petermann June 10th, 2015 I kinda disagree with Stefan. Make sure your dependencies follow semver, and update on a regular basis (before you start your own release process for example)

This page is protected by reCAPTCHA and the Google
Privacy Policy and Terms of Service apply.

Phone: +1 514-918-7866 | E-mail: