security-advisories | published security advisories reported by the Programa STIC | Database library

The problem is not really in monolog-bundle but as follows:

• monolog-bundle requires symfony/http-kernel ~3.4 || ~4.0 || ^5.0
• You restricted all Symfony components to 5.0 (by setting "extra" -> "symfony" -> "require" to 5.0.*). So the only fulfillable requirement for monolog-bundle is http-kernel 5.0.*
• roave/security-advisories works by purposely conflicting with lib versions that have known security issues. In this case, every 5.0.* release has vulnerability CVE-2020-15094 (see https://symfony.com/blog/cve-2020-15094-prevent-rce-when-calling-untrusted-remote-with-cachinghttpclient) and is therefore blocked. So there is no valid version left and Composer aborts.

My suggestion: Symfony 5.0 reached end of life, so use the current release Symfony 5.2.x (Composer constraint "^5.2"). As Symfony uses strict Semantic Versioning there is no disadvantage for going to 5.2 instead of 5.0 (i.e. all code that runs on 5.0 will also run on 5.2).

At least one of the packages you're using doesn't support Laravel 7 or 8. The composer error message tells you which one.

According to the error message, "silber/bouncer": "v1.0.0-rc.6" only supports up to Laravel 6. Looking at the composer.json for that package shows that support for Laravel 7 wasn't added until v1.0.0-rc.7, and support for Laravel 8 wasn't added until v1.0.0-rc.9.

You'll need to update your silber/bouncer dependency and then try again. If you run into another error, you'll need to look at the message to determine which package doesn't meet the requirements, and then figure out what version of that package you need to get to in order to meet the requirements.

Since Laravel 8 is fairly new, you may run into some packages that haven't been updated to support it yet (such as vimeo/laravel). In that case, you'll either need to wait until those packages support it, or fork the package and attempt to add the support yourself.

Why not simply inspect your folders to find a vulnerable version? If there was any, you should find a vendor folder within that package, that's where that package could have installed stuff from it's own composer.lock

Usually, only the composer.json of a package is evaluated to install dependencies. If there is a lock file within one package's folder, you should ask the maintainer of that package why this is the case, but for installing dependencies on your system, this does not matter.

Side note: writing "usually" refers to the standard model of installations. I've seen some crude stuff where Composer plugins put other rules in place, but this cannot be said for your project without knowing more about the structure.