As a grateful user, when I click at <3 Sponsor, I want to be able to say thanks with a contributions/some money etc, so that the developers know there work is appreciated.

Failures: https://github.com/williamdes/phpmyadmintest/runs/2713378511
https://github.com/phpmyadmin/phpmyadmin/commits/master?before=1ac5820cdf73d3c1136e5e733a4d4746c01805d2+35&branch=master

You can see b4d6282376d2f4a9ccd851daa333d9acd39c0b12 passes and just after 3706c1fcd1eab234dc3bd1007232c684be19704f does not

  Problem 1
    - phpmyadmin/phpmyadmin is present at version 1.0.0+no-version-set and cannot be modified by Composer
    - phpmyadmin/phpmyadmin 1.0.0+no-version-set conflicts with roave/security-advisories dev-latest.
    - Root composer.json requires roave/security-advisories dev-latest -> satisfiable by roave/security-advisories[dev-latest].

Composer bug or something else ?

This only happens on my custom multi arch setup using alpine

Inspection of the composer.json shows up the warning The version constraint has not upper bound - this is not a good idea.

It would be nice to have some tags, so that we can use the @stable constraint.

Change/blame seen here: https://github.com/Roave/SecurityAdvisories/blame/bac54e18ee767f065d88b81c8517fb21cd6414ab/composer.json#L98

Was changed in commit: bad3752

I'm not quite seeing any recent change in https://github.com/FriendsOfPHP/security-advisories/tree/master/facade/ignition

Had a little monologue about it here 😅: https://twitter.com/HenkPoley/status/1460186738689773569

It currently blocks installing Laravel 6.x for me. Which is still in security support for about a year, so I'd be surprised if there actually was an unfix{ed,able} problem.

When a package has several vulnerabilities, the generated conflict constraint may be much more complex than necessary. See for instance the rule for FOSUserBundle (much simpler than the symfony one):

>=1.2.0,<1.2.1|>=1.2.0,<1.2.4|>=1.2.0,<1.3.0|>=1.3.0,<1.3.5|>=1.2.0,<1.2.5|>=1.3.0,<1.3.3

The third constraint is a superset of the first 2 ones (and of the 5th one). Deduplicating constraints would make the dependency resolution much easier for Composer later.

To avoid useless diffs between versions, constraints should be sorted before dumping them, to ensure a consistent dump.
Sorting by lower bound (or by upper bound, whichever you prefer) seems logical.

I'm not sure whether it's Roave/SecurityAdvisories or composer bug, but let's try to start research from here.

Versions details:
os: ubuntu 18.04 (just installed)
php 7.2.7 (the official ubuntu repository) with php-curl, php-xml and php-zip installed additionally
composer 1.7.2 2018-08-16 16:57:12

Steps to reproduce:

1. Create an empty symfony flex project:

    cd /tmp
    composer create-project symfony/website-skeleton bug
   

2. Add roave/security-advisories dependency

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

Expected: all should be good

Actual:

Dependency resolution completed in 0.001 seconds
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Installation request for __root__ No version set (parsed as 1.0.0) -> satisfiable by __root__[No version set (parsed as 1.0.0)].
    - roave/security-advisories dev-master conflicts with __root__[No version set (parsed as 1.0.0)].
    - Installation request for roave/security-advisories dev-master -> satisfiable by roave/security-advisories[dev-master].

Just wanted to bring to your attention that the simplesamlphp/simplesamlphp and simplesamlphp/saml2 advisories are behind:
https://simplesamlphp.org/security/201803-01

Date

March 2, 2018

Affected versions

simplesamlphp/saml2 < 3.1.4
simplesamlphp/saml2 < 2.3.8
simplesamlphp/saml2 < 1.10.6
SimpleSAMLphp < 1.15.4

Severity

Medium

I'm not sure what the process is by which this repo stays updated, but this seemed worth mentioning. Thanks for the great help this repo is!

Hi.

Can you release please?
Now you haven't any tags.

So we need to write dev-master at composer.json, but this is not good idea + have problems with minimum-stability.

Thank you a lot.
Nice work!

The VersionConstraint currently allows matching only a very limited type of constraint

This may be improved, but it is not completely necessary

I'm trying to use this package on Drupal 8.3.7, What're conflicts exist between this packages?

