Loading...
 
Skip to main content

Check security advisories of Composer dependencies

This page is to discuss and plan the inclusion of a dedicated security check library in Tiki.

here is the library that was used (https://github.com/fabpot/local-php-security-checker) but which, since August 2, 2024 has been abandoned.

Possible options

1. Roave/security-advisories

https://github.com/Roave/SecurityAdvisories

Advantages:

- Displays high activity, with the last commit made 13 hours ago
- Uses 2 databases for advisories (https://github.com/FriendsOfPHP/security-advisories and GitHub Advisory Database)

Disadvantages:

- Not flexible to ignore a known vulnerability (important when there is work in progress to fix a vulnerability)

2. cs278/composer-audit

https://github.com/cs278/composer-audit

Advantages:

- Provide a way to ignore a known vulnerability (important when there is work in progress to fix a vulnerability)

Disadvantages:


- Only two contributors
- Displays last commit made last year

3. Built-in composer audit Command

Advantages:

- No third-party library to install
- Uses 2 databases for advisories (https://github.com/FriendsOfPHP/security-advisories and GitHub Advisory Database) as mentioned here
- Possibility to add a third-party advisory repository

Disadvantages:

- None found

My proposed choice

I(Alfred Syatsukwa) suggest working with composer built-in solution. In fact I read in detail about roave/security-advisories and in its use it is used to block the installation of libraries with known vulnerabilities.

On the other hand we have the solution with composer audit (built-in solution) flexible because it warns us of vulnerabilities without blocking the development. We think that this situation is well suited to the context of Tiki working with several libraries and which may not have an urgent applicable solution.

benoitg: There is another important aspect:
- The composer native solution has only been written in 2022. We probably added https://github.com/fabpot/local-php-security-checker before that. And it was added because a previous project had died. Now that a native solution exists, it seems unlikely other projects will survive long term unless they provide something very specific. So we should probably go with the native solution.

Show PHP error messages