1

Some of my apps use more than 30 composer packages.

Using all these packages got me thinking, what if some of them discover a critical issue that needs updating, I can't just manually recheck them all every day.

Please note that I don't want to update just for new features when in production, only want to do critical updates, so I can't just check if there is a new version out.

I thought of using minor patch numbers for these, but I don't think that's enough since some packages do not provide security updates for old versions.

My question is:

Is there a simple way to keep an eye on all these packages to know if there is a critical security issue or bug that needs updating? (maybe there is a flag option I'm not aware of, to only update packages flagged as "ciritical-bug-fix"?)

Do you professional guys just require packages and forget they are there once you reach production?

P.S. I heard we shouldn't really run composer update in production, so in case of a critical update how should we proceed?

Community
  • 1
  • 1
J. Doe
  • 812
  • 1
  • 15
  • 33
  • 2
    There are some tools to scan for this sort of stuff, but they are only as good as the definitions. https://github.com/sensiolabs/security-checker – Alex Barker Feb 15 '20 at 02:29
  • 2
    Generally, you'd want a CICD pipeline where, in the case of an update, you update on your build server which then runs unit tests against your code. Tests failing would prevent the build from passing which would then prevent it from being pushed to production, thus, saving you from deploying any updates that break your existing code. – Matthew Anderson Feb 15 '20 at 02:31
  • 1
    @AlexBarker Thanks, that website (https://security.symfony.com) seems really cool, apparently I upload my composer.lock and they notify me if there is security vulnerability in any of my packages. – J. Doe Feb 15 '20 at 03:02
  • 2
    "I heard we shouldn't really run `composer update` in production, so in case of a critical update how should we proceed?" You run `composer update` on your development machine, run your tests, and then commit the `composer.json` __and__ `composer.lock`. You can then run it through CICD, or merge the commit into master, and make a release. Pull the release onto production and run `composer install --no-dev` to update/install packages to the tested versions set in your lock file. – HorusKol Feb 15 '20 at 03:49
  • Others have given good advice, but I would also interject that if a project requires 30 composer packages, this is a problem in and of itself: it has gone WAAAY past optimal for security and efficiency. Perhaps it is time to pare down the dependencies, cutting out features or "reinventing the wheel" in a few cases if necessary. – cazort Jul 28 '21 at 19:07
  • 1
    @cazort If you only install Laravel and do nothing else, that gets you to over 30 composer packages (its dependencies are huge). – J. Doe Jul 31 '21 at 03:38
  • @J.Doe Yes, and that's a great example of why I don't use or recommend Laravel; their history of security holes is not anywhere near as bad as some frameworks and they're usually quick at patching them, but it's still something I don't recommend, see: https://www.cvedetails.com/vulnerability-list/vendor_id-16542/Laravel.html and https://snyk.io/vuln/composer:laravel%2Fframework – cazort Jul 31 '21 at 19:01
  • Similar, duplicate (?) question: https://stackoverflow.com/questions/39090770/tool-to-check-known-vulnerabilities-in-php-project-using-composer – Sybille Peters Dec 06 '22 at 06:53

1 Answers1

4

Since Composer v2.4 there is an audit command, that reports dependencies with security issues:

composer audit

example of composer audit output

The audit command returns the amount of vulnerabilities found. 0 if successful, and up to 255 otherwise.

You can run this command by CI and check return code (or compare output if you want to ignore some vulnerabilities).


Alternatively you can use roave/security-advisories package. This is a Composer package which contains only a set of conflict rules with packages with known vulnerabilities. In practice you will not be able to install/update this package if you have security issues in your dependencies.

To install package:

composer require --dev roave/security-advisories:dev-master

After this you can test your dependencies using:

composer update --dry-run roave/security-advisories

If any of these commands result "Your requirements could not be resolved to an installable set of packages" error, you should take a look at conflicting packages, since they probably have some known security issues.

rob006
  • 21,383
  • 5
  • 53
  • 74
  • Do you have another recommendation? As you pointed out, it is not possible to install this if you have a package with vulnerabilities. In practice however, it may sometimes be a good solution to make other updates first, esp. if you are not affected by the vulnerability. (on the other hand, you can temporarily deactivate it in this case) – Sybille Peters Dec 02 '22 at 14:01
  • @SybillePeters I updated my answer. But alternatively you may try to use `roave/security-advisories` without installing, just run `composer require --dev roave/security-advisories:dev-master --dry-run` and check list of conflicted dependencies. – rob006 Dec 02 '22 at 21:16
  • cool, thanks. That works. Can also be done in CI pipeline (I am looking for something which is regularly executed and sends me a notification). I included it already now, because I realized I rarely (or never) have the requirement of not updating packages with vulnerabilities immediately. – Sybille Peters Dec 03 '22 at 10:06