Aller au contenu principal
Version: v0.20

Sécurité et état du SDK PHP

Le SDK lit des fichiers de projet non fiables et peut les modifier lorsque la remédiation est activée. Traitez une analyse comme une opération privilégiée avec une cible explicite, un stockage contrôlé et un parcours d'examen pour chaque détection.

Configuration globale au processus​

Scanner stocke sa configuration et son rapport actuel dans un état statique. Les setters fluides renvoient une nouvelle instance de Scanner, mais modifient cet état partagé du processus.

$first = new Scanner();
$second = $first->setPathScan('/srv/project-a');

// Both objects observe the same Scanner configuration.

Exécutez une seule analyse à la fois dans chaque processus PHP. Utilisez un nouveau processus CLI pour les tâches d'arrière-plan, les requêtes simultanées ou l'isolation des locataires. Un worker de longue durée doit appliquer la configuration complète avant chaque exécution et éviter de réutiliser l'état d'une tâche antérieure.

run() réinitialise le rapport au début d'une analyse. Elle ne réinitialise pas la configuration générale du scanner. Ne comptez pas sur la construction d'un objet pour restaurer les valeurs par défaut.

Actions sur les fichiers​

Le comportement d'invite par défaut diffère entre les exécutions interactives et silencieuses. Choisissez explicitement une action dans du code sans surveillance :

$report = (new Scanner())
    ->setPathScan('/srv/app')
    ->setSilentMode()
    ->setAutoSkip()
    ->run();

Pour toute action qui modifie des fichiers, appelez enableBackups() et définissez setPathBackups() sur un répertoire accessible en écriture hors de la cible. Conservez la quarantaine, la liste blanche, la désobfuscation, les rapports, les journaux, les détections durables et les points de contrôle hors du projet analysé afin que le scanner n'inspecte pas sa propre sortie.

Avant d'activer le nettoyage, la mise en quarantaine ou la suppression automatiques :

  1. Exécutez des analyses avec rapport uniquement sur des copies représentatives de l'application.
  2. Vérifiez coverage, findings et diagnostics pour chaque exécution.
  3. Testez les procédures de sauvegarde et de restauration sous le même compte que celui qui exécute les analyses de production.
  4. Limitez le chemin cible aux racines de projet approuvées.

Chemins et autorisations​

Passez des chemins absolus provenant d'une configuration fiable. Normalisez et autorisez les chemins issus de requêtes avant d'appeler setPathScan(), setPathReport() ou tout autre setter de chemin. Le SDK normalise les chemins avec Path::get(), mais la normalisation n'applique pas la limite d'autorisation de votre application.

Exécutez le scanner avec le minimum d'accès au système de fichiers nécessaire pour lire la cible et écrire sa sortie contrôlée. N'exécutez pas une requête web sous un compte pouvant analyser ou supprimer des fichiers hors de la racine de déploiement prévue.

Comportement réseau et fonctionnement hors ligne​

L'analyse du code principal utilise des définitions intégrées. La vérification d'intégrité et les définitions de domaines Maltrail peuvent utiliser du HTTPS sortant. Le scanner stocke les données distantes réussies dans un cache du système d'exploitation hors de la cible d'analyse.

Lorsque votre environnement bloque le trafic sortant, collectez et conservez les diagnostics de rapport. Une mise à jour échouée peut laisser des définitions mises en cache actives ; le rapport enregistre les métadonnées disponibles dans signature_indexes. Ne supposez pas que le tableau de diagnostics est vide en l'absence de route réseau.

Politique d'échec​

Traitez false provenant de run() comme une erreur opérationnelle. Traitez une couverture incomplète, les diagnostics et les avertissements comme des signaux nécessitant un examen. Stockez le rapport avec son horodatage d'analyse, l'identité de la cible, la version du scanner issue de Scanner::getVersion() et tout identifiant de tâche externe.

Le SDK expose les messages d'erreur interceptés par getLastError(). Enregistrez-les dans un journal d'application protégé. N'exposez pas les chemins cibles, le contenu des rapports ni le texte brut des erreurs à des utilisateurs non fiables.