Lukas Kahwe Smith recently brought forward an idea to PHP-FIG with two broad objectives for a new PSR:

1. To write a security policy that could be adopted by members; and
2. A proposal to make sharing security vulnerabilities more common and standardised.

He has invited interested people to express their interest in joining a separate mailing list to discuss the details:!topic/php-fig/45AIj5bPHJ4

Larry Garfield of Drupal and Korvan Szanto of concrete5 CMS have offered to sponsor the proposal.

Security Policies

A security policy is essentially a plan of action, where you lay out your expected responses to a reported vulnerability (and your expectations of all parties’ behaviour) in a document for easy reference by your contributors, security reporters and users. An extremely short example:

Will confirm issues; Will fix them consistently; Will inform users when fixed.

A security policy can be as simple or as complicated as you wish, so long as you don’t forget these three core statements. A common problem in PHP open source is when you have a project where a) there is no security policy published and b) the contributors clearly have no informal security policy that they can explain. When both of these points are true, trust becomes an issue. Usually, it can be illustrated by sending in a batch of reports and monitoring the response. When you come back months later and the fixes are still pending despite one or more follow ups, then you simply never use that project. This is ignoring that you had a “batch” to start with ;) .

I like Lukas’ proposal for a standardised security policy in some form since it would help create shared community expectations. Projects can adopt it as a best practice. Security reporters can refer to it to set expectations of projects. Users can rely on it as evidence that a project does actually have a plan of action in the event of vulnerabilities being reported or discovered.

Also, it would just save folk time trying to write their own. All you’d need to put somewhere is “we follow PSR-X” with a reporting email, e.g. your Github README. It doesn’t get any simpler ;) .

Standardised Vulnerability Data

You’ve just adopted an <80 character Security Policy suggested by some lunatic on the internet, and you’re now wondering how to inform users of security vulnerabilities. If you have a website, you might publish a regular blog and RSS feed. If you’re stuck with Github, you might label or prefix commit messages. Email might not be a bad idea. We’ve just mentioned four specific disclosure routes and we can already assume that most users might never become aware of a disclosure. Wouldn’t it be easier to just push the information down to them more consistently?

It’s not an impossible task for the future, but it does rest on the notion that vulnerability data will be available in some agreed format containing specific data. Those with blogs might decorate their feeds appropriately, and those reliant on a simple git repository might just push disclosure data to a basic JSON/YAML file.

What would be achieved through such a practice, is to create lots of vulnerability disclosure data, in standardised formats, that future services and tools could then aggregate and summarise for users based on their known project dependencies. I hesitate to bring Composer/Packagist into the equation, but something along those lines scanning installed (or declared) dependencies for vulnerable versions would be ideal.