Don't use PHP libraries with known security issues

Fabien Potencier

February 19, 2013

If you are a "connected" developer, you are probably aware of the major vulnerabilities found in Ruby on Rails recently. To be fair, we've also found some serious issues in the Symfony code during the last few months.

As security management should be a top most priority for us and our customers, I've recently worked on improving the current situation in the Symfony world, with an enhanced security process. But security management is also a very important topic for me because Symfony is quickly growing in popularity for both end-user projects and Open-Source ones; and more exposure also means more interest from the "bad guys".

One of the goal of good security issues management is transparency. That's why the Symfony project has a simple way of reporting security issues (via the security [at] email address), an easily accessible list of security advisories, and a well defined blog post template to announce security issues. Recently, we have also enforced the need to have a CVE identifier for all security issues to help the broader community to be aware of Symfony security issues.

The best advice one can give you is to upgrade your favorite libraries as soon as possible when new versions with security fixes are released. Easier say than done.

How do you know that a new release is out? How do you know that it contains security fixes? For Symfony, you can subscribe to the RSS feed of the Symfony blog, or you can have a look at our security advisories from time to time. But sometimes, that's not possible as the project does not even have a blog. Was the security fix announced on Twitter? Quite possible. But most of the time, smaller libraries just release a new version without any proper security announcement.

But I want to provide a simple and efficient way to check for vulnerabilities in a project and I want to serve more than just the Symfony community. That's why I'm really proud to announce a new SensioLabs initiative: a simple way to check if your project depends on third-party libraries with known security issues. The website explains how it works in details (, but basically, this initiative gives you several ways to check for security issues in your project dependencies based on the information contained in you composer.lock file (you are using Composer to manage your dependencies, right?):

  • The website itself allows you to upload a composer.lock to check for vulnerabilities;

  • A web service can used with curl or to integrate that tool into your own continuous integration process (it returns its results as plain text or as a JSON array);

  • A command line tool gives you the same feature as the web service and the website but nicely packaged as a simple Symfony command.

Of course, the most important part of this initiative is the database where known security vulnerabilities are referenced. The database is hosted on Github: We have already referenced known vulnerabilities for Symfony, Zend Framework, and some well-known Symfony bundles, but the idea is for the community to help us add more libraries and more importantly to update the database whenever a security issue is fixed in a library. Even if you don't have a way to easily announce your security fix to the world, at least, reference it in the database; contributing to the database is really easy: fork the repository, contribute your changes, and send a pull request (you can even do everything from the Github web interface if you want).

Check your projects, upgrade your dependencies when needed, and contribute to the database!


gravatar Jordi Boggiano  — February 19, 2013 16:56   #1
Definitely a good initiative. And one more incentive for people to use tagged releases (and for devs to tag more!), because dev versions are kind of impossible to check for vulnerabilities as git commit hashes are non-sequential.

Just an idea regarding using this on a regular basis, is to hook it as a post-update-cmd listener in your composer.json (see example at Obviously that requires everyone running composer update to have this installed and available globally, but at least you'll see any security warning every time you update your dependencies.
gravatar Jimmy Henderickx  — February 19, 2013 17:10   #2
Great initiative!

We'll definitely implement this in our monitoring infrastructure to keep track of our live projects' security status.
gravatar Steven Leggett  — February 19, 2013 17:18   #3
Hi Fabien,

Glad to see someone thinking about this with a broad scope.

RE: project
While I do think your efforts in this case are welcome and helpful, I don't think this is particularly the right approach.

I do believe PHP needs a standardized method of defining what version is being used, in the actual application. I believe this should be part of PHP itself. So you can basically do the following anywhere, in any app:
cd app
php -app -v
WordPress 3.5.1

Or via the plugin itself:
cd app/wp-plugins/myplug-1.2.3
php -app -v

PHP applications need to have a standardized version, maybe in a .json maybe something else, to ever really make progress in this area.

If PHP ever gets to this point, we can very very easily create something to get all or our app and plugin versions (that are right off the server and now based on the composer file) to compare directly for things like security issues on CVE.

While composer is great, it's not used everywhere - some people haven't bothered. Just consider pre-installers of applications or frameworks (no composer), like AWS, Fantastico! and other server side installers widely used.

What are your thoughts?
gravatar Leo P  — February 19, 2013 17:22   #4
Timed perfectly as I stumbled upon this : the other day.

gravatar Tobias Sjösten  — February 19, 2013 17:38   #5
Very nice!

Every one of these steps of PHP goodness seems so well orchestrated. I'm curious to know — how long have you planned this service for? :)
gravatar Fabien Potencier  — February 19, 2013 20:47   #6
@Jordi: Actually, we do check for security vulnerabilities even if you are using a branch as we rely on date comparisons in that case between the date of the sha you are using and the date of the fix for the vulnerability (that's why we have very precise dates for resolution dates in the database).
gravatar Khayrattee Wasseem  — February 20, 2013 07:11   #7
Mr Symfony Super-man, kudos! #awesome
gravatar Lukas Kahwe Smith  — February 20, 2013 10:17   #8
Looks like LiipMonitorBundle will soon have support too
gravatar Pascal Borreli  — February 20, 2013 18:20   #9
@Jordi: what about adding this security check to composer itself ? at every check or using a special command ?
gravatar Daniel Ribeiro  — February 21, 2013 15:11   #10
Very good article.

Thanks a lot Fabien.

And thanks to Jordi as well, for the tip on the composer hook.
gravatar Matthias Gutjahr  — February 22, 2013 09:28   #11
The LiipMonitorBundle looks great, love it. I also created a Bundle that puts vulnerabilities info in the debug toolbar, please check it out:
gravatar Jean-François Lépine  — March 01, 2013 19:17   #12

that's a very good initiative !

I've developed with the same approch. I think it would be great to merge all services directly into composer...