Scan des dépendances

Le SDK peut transmettre les packages Composer installés dans votre application afin que le serveur Quiet Guard les confronte aux avis de sécurité connus et vous alerte lorsqu'une vulnérabilité touche une version que vous utilisez.

La commande

php artisan monitor:dependencies

Cette commande lit votre composer.lock, construit un instantané de chaque package installé et le poste sur l'endpoint /api/v1/dependencies du serveur. Le serveur stocke l'instantané et met en file un scan contre les avis de sécurité de Packagist.

Lorsque MONITOR_ENABLED=false, la commande affiche un avertissement et n'envoie rien.

Options

php artisan monitor:dependencies --path=/var/www/releases/current/composer.lock

Ce qui est envoyé

La commande analyse à la fois packages et packages-dev du composer.lock. Pour chaque entrée, elle envoie :

• name: le nom du package (ex. laravel/framework) ;
• version: la version verrouillée, sans le v initial éventuel (ex. 12.3.1) ;
• is_dev: si elle provient de packages-dev.

Seul le fichier de lock est lu. Aucun code source, aucun .env et aucune contrainte de composer.json ne sont envoyés, uniquement les paires nom/version résolues, déjà publiques sur Packagist.

Planification

Lancez la commande à chaque déploiement pour que l'instantané corresponde toujours à ce qui tourne en production, et éventuellement quotidiennement pour confronter les avis nouvellement publiés à votre lockfile actuel.

Ajoutez-la au planificateur de votre application dans routes/console.php :

use Illuminate\Support\Facades\Schedule;

Schedule::command('monitor:dependencies')->dailyAt('06:00');

Ou dans votre script de déploiement, juste après composer install :

php artisan monitor:dependencies

Codes de sortie

• Succès lorsque les dépendances sont transmises, lorsque le SDK est désactivé, ou lorsqu'aucun package n'est trouvé.
• Échec lorsque composer.lock est introuvable au chemin indiqué, ou lorsque l'envoi échoue.

Lorsque le serveur refuse l'envoi, la commande affiche la phrase du serveur, sous la forme HTTP <statut> from <url>: <message>, plutôt qu'une consigne générique de vérifier MONITOR_URL et MONITOR_KEY. Un 401 dit que la clé est fausse, un 404 que l'adresse l'est, un 403 que le forfait n'inclut pas le scan : l'ancien conseil ne convenait qu'à l'un des trois.

Où apparaissent les résultats

Les findings apparaissent dans l'onglet Vulnérabilités de votre projet sur le dashboard Quiet Guard, et les nouvelles vulnérabilités déclenchent des alertes via vos canaux de notification configurés. Consultez la documentation du serveur pour gérer et ignorer les findings.