FriendsOfPHP/security-advisories

Document usage limits for security.sensiolabs.org

legoktm opened this issue ยท 9 comments

I'd like to integrate checking against this database as part of our CI system. How many requests per some timeframe is it appropriate to make against this service?

Alternatively is it possible to self-host the service or maybe a tool that can just run against a git checkout of this repository?

And, thanks for maintaining this :)

cebe commented

I have no answer about security.sensiolabs.org, but an alternative:

There is https://packagist.org/packages/roave/security-advisories which prevents composer from installing software marked as vulnerable in this repository. Requiring it on a project with composer.lock file present should fail when a vulnerable dependency exists.

stof commented

that would prevent composer update though. It won't help when installing from lock where you would want to check the current locked versions against the latest database.

A bit late, sorry, I guess this is more for future reference. At work, we value security as much as we value good code. For a couple of months now, we have been using the cli tool in our CI (Bitbucket Pipelines). So far without any problems, no rate limit, and no false positive issues. I think we have discovered about 5 major issues so far, without any extra effort! I would definitely recommend implementing this tool in your CI.

Closing as security.sensiolabs.org is closing down at the end of October. Limit has been implemented on security.symfony.com where usage is limited to personal checks.

Closing as security.sensiolabs.org is closing down at the end of October. Limit has been implemented on security.symfony.com where usage is limited to personal checks.

Will this break previous installations of sensiolabs/security-checker? As in, should everyone update to 5.0.0 before the end of october?

It will most likely break, since the API requires authentication now

There is no break and no need to authenticate to the API. The API is exactly the same as before. The only exception being that there is now a rate limiting in place.

stof commented

@fabpot https://security.symfony.com/docs should be updated to document the rate limit

Is this the reason why some of our ci builds fail with the following error?

An error occurred: file_get_contents(https://security.symfony.com/check_lock): failed to open stream: Connection timed out.

  • What's the limit?
  • What can we do to increase the limit?
  • Is there a way to self-host the checker?