Add audit command to check for security issues

[GuySartorelli]

Closes #10329

Description

Adds an audit command which checks for security vulnerability advisories for installed packages using the API on packagist.org.

Also adds optional auditing (on by default) to the following commands:

• create-project
• update
• install
• require
• remove

Table output (default)

Plain output

Things the audit command does not do:

• Confirm the packages in vendor dir match what composer.lock says they should be
• If composer.lock is missing, check for advisories based on the constraints in the composer.json file

Out of scope, but would be a good future enhancement

• A new --no-insecure (or --allow-insecure) flag could be added to update and require. This could use Auditor to take versions with advisories out of the version candidate pool, so that you can't accidentally update to or require an insecure version of a package.
• new config in composer.json where you can declare specific advisories which should be ignored by the audit (e.g. the advisory doesn't apply for your project and you don't want audit to keep failing because of it). Would likely need to include the advisory ID in audit output for this to be feasible.

Things I'm unsure about

• I don't know how to resolve the PHPStan failures - some seem overly strict so I'm hesitant to just blindly follow them.
• Is there a clean way to test the different formats are working as expected in a unit test?

[stof]

I also got the 502 error when trying the query in the browser. This seems to be caused by too many packages in a single request; if I significantly reduce the number of packages in the query, it returns an appropriate response. This is a major blocker for this functionality being implemented, so if someone knows a way around this, please let me know.

Well, one thing you could do is splitting the list of packages into batches (the batch size should be chosen based on the supported size for the Packagist API) and send multiple requests. Thanks to the parallelization support in Composer 2+, you can even send those requests in parallel.

[GuySartorelli]

That's a good idea - I couldn't find any information about what the limit actually is but I'll have another look, and failing that I can always do some trial and error to find it. Bonus points for anyone who can point me in the right direction or who already knows what the limit is.

Edit: apparently the API supports POST requests - I'll experiment a bit and see if I can get that to work, cause it's likely POST requests have a much higher limit.

[Seldaek]

Yes IMO putting the package list in the POST body will fix this as this is AFAIK not size limited at all, unlike URL length which has limits in various places.

[GuySartorelli]

Currently blocked because the packagist API returns a 404 error on POST requests. I've created an issue for it under composer/packagist#1309

Edit: It does if I do things correctly. :P Not blocked anymore.

[GuySartorelli]

The basic functionality is working now - any review on the AuditCommand or Auditor, updates to existing commands, and related documentation would be useful at this stage.

I'm especially eager for feedback on the UX - I'm aware that the current output is probably not ideal, but I'm not sure how it should look. The parent issue references yarn audit which formats the output as a table - should we look at doing something like that? If so can someone point me in the right direction for how to format such an output?

[GuySartorelli]

It looks like there's some PHPStan issues as well - to be honest I don't understand what I need to do to resolve those. A lot of the errors are saying the new command doesn't define some options... but it doesn't need those options.

[GuySartorelli]

I've resolved some of the PHPStan issues. The ones that I think are false alarms I've tried to add to the baseline, but it doesn't seem to have taken. There are a couple of PHPStan issues there as well which are unrelated to this PR.

[ktomk]

For the output format could JSON Text be another variant? I've seen there is a table, so perhaps some very straight forward JSON Array of JSON Objects could be nice to pass along to further (automated) processing.

[GuySartorelli]

@ktomk At this stage I'd just be keen to see the feature merged - that sounds like an enhancement that can be added after the fact quite easily if there is real world use for it. I'd be quite happy for someone to create a follow-up PR with that format if there is a need for it but it's not something I want to add to this PR right now.

[Seldaek]

Thanks, looking good I think now, a couple typos/nitpicks and then it's mergeable I think.

[GuySartorelli]

Requested changes have been made.
Edit: Oops looks like I broke some tests... will fix those now.

[GuySartorelli]

Tests fixed - there is one failure there but I think it's unrelated to this PR.

[Seldaek]

Thanks! Merged as d93239d and fixed up some remaining issues in 611b215 🥳

[GuySartorelli]

Awesome, thank you!
Should I create an issue to track/remind about moving Auditor into its own repository post-stable, or do you have an alternative to-do list somewhere with that on it?

[Seldaek]

The more I think of it the more I think we can't really extract this, as it'll probably need to be integrated deeper into the Repository code than it is now.

I think the better way would be to publish a packagist.org API client library really, that would be completely separate from Composer, and would not require Package objects or anything to function.

[GuySartorelli]

That's fair. I'd be happy to help develop such a library with as much or as little guidance as you want to provide. While I could implement such a library in some arbitrary repo it makes sense to me that there would be such a repository under the composer organisation which people can just add to their dependencies when and as they need it.

[stof]

You mean something like https://packagist.org/packages/knplabs/packagist-api ?

[Seldaek]

Ah yes there's that, then maybe worth sending a PR there porting the Auditor querying bits @GuySartorelli if you feel like it?

[GuySartorelli]

I'll take a look - I wasn't aware of that package. Still doesn't feel as appropriate as having one in GitHub.com/composer but I won't push for that if the appetite for creating it isnt here 😅

[barryvdh]

For the output format could JSON Text be another variant? I've seen there is a table, so perhaps some very straight forward JSON Array of JSON Objects could be nice to pass along to further (automated) processing.

I created a follow-up PR for the json format here: #10965