After adding "roave/security-advisories": "dev-master" and running composer update I hit a memory exhaustion error in PHP. I have 1 gig set as my memory_limit.

Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 4096 bytes) in phar:///usr/local/bin/composer/src/Composer/DependencyResolver/RuleWatchGraph.php on line 52

There is no documentation about memory consumption so I'm wondering if other people have ran into this issue, or if it's my system?

edit
Upping the PHP memory_limit to 2GB has resolved the issue.

Does this project list stuff like tpyo-squatting e.g. symfont/process vs symfony/process

https://www.kernelmode.blog/typosquatting-malware-found-in-composer-repository/

I'm having an issue with a packages that replace zendframework1
shardj/zf1-future 1.16.2

Should securityadvisories check replacing packages?
This seems like a bug, or is this a composer issue?

That version of laravel, as well as older versions, does not include Ignition, which was the package that had code that was exploited in that RCE. So it's not vulnerable to that exploit, so a lot of versions of laravel that predate the inclusion of Ignition may have been erroneously added when there's not actually a security advisory for them.

Also worth investigating if composer require --dry-run --dev roave/security-advisories would work.

This work should be reflected in README.md

When updating my composer, I see this error:

[RuntimeException]
  Could not load package socalnick/scn-social-auth in http://packagist.org: [UnexpectedValueException] Could not parse version constraint >=1.2.2 <2.0.0: Invalid version string
   "1.2.2 <2.0.0"

[UnexpectedValueException]
  Could not parse version constraint >=1.2.2 <2.0.0: Invalid version string "1.2.2 <2.0.0"

Hi there

when I try to run the command as documented, I get a lot of errors but no security check. What am I doing wrong?

$ composer require --dev roave/security-advisories:dev-latest
./composer.json has been updated
Running composer update roave/security-advisories
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.
  Problem 1
    - tymon/jwt-auth is locked to version 1.0.2 and an update of this package was not requested.
    - tymon/jwt-auth 1.0.2 requires php ^5.5.9|^7.0 -> your php version (8.0.9) does not satisfy that requirement.
  Problem 2
    - supliu/laravel-query-monitor is locked to version 1.0.2 and an update of this package was not requested.
    - supliu/laravel-query-monitor 1.0.2 requires php ^7.3 -> your php version (8.0.9) does not satisfy that requirement.
  Problem 3
    - laravel/framework is locked to version v8.25.0 and an update of this package was not requested.
    - roave/security-advisories dev-latest conflicts with illuminate/database <6.20.26|>=7,<8.40 (laravel/framework v8.25.0 replaces illuminate/database self.version).
    - Root composer.json requires roave/security-advisories dev-latest -> satisfiable by roave/security-advisories[dev-latest].
Installation failed, reverting ./composer.json and ./composer.lock to their original content.

Thx
Ronny

bc10788#diff-d2ab9925cad7eac58e0ff4cc0d251a937ecf49e4b6bf57f8b95aab76648a9d34R139 is not a valid inclusion in this package because it is unactionable and prevents existing Laravel projects from updating their dependencies while requiring this package.

The inclusion of that line stems from GHSA-246r-r2wf-frhx which is a security advisory about a weak default value in the laravel/laravel project demo / template repository. The problem stems from the fact that laravel/laravel is not a dependency that is pulled into other projects, it is instead a base point that other projects start from.

This causes issues with a large amount of existing (and new) Laravel projects because most people don't change the name property in their project's composer.json file, meaning that a significant number of projects out there have name: laravel/laravel in their composer.json files, which means that this package will (falsely) now conflict with their very own project's composer.json file.

The specific error message presented to users in the above case is the following:

Problem 1
    - laravel/laravel is present at version 1.0.0+no-version-set and cannot be modified by Composer
    - roave/security-advisories dev-master conflicts with roave/security-advisories dev-master.
    - Root composer.json requires roave/security-advisories dev-master -> satisfiable by roave/security-advisories[dev-master].

As far as I can see symfony/security-http 4.4.23 does not exist.
https://github.com/symfony/security-http/releases

Maybe I'm missing something, but for now roave/security-advisories is blocking the symfony 4.4.23 update for us.

Please tag a v1.0 version. The version constraint dev-master has no upper bound - this is not a good idea. See Why are unbound version constraints a bad idea? for more information.

Parsedown is listed here as having a security advisory, but I'm not 100% sure it is warranted. It is a Markdown parsing library that takes the Markdown input it is given and turns it into HTML. Period. That is all it does. It is not output sanitizer and the author has stated that that is not a goal of the library. It already is possible to combine Parsedown with a sanitizer in order to sanitize output, for example:

