This is a branch off from a separate discussion on the PHP-FIG mailing list about other ways the Framework Interoperability Group can encourage and foster wider interoperability among its member projects (and by extension, the whole PHP community). I’ll start by noting two interesting developments in recent months and one long standing best practice.

1. Launch of the SensioLabs Security Advisory Checker

You manage your PHP project dependencies with Composer, right? But are you sure that your project does not depend on a package with known security issues? The SensioLabs security advisories checker is a simple tool, available as a web service or as an online application, that uses the information from your composer.lock file to check for known security vulnerabilities. This checker is a frontend for the security advisories database.

The service operates by having people submit vulnerability data, as YAML files, to a centralised Github repository through pull requests. The upside is that the vulnerability data can be peer reviewed and centrally dispersed either online or via a service API. The downside is that you need to find vulnerability disclosures and people to submit them. The service currently covers Symfony, Zend Framework, Doctrine, Twig and FriendsOfSymfony bundles. It’s a tiny sample of packages available through Composer. I’m also not entirely sure if it’s sufficiently fine grained to report vulnerabilities on a project’s sub-packages where you have no direct dependency on the aggregate package (e.g. using zendframework/zend-db instead of zendframework/zendframework). That said, this is a working model of a service for checking your dependencies.

That said, the service exhibits an ambitious idea – projects sharing their vulnerability disclosures or advisories in a way that allows for automatically checking if any of your projects need to have their dependencies updated for security reasons.

2. OWASP‘s Top 10 security risks for 2013 includes “A9 – Using Components with Known Vulnerabilities”

This is a new entry onto OWASP’s Top 10 (which is currently at release candidate status for 2013). In summary, it recognises that applications are becoming ever more dependent on code not developed internally. We’ve had web application frameworks for years. Composer and Github have unleashed a storm of accessible libraries, bundles, modules, and other units of reuse that have revealed Not Invented Here (NIH Syndrome) as a psychological problem in ways not previously possible.

As reliance on externally controlled dependencies increases, so too does the risk of your applications using insecure dependencies. This is a risk that requires a lot of work to mitigate. For each dependency, you need to do a security review (no, I’m not kidding), check for security disclosures (whether voluntary or involuntary) and ensure that you end up rolling out to production with safe versions.

Quoting from the OWASP advice on preventing the use of components with known vulnerabilities…

One option is not to use components that you didn’t write. But realistically, the best way to deal with this risk is to ensure that you keep your components up-to-date. Many open source projects (and other component sources) do not create vulnerability patches for old versions. Instead, most simply fix the problem in the next version. Software projects should have a process in place to:

1. Identify the components and their versions you are using, including all dependencies. (e.g., the versions plugin)

2. Monitor the security of these components in public databases, project mailing lists, and security mailing lists, and keep them up-to-date.

3. Disclosing security vulnerabilities in a timely and responsible manner is a best practice

As programmers, we have a responsibility to users to disclose security vulnerabilities and fix them in a timely manner to ensure that those users are protected from harm. It’s almost impossible not to end up in such a situation at some point in your career. In fact, it may even be impossible for it not to happen multiple times in a single year!

The sad truth, however, is that disclosing security vulnerabilities can be terribly hit and miss. I’ve seen people ignore vulnerabilities or fix them but fail to disclose the fact to their users. Opinions over the severity of a vulnerability can vary dramatically within even a small group of programmers. Nobody likes to air their dirty laundry in public but not doing so can mean someone including a dependency with a known vulnerability without any means of becoming aware of that vulnerability.

It is always a good thing to come clean. Fixing a vulnerability, disclosing it, and having a good security policy in place prevents the reputational damage you might suspect would occur. It’s usually the secretive rollout of fixes that gets you in trouble when someone is attacked or the reporter discloses the vulnerability through other means (usually making note of your refusal to come clean).

The method of disclosure is usually in release notes, commit messages, blog posts or emails. This article suggests using formats that are more fundamentally consumable and standardised.

Centralised Tracking Of Decentralised Vulnerability Data?

