How to manage vulnerabilities in your PHP dependencies

That makes a lot of sense when you think about it, why should an attacker waste time trying to figure out a way of attacking a specific web application, when they can just try a known vulnerability for a popular framework such as Symfony or Laravel en masse?

Detecting PHP security flaws

Luckily, these vulnerabilities are typically responsibly disclosed nowadays. Meaning that the person discovering the vulnerability informs the package maintainer in secrecy so they have a chance of fixing the vulnerability before it is made public. This leads to that when a vulnerability is announced, there is often a safe version already available of the vulnerable dependency.

So, in theory, you just need to keep your dependencies up to date at all times and you should be fine. While this might be a valid strategy for a small hobby project, as your project grows it is typically not possible to stick to the latest versions of your dependencies because of breaking changes. Also, there is always the risk of dependencies becoming unmaintained with known security flaws.

Avoiding PHP vulnerabilities

To avoid these risks you must proactively gather information about your open source dependencies and their potentially security vulnerabilities. Here are a few free ways of gathering this information:

Manually checking vulnerability databases

The most time consuming and error prone option. You can manually check vulnerability databases for known vulnerabilities.

Good sources for PHP vulnerabilities are NVD, GitHub Advisory Database and FriendsOfPHP’s security advisories or our own Debricked Vulnerability Database, which combines all three sources into one. You should monitor all these three databases (or just Debricked’s database) regularly, preferably daily, as to avoid near zero-day attacks.

While it is fairly easy to keep up to date with GitHub’s and FriendsOfPHP’s advisories, it is a lot harder to keep up with NVD’s steady stream of new vulnerabilities.

Vulnerabilities from NVD also has a tendency to be badly and inconsistently tagged, meaning it is easy to miss a vulnerability simply because e.g. the vendor was specified slightly differently from your search query.

Additionally, it is worth keeping in mind that it is not enough just checking the dependencies you require yourself, you need to keep track of “indirect dependencies” as well, in other words, dependencies of your dependencies.

A fair sized repository typically has hundreds, if not thousands of dependencies, making for a very daunting task.

When you have found a vulnerability for one of your dependencies, you will then have to see if there is any fix available, typically involving updating to a newer version of the vulnerable dependency.

As a last step you will have to implement the fix by modifying the version in composer.json, updating your composer.lock file and finally commit and push the changes. A process, while not often complicated, is very tedious, and can definitely be automated.

Using local PHP security checker

Instead of trying to keep check of potentially thousands of dependencies you can use the freely available Local PHP Security Checker. It is a handy command line tool written in Go which analyses your composer.lock file for any known vulnerabilities found in FriendsOfPHP’s security advisories.

The reliance on this single source is also one of its biggest weaknesses, while the FriendsOfPHP database contains a lot of PHP specific vulnerabilities, it doesn’t give complete coverage.

At the time of writing, it only contains 750 vulnerabilities, while there are an additional 188 and ~4000 vulnerabilities (some overlapping) to be found on GitHub’s Advisory Database and NVD respectively.

You still also have to do the tedious process of actually updating your dependencies to safe versions.

In order to be proactive with your security, you will have to add the command to your devops life cycle. This could, for example, be done using a Composer script or adding the command to your CI. In that way you will be notified of any existing vulnerabilities you may have. 

Unfortunately there is no great way of managing the vulnerabilities you find. Either you have vulnerabilities (status code 1) or not (status code 0) from the command (local-php-security-checker).

Using Debricked to manage your PHP security issues

By using Debricked you get instant access to a very large vulnerability database. Our database combines and refines all the previously mentioned sources, NVD, GitHub Advisory Database and FriendsOfPHP’s security advisories, into one big database. Removing any possible duplicates, providing you with less noise, but still giving you all the information in one place.

We also provide ready to go integrations for all the popular CIs such as GitHub App/Actions, GitLab CI, BitBucket Pipelines, Azure Pipelines and many more. You can view the full list in our documentation.

In combination with our Automations Engine’s default rules, you will automatically be able to stay on top of your security issues. By e.g. only getting notifications for vulnerabilities which exceeds a certain CVSS score. In addition, you will also be able to use our license feature at the same time if you so desire.

In the near future we will also extend our automatic fix pull request feature to the PHP language. Taking out the tedious work of manually updating your dependencies to safe versions. Giving you a complete vulnerability management solution.

Convinced? Head over to our signup to start scanning, it only takes a few minutes to set up and it is free!