use Parsedown;
use Stauros\Stauros;
use Stauros\HTML\Config;

$parsedown = (new Parsedown)->setMarkupEscaped(true);

$stauros = new Stauros(
    new Config([
        'a' => ['href' => true, 'title' => true],
        'b' => [],
        'br' => [],
        'blockquote' => ['cite' => true],
        'cite' => [],
        'code' => [],
        'em' => [],
        'i' => [],
        'p' => [],
        'q' => ['cite' => true],
        's' => [],
        'strike' => [],
        'strong' => [],
    ])
);

$html = $stauros->scanHTML(
    $parsedown->text($markdown)
);

IMO, these two things are separate concerns and forcing Parsedown to implement a full HTML sanitization feature or integrate with other libraries to do so when it can easily be done flexibly and easily in user-land doesn't make a ton of sense.

I would prefer someone other than @Ocramius review this issue as I'm not sure he can keep personal bias out of the discussion, since he fairly routinely tweets inflammatory things regarding libraries I have created. Thanks.

Thoughts?

There are several instances where you might legitimately want to include a package with a security advisory in your project. Quite often, upgrading to a newer secure version of a package may be difficult or impossible, and the security vulnerability may be low criticality or not affect your project at all. You might also want to patch the insecure version of the module (using something like https://github.com/cweagans/composer-patches) rather than upgrading to a new version.

Unfortunately there's no way to allow these kinds of exceptions with SecurityAdvisories, and no workaround that I know of.

The restrictions for symfony 4.4 for CVE-2021-21424 have been removed in FriendsOfPHP/security-advisories@42081fa.

These limits do still occur in the generated composer.json from this repo.

I tried running Roave/SecurityAdvisoriesBundle-build-conflicts.php and got the same composer.json as output. I grepped the build-directory but could not find any reason where the restrictions for that library were sourced.

Could this be looked into?

Current status

If you have symfony/security-http installed, you are not able to upgrade to a safe version since that does not exist. Latest available version for symfony 4.4 is 4.4.22, which is lower than the required 4.4.23.

What I tried/found out

$ php build-conflicts.php

$ cd build

$ grep --recursive --line-number security-http .
./composer.json:256:        "symfony/security-http": ">=2.3,<2.3.41|>=2.4,<2.7.51|>=2.8,<3.4.48|>=4,<4.4.23|>=5,<5.2.8",
./roave-security-advisories-original/composer.json:256:        "symfony/security-http": ">=2.3,<2.3.41|>=2.4,<2.7.51|>=2.8,<3.4.48|>=4,<4.4.23|>=5,<5.2.8",
./roave-security-advisories/composer.json:256:        "symfony/security-http": ">=2.3,<2.3.41|>=2.4,<2.7.51|>=2.8,<3.4.48|>=4,<4.4.23|>=5,<5.2.8",
./security-advisories/symfony/security-http/CVE-2021-21424.yaml:11:reference: composer://symfony/security-http
./security-advisories/symfony/security-http/CVE-2020-5275.yaml:11:reference: composer://symfony/security-http
./security-advisories/symfony/security-http/CVE-2019-18886.yaml:14:reference: composer://symfony/security-http
./security-advisories/symfony/security-http/CVE-2019-10911.yaml:35:reference: composer://symfony/security-http
./security-advisories/symfony/security-http/CVE-2018-19790.yaml:35:reference: composer://symfony/security-http
./security-advisories/symfony/security-http/CVE-2018-11406.yaml:38:reference: composer://symfony/security-http
./security-advisories/symfony/security-http/CVE-2018-11385.yaml:38:reference: composer://symfony/security-http
./security-advisories/symfony/security-http/CVE-2017-16652.yaml:23:reference: composer://symfony/security-http
./security-advisories/symfony/security-http/CVE-2016-4423.yaml:26:reference: composer://symfony/security-http
./security-advisories/symfony/security-http/CVE-2015-8125.yaml:17:reference: composer://symfony/security-http
./security-advisories/symfony/security-http/CVE-2015-8124.yaml:17:reference: composer://symfony/security-http

$ grep --recursive --line-number "4\\.4\\." ./security-advisories/symfony/security-http
./security-advisories/symfony/security-http/CVE-2020-5275.yaml:5:    4.4.x:
./security-advisories/symfony/security-http/CVE-2020-5275.yaml:7:        versions: ['>=4.4.0', '<4.4.7']

Hi,

I think than the possibility to change the security-advisories repository will permit us to satisfy the requirements to have CI runner without internet connection and will solve the need to have security-checker self hosted

What is your opinion on it ?

typo3/cms-core v10.4.19 conflicts with roave/security-advisories dev-latest.

I can't update my TYPO3 since the new security releases are online.

Is this a bug from roave or TYPO3?

I'm on an old project and would like to add this tool. However, I'm getting this result:

$ composer require --dev roave/security-advisories:dev-master
    1/2:	http://packagist.org/p/provider-latest$272b2375b59d963722fae33cda2f21391d74cabff9314e72be645ef506ffb148.json
    2/2:	http://packagist.org/p/provider-2018-10$e848d0ea86ecaa3b0f19d91a3e0c77a2ace231a51e677fdfbe6425d20a82ece2.json
    Finished: success: 2, skipped: 0, failure: 0, total: 2
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Installation request for … -> satisfiable by ….
    - roave/security-advisories dev-master conflicts with ….
    - Installation request for roave/security-advisories dev-master -> satisfiable by roave/security-advisories[dev-master].


Installation failed, reverting ./composer.json to its original content.

The composer why-not is not helpful either.

$ composer why-not --recursive roave/security-advisories dev-master


  [InvalidArgumentException]
  Could not find package "roave/security-advisories" in your project


prohibits [-r|--recursive] [-t|--tree] [--] <package> [<constraint>]

Is there any known way to handle this situation? I mean something more useful and precise other than "just update everything".

I think there is a typo in this package name

    "symfont/process": ">=0,<4"

I think it is supposed to be

    "symfony/process": ">=0,<4"

• roave/security-advisories dev-latest conflicts with silverstripe/admin 1.9.0.
  • roave/security-advisories dev-latest conflicts with silverstripe/admin 1.9.0-rc1.
  • roave/security-advisories dev-latest conflicts with silverstripe/admin 1.9.0-beta1.
  • roave/security-advisories dev-latest conflicts with silverstripe/admin 1.9.0-alpha1.
  • roave/security-advisories dev-latest conflicts with silverstripe/admin 1.8.1.
  • roave/security-advisories dev-latest conflicts with silverstripe/admin 1.8.0.
  • roave/security-advisories dev-latest conflicts with silverstripe/admin 1.8.0-rc1.
  • roave/security-advisories dev-latest conflicts with silverstripe/admin 1.8.0-beta1.
  • roave/security-advisories dev-latest conflicts with silverstripe/admin 1.7.4.
  • roave/security-advisories dev-latest conflicts with silverstripe/admin 1.7.3.
  • roave/security-advisories dev-latest conflicts with silverstripe/admin 1.7.2.
  • roave/security-advisories dev-latest conflicts with silverstripe/admin 1.7.1.
  • roave/security-advisories dev-latest conflicts with silverstripe/admin 1.7.0.
  • roave/security-advisories dev-latest conflicts with silverstripe/admin 1.7.0-rc1.
  • roave/security-advisories dev-latest conflicts with silverstripe/admin 1.7.0-beta1.
  • roave/security-advisories dev-latest conflicts with silverstripe/admin 1.6.4.
  • roave/security-advisories dev-latest conflicts with silverstripe/admin 1.6.3.
  • roave/security-advisories dev-latest conflicts with silverstripe/admin 1.6.2.
  • roave/security-advisories dev-latest conflicts with silverstripe/admin 1.6.1.
  • roave/security-advisories dev-latest conflicts with silverstripe/admin 1.6.0.
  • roave/security-advisories dev-latest conflicts with silverstripe/admin 1.6.0-rc1.
  • roave/security-advisories dev-latest conflicts with silverstripe/admin 1.6.0-beta1.
  • roave/security-advisories dev-latest conflicts with silverstripe/admin 1.5.2.
  • roave/security-advisories dev-latest conflicts with silverstripe/admin 1.5.1.

We have forked CakePHP because we have several applications still going strong on the v2 line, which is now EOL. We wanted to update it to support PHP 8, so we forked it, got the tests passing on PHP 8, and now want to require it in our applications.

Just to confuse everyone further, we dropped all the Cake versioning and started our own semver again.

However, when I try to require it, I get:

  Problem 1
    - roave/security-advisories is locked to version dev-master and an update of this package was not requested.
    - roave/security-advisories dev-master conflicts with myorg/cakephp 1.1.0.
    - Root composer.json requires myorg/cakephp ^1.1 -> satisfiable by myorg/cakephp[1.1.0].

I notice that cakephp/cakephp <1.3.18 is in the list of packages in the conflict list of this repository. Is that causing this issue?

Our fork is in a repository on Private Packagist, and the only things in its own require are PHP, PHPUnit (v8), and Rector prefixed.

I guess this might be a composer (or a user understanding) problem rather than a roave/securityadvisories problem, but thought I'd ask for advice. Cheers!

guzzlehttp/guzzle v6.x is old.
support for guzzlehttp/guzzle v 7.x is in need

In response to #55, I wanted to discuss the possibility of using aliases for dev-master to point to a 1.0.0 branch. The benefit of using a version is that users do not have to lower their minimum stability - which is typically a global setting - while allowing them to receive the most recent commits as if they were using the unbound dev-master version constraint.

It would look something like this:

{
    ...
    "branch-alias": {
        "dev-master": "1.x-dev"
    }
}

Then you simply tag master as v1.0.0 (down at the root of commits). Done. Users would then update the version constraint to use ^1.0 or ~1.0 and run composer update --lock.

Additionally, and this would be good to document in the instructions, is that you can inline the alias, such as "roave/security-advisories": "dev-master as v1.0.x-dev". Though this will generate an IDE warning for users of IntelliJ editors that use the EA Inspections plugin (i.e., possibly an edge case).

I'd be happy to submit a PR for it later this evening (it's 3pm -0400 for me right now).