Being aware of these three, we can see the immediate value in something like SensioLabs security advisory checking service. You have dependencies which very likely have had or will have vulnerabilities, and you probably would love to know about those before releasing a new project build to production servers. The problem is that this involves work in importing vulnerability data into the checking service and, failing that at present, a trawl of the internet for vulnerability disclosure blog posts, commit messages and emails. What would happen if, as a means of improving interoperability and common security, more vendors published their disclosures at fixed URIs in just one or two easily consumable formats (e.g. YAML or RSS/Atom)?

For example, instead of relying on someone submitting a pull request to SensioLabs each time Library X discloses a vulnerability, one could simply store a URI to Library X’s disclosure feed and/or a YAML formatted summary stored in its git repository. The SensioLabs service, or something like it, could now pull in vulnerabilities automatically assuming Library X uses a predetermined consumable format. This sounds, at least to me, as a more sustainable system.

If a sufficient number of packages on Composer followed this practice, we’d have something quite brilliant and possibly easier to promote in the community. People are now very familiar with maintaining a composer.json file. Adding one more file, in lieu of an alternative RSS/Atom feed, is not that big of a stretch if enough projects request it of their dependencies. The rest would be down to the boring work of agreeing formats, procedures and other technical aspects with a view towards, *if* called for, a PSR on the topic.

Let me know what you all think in the comments or catch me on the PHP-FIG mailing list.

That way composer could automatically factor unsafe versions into its version matching algorithm, and link to vulnerability reports without package maintainers needing to follow a specific format.

Mind you, I really like the sensiolabs checker too!

Tim Fountain

Could a basic version of this be built into composer itself? So if ZF released a security fix, they also update their composer.json to add an entry in a specific format that defines what version(s) of the package had the vulnerability, along with an optional description and ‘more details’ URL. Composer could warn uses of that package when they run update or install if they’re running a version with a known vulnerability.

https://www.lazycat.org/ Matt Robinson

Hah, jinx!

http://blog.astrumfutura.com Pádraic Brady

That’s actually a really good idea. I’ll keep it mind when I get around to practical action

Anonymous

One thing I’d thought about was using the Github issues themselves to track security issues. Some tool that could look for a tag on the issues (maybe “security” or “vulnerability”) and populate the system with that. Puts the burden back on the developer of the library.

I’m open to the idea of trying to supply a PR myself, though I’m sure there are others better suited to the task

Tim Fountain

Seems we both had the same idea. The comments on the Github issue suggest it wouldn’t be straightforward though. It sounds like Composer only keeps meta data for the version your app is using. So let’s say you have Composer setup to use a specific version of ZF like 2.0.5. A security issue is found in that version and so Zend release 2.0.6 and add 2.0.5 to the composer.json ‘blacklist’. Your app won’t know about this because it’s only looking at the composer.json that was released with 2.0.5.

https://www.lazycat.org/ Matt Robinson

That’s right; apparently it doesn’t really suit the way that Composer currently works; although I wonder if the approach might still have value in selecting a version in Composer’s version-resolution during install; not just for security but also for versions that are bad/broken for other reasons…

Pádraic has opened a thread on the PHP-FIG mailing list about an alternative approach, which involves publishing an advisories.json file, which I think has some merit: https://groups.google.com/forum/?fromgroups#!topic/php-fig/lRBco1JcNzg

https://www.lazycat.org/ Matt Robinson

It does, and that’s cool, but it’s very Github-centric, which makes me a little nervous (I’ve been skittish ever since Google shut down Reader). Also, many GitHub-hosted projects use external issue-trackers (like the Doctrine packages).

The other concern I have is that some package maintainers may be embarrassed/reticent about publishing vulnerabilities. Obviously that’s wrong, but there’s also a lot of value in centralising reports (like the CVE list, or Sensiolabs’ security-checker).

I was
excited to find this web site. I need to to thank you for your time due to this
wonderful read!! I definitely savored every little bit of it and I have you
bookmarked to check out new things on your web site.