Please, add to 'about' widget of github repo (right block) link to packagist (https://packagist.org/packages/roave/security-advisories )

Since there are no stable releases, only dev-master, our CI jobs are failed in weird way.

When I run composer outdated --direct --minor-only --strict locally, I have 0 exit code and everything is OK. In Gitlab CI job I get:

roave/security-advisories dev-master ! dev-master 6acf968 Prevents installation of composer packages with known security vulnerabilities: no API, simply require it

AFAIS 6acf968 is latest commit and we have it in composer.lock so I don't get why COmposer complains about it.

Anyway, do you consider providing stable releases? This shouldn't add much to maintaining time (just create tags) and it would bring added value:

• Do not depend on unstable package (dev-master) in projects
• composer outdated would report this package in the same way like others

If all tags would be in 1.x branch, constraint ~1.0 would work the same as dev-master. So this is only up to maintainers it they want to provide tags (releases).

Once #14 is done, there is another case where we can merge ranges: consecutive ones. This happens when the upper bound of 1 range is the same than the lower bound of the other range, and at least one of the range includes the bound:

• >=2.1,<2.2 | >=2.2,<2.2.5 => >=2.1,<2.2.5
• >=2.1,<=2.2 | >2.2,<2.2.5 => >=2.1,<2.2.5
• >=2.1,<=2.2 | >=2.2,<2.2.5 => >=2.1,<2.2.5 (may be catched by #14 already, not sure)
• >=2.1,<2.2 | >2.2,<2.2.5 => no change as 2.2.0 is not matched by ranges

The README states that the following command is sufficient to manually trigger a security version check (see #59).

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

This does not seem to work however.

I made an example repository (https://github.com/pixelbrackets/SecurityAdvisoriesTest/) with the TYPO3 CMS locked to version 10.4.5. The skeleton project has the core package »typo3/cms-core« as dependency. And I added »roave/security-advisories« as dependency as well.

composer show typo3/cms-core
name     : typo3/cms-core
descrip. : The core library of TYPO3.
keywords : 
versions : * v10.4.5

composer show roave/security-advisories
name     : roave/security-advisories
descrip. : Prevents installation of composer packages with known security vulnerabilities: no API, simply require it
keywords : 
versions : * dev-master

A new TYPO3 version 10.4.6, containing security fixes, was released today: https://packagist.org/packages/typo3/cms-core#v10.4.6

The version constraint is already merged into »roave/security-advisories«: https://github.com/Roave/SecurityAdvisories/blob/master/composer.json#L216

The given command should now return any kind of information, that 10.4.5 is not valid anymore. This is not the case however.

I use Composer version 1.10.9.

As per #9 and #13, it would be interesting (but very complicated!) to merge ranges that overlap.

Examples:

• >1,<2 + >=2,<3 = >1,<3
• >1,<2.1 + >2,<3 = >1,<3

zendframework changed their project and now it is called Laminas, so Please also add Laminas issues too.
After this changes all packages called zendframework, zfcampus, moved to their Laminas paths and current packages marked as archive.

For example

"zendframework/zend-cache" now "laminas/laminas-cache"

"zendframework/zend-captcha" now "laminas/laminas-captcha"

etc ...

in FriendsOfPHP/security-advisories : laravel/framework
"7.x": time: 2020-01-13 14:37:00 versions: [>=7.0.0', '<7.30.2']

With reference to 410eb5b , which versions of zendframework/zend-db are actually allowed? Are any of them secure at all?

Today the Travis tests for one of my bundles started failing with no apparent reason in its code (log: https://travis-ci.org/kaliop-uk/ezmigrationbundle/jobs/395645840 )

The travis log tells me that composer failed to install the dependencies - but in a quite non obvious way, as the offending package is listed as being 'roave/security-advisories dev-master', instead of the one that SecurityAdvisories conflicts with.

It might well be that this is rather a composer problem with not giving more detailed information about the conflict - but in the current situation it is hard for me to find out which package prevents composer to achieve an installation, as the list of dependencies is huge.

It is also not as easy to simply 'not include SecurityAdvisories' in the composer.json that I use for Travis tests, as it is in fact pulled in by a dependency (my bundle is a plugin for a cms, and it pulls in the cms as dependency when running its test suite. The cms seems to be the one now including SecurityAdvisories).

And all things considered, I'd rather still run my tests against a complete matrix of versions of the supported core system, even though some of those might now be known to have security issues.

It would be nice to have at least some tips for working around this situation in the Readme file...

Commits like a88d5f2 are quite frequent, and caused by different globbing/sorting of configurations, upgrades in components that do the YAML parsing and so on.

Basic sorting (can be very simple) of the constraints would prevent this in future.

I think @stof reported this previously.

After the Laravel Cookie incident, I think the conflict with https://github.com/illuminate/cookie needs to be updated.

Related: https://blog.laravel.com/laravel-cookie-security-releases

I see that since yesterday you've added Drupal Contrib Modules to your great package.

I like that, but it currently breaks my composer on all my D8-projects, because all versions of drupal/entity are marked as unsafe: "drupal/entity": ">=1,<1.9"

At least the latest (1.0-rc1) version has been found safe by the Drupal Security Team: https://www.drupal.org/project/entity

Hi,

This advisory has been withdrawn. So i think the laravel/framework package conflict should be reverted to the previous value.

8e5526b didn't pick up "doctrine/orm": ">=2.5.0,<2.5.1" (defined in doctrine/orm/2015-08-31.yaml)

This needs investigation.

Could you please add drupal/core ? It's a subtree split of drupal/drupal so it should be the same.

the code uses false === exec(...) to check for failures in commands. this is wrong. The return value of exec does not indicate success or failure at all. It is the last line of the command output: http://php.net/manual/en/function.exec.php

The travis builds should actually be failing currently, because git commit says it cannot determine the author info: https://travis-ci.org/Roave/SecurityAdvisories/jobs/78440921#L259
But this is not detected.

This also means that the build script does not fail in case it generates an invalid composer.json

I like to run composer diagnose as one of many CD health/settings checks.

It's currently all clear except for roave/security-advisories:

Checking composer.json: WARNING
require.roave/security-advisories : unbound version constraints (dev-master) should be avoided
Checking platform settings: OK
Checking git settings: OK
Checking http connectivity to packagist: OK
Checking https connectivity to packagist: OK
Checking github.com rate limit: OK
Checking disk free space: OK
Checking pubkeys: 
Tags Public Key Fingerprint: 57815B42 7E54DC31 7ECC7CC5 573090D0  87719BA6 8F3BB723 4E5D42D0 84A14642
Dev Public Key Fingerprint: 4AC4D767 E5EC2265 2F0C1167 CBBB8A2B  0C708369 153E328C AD90147D AFE50952
OK

I'm guessing this is intentional so that we always have the latest advisories without the maintainers having to do continuous releases. However, this check erroring out stops my CD process (as it should).

Any ideas of a fix/workaround?