Moteurs de scan et couverture

Les moteurs Plexicus et ce qu’ils couvrent

Plexicus applique l’approche Proof-Driven AppSec : AI Swarm Pentest valide ce qui est réellement exploitable, Deep Code Analysis explique ce qu’un constat affecte, et Remediation prépare un correctif que votre équipe relit et fusionne. Les moteurs de scan alimentent cette boucle. Ils vous apportent une couverture large et reproductible de votre code, de vos dépendances, de votre configuration et de votre chaîne d’approvisionnement. Considérez une détection de scanner comme un constat candidat, et non comme une preuve : pas de preuve reproductible, pas de constat vérifié.

Chaque moteur Plexicus est un bundle géré : une capacité que vous activez ou désactivez d’un bloc, et qui peut faire tourner plusieurs scanners sous-jacents. Chaque constat enregistre dans son champ Tool le moteur qui l’a produit, par exemple plexicus-sast ou plexicus-iac.

Le catalogue des moteurs

Moteur	Ce qu’il recherche	Exemple type
Plexicus SAST (`plexicus-sast`)	Vulnérabilités du code, comme les failles d’injection et les patterns dangereux, avec traçage des flux de données	Un gestionnaire de connexion qui concatène le nom d’utilisateur dans une requête SQL
Plexicus SCA (`plexicus-sca`)	Dépendances open source vulnérables dans les principaux gestionnaires de paquets, rapprochées de sources de CVE comme la NVD et la GitHub Security Advisory Database	Un analyseur XML obsolète, visé par une CVE publiée, dans votre fichier de verrouillage
Plexicus Secrets (`plexicus-secrets`)	Identifiants, clés d’API et jetons codés en dur, dans l’arborescence de travail et dans tout l’historique Git, avec vérification en direct auprès du service émetteur	Une clé d’accès cloud commitée l’an dernier, supprimée ensuite, mais toujours présente dans l’historique
Plexicus IaC (`plexicus-iac`)	Violations de politiques dans les templates Terraform, CloudFormation, Kubernetes, Helm, Ansible et ARM	Un bucket de stockage déclaré avec un accès public en lecture
Plexicus CI/CD (`plexicus-cicd`)	Erreurs de configuration, permissions non sécurisées et identifiants exposés dans les définitions de pipeline comme GitHub Actions, GitLab CI et Azure Pipelines	Un workflow qui accorde à son jeton un accès en écriture à tout
Plexicus Container (`plexicus-container`)	Erreurs de configuration, images de base non sécurisées et vulnérabilités connues dans les Dockerfiles et les artefacts de conteneur du dépôt	Un Dockerfile construit sur une image de base obsolète présentant des CVE connues
Plexicus License (`plexicus-license`)	Licences copyleft, propriétaires ou inconnues dans les dépendances	Une bibliothèque copyleft dans un produit que vous distribuez
Plexicus SBOM, CBOM et AIBOM	Des inventaires plutôt que des constats classés par sévérité : composants logiciels (CycloneDX ou SPDX), actifs cryptographiques avec leur niveau de préparation post-quantique, et modèles d’IA, jeux de données et fiches de modèle	Une paire de clés RSA que le CBOM signale comme vulnérable aux attaques quantiques
Plexicus SCM (`plexicus-scm`)	Posture de la chaîne d’approvisionnement et pratiques SLSA : commits signés, provenance des artefacts, durcissement des builds	Une branche par défaut qui accepte des commits non signés

Lorsqu’ils sont activés pour votre organisation, deux autres moteurs apportent une couverture complémentaire au-delà du dépôt : Plexicus Registry scanne les images des registres de conteneurs connectés, et Plexicus Cloud contrôle les comptes cloud connectés à la recherche d’erreurs de configuration et de politiques IAM trop larges. Tous deux alimentent le même modèle de constat (leçon 5).

Deux autres cartes gérées par Plexicus figurent dans la catégorie SAST : Plexicus AI Scan, un moteur expérimental piloté par l’IA que Plexicus active organisation par organisation (module 5), et GitHub SAST, qui importe les alertes GitHub code scanning. Cette catégorie contient aussi la carte SARIF Import et les cartes des connecteurs commerciaux (leçon 3). AI Swarm Pentest n’est pas un moteur de dépôt : il apparaît sous le nom AI Pentest dans la section Pentest (module 6).

La disponibilité dépend de votre offre

SAST, SCA, Secrets et IaC ne dépendent pas de l’offre. Les autres moteurs, comme Container, CI/CD, License, SCM, Registry, Cloud et AI Scan, dépendent de votre offre. Si votre offre n’inclut pas un moteur, sa carte affiche une invitation à changer d’offre au lieu de s’activer, et le backend applique la même règle. Pour les moteurs soumis à l’offre, un administrateur peut demander un changement d’offre sous Settings Billing (module 10). AI Scan fait exception : Plexicus l’active sur demande (module 5).

Choisir un ensemble de moteurs pour votre organisation et vos dépôts

Partez de ce que contiennent vos dépôts. Certains moteurs se règlent par dépôt, d’autres s’appliquent à toute l’organisation (leçon 2).

Un service Python ou Node.js : SAST, SCA et Secrets. Ajoutez CBOM si le code manipule de la cryptographie.
Des définitions Terraform, CloudFormation ou Helm : ajoutez IaC.
Des définitions de pipeline : ajoutez CI/CD.
Des Dockerfiles : Container, plus License pour le risque lié aux licences. Tous deux s’appliquent à toute l’organisation.
La posture de la chaîne d’approvisionnement : SCM, également au niveau de l’organisation.
Des preuves d’inventaire : SBOM, CBOM et AIBOM. Le module 8 explique comment ils alimentent le XBOM.

Configurer les scans

L’organisation définit les moteurs par défaut, et chaque dépôt peut en surcharger certains. Réglez d’abord correctement les valeurs par défaut, puis ne surchargez que là où un dépôt diffère réellement.

Valeurs par défaut de l’organisation sur la page Connectors

La page Connectors répertorie les moteurs de scan et les connecteurs d’outils par catégorie, de SAST, SCA et Secrets / PII Scan jusqu’à CI/CD Posture, License et SCM Security. Ouvrez /connector sur votre hôte Plexicus pour y accéder ; les inventaires XBOM vides y renvoient aussi avec Go to Connectors. La gestion de code source, les registres, les comptes cloud et la gestion des tickets se connectent séparément sous Settings Integrations .

Ouvrez la carte d’un moteur pour afficher son panneau de configuration :

Onglet	Rôle
Tool	L’interrupteur Enable active ou désactive le moteur pour toute l’organisation. Niveau organisation uniquement.
Severity	Choisit les sévérités que Plexicus conserve pour ce moteur. Par défaut : Medium, High & Critical.
Advanced Options	Paramètres propres au moteur, affichés uniquement pour les moteurs qui en disposent. Cliquez sur Save pour conserver les modifications.

Les modifications s’appliquent aux scans suivants.

Surcharges par dépôt

Pour modifier les moteurs d’un seul dépôt, ouvrez Assets Repo Scan Configure (l’icône d’engrenage sur la ligne du dépôt). Le panneau n’affiche que les catégories réglables par dépôt, comme SAST, SCA, Secrets, IaC, CI/CD et les moteurs de nomenclature (BOM). Container, License et SCM se choisissent au niveau de l’organisation, sur la page Connectors.

Pour un dépôt sans sélection propre, le panneau s’ouvre sur la sélection actuelle de votre organisation et liste ce qui est « Enabled for this repository ». À l’enregistrement, cette liste devient une copie explicite propre au dépôt, et les modifications ultérieures des valeurs par défaut de l’organisation ne s’y appliquent plus. La console ne propose pas de bouton de réinitialisation ; le retour à la sélection de l’organisation se fait via l’API REST (module 9).

Utilisez l’interrupteur de la carte d’un moteur pour l’activer ou le désactiver sur ce dépôt. Une notification le confirme, par exemple « Plexicus IaC tool enabled for this repository ».
Les connecteurs qui nécessitent des identifiants ouvrent d’abord leur configuration ; l’interrupteur ne reste activé qu’une fois le connecteur configuré.
Dans la console, la fenêtre de détail du moteur n’affiche ici que les onglets Severity et Advanced Options, et les modifications qui y sont faites s’appliquent à toute l’organisation. L’API REST permet aussi de définir, pour un moteur donné, des paramètres et un filtre de sévérité propres à un dépôt.

Lorsque vous ajoutez des dépôts dans Manage Repositories, Launch scanne chacun d’eux avec la sélection de moteurs par défaut de votre organisation. Advanced Options ouvre à la place « Configure Tools for Repository », où vous choisissez les moteurs de chaque dépôt avant le lancement.

Le filtre de sévérité et les chemins exclus

L’onglet Severity définit les sévérités que Plexicus conserve pour ce moteur. Les résultats hors sélection sont écartés après le scan et ne deviennent jamais des constats : vous ne pourrez pas les faire réapparaître ensuite. Avec la valeur par défaut, Medium, High & Critical, les résultats Low et Informational ne sont remontés pour aucun moteur, sauf si vous les ajoutez. Pour voir les résultats Low, ajoutez Low et relancez le scan. Les moteurs de nomenclature produisent des inventaires et ignorent ce réglage.

Les chemins exclus n’ont pas de champ dans la console. Ce sont des paramètres de bundle définis via les endpoints de configuration des outils de l’API REST (module 9). La plupart des moteurs de code les prennent en charge, mais pas Secrets, SCM, AIBOM ni CBOM.

Options avancées

Quelques options propres aux moteurs que vous utiliserez :

SAST : baseline_commit ne remonte que les problèmes apparus depuis un commit donné ; exclude_rule désactive une règle trop bruyante.
SCA : fail_on définit le seuil de blocage par code de sortie ; only_fixed ne conserve que les CVE qui disposent d’un correctif.
Secrets : redact masque les valeurs des secrets dans la sortie ; include_detectors et exclude_detectors sélectionnent les détecteurs.
IaC : skip_check et skip_framework écartent des contrôles ou des frameworks entiers ; soft_fail signale sans faire échouer. La carte Plexicus CI/CD n’a pas d’onglet Advanced Options.

L’interrupteur Autonomous Scan des scans de pull request se trouve sous Settings Platform (leçon 4).

Importer d’autres résultats

De nombreuses équipes utilisent déjà d’autres scanners ou reçoivent des rapports de testeurs externes. Inutile de choisir entre eux et Plexicus : importez leurs résultats, qui rejoignent la même file, le même enrichissement et la même déduplication que les constats natifs.

Upload Scan

La voie la plus directe est Findings Repo Upload Scan . Le bouton n’existe que dans l’onglet Repo.

Select repository : le dépôt Plexicus auquel appartiennent les résultats.
Select tool : SARIF générique, ou le format d’export de l’un des outils commerciaux de SAST, de SCA ou de test dynamique pris en charge ; la liste indique lesquels.
Select file : le rapport produit par votre outil.
Cliquez sur Upload.

Une fois l’envoi accepté, le message « Data uploaded successfully » s’affiche. Les résultats sont ensuite traités comme ceux de n’importe quel autre scan.

Import SARIF 2.1.0

Plexicus accepte le SARIF 2.1.0 de tout analyseur compatible, via Upload Scan ou via la carte SARIF Import de la catégorie SAST de la page Connectors. La sévérité est déterminée dans cet ordre :

Donnée SARIF	Sévérité Plexicus
`security-severity` de la règle à 9,0 ou plus	Critical
`security-severity` de 7,0 à moins de 9,0	High
`security-severity` de 4,0 à moins de 7,0	Medium
`security-severity` en dessous de 4,0	Low
Pas de `security-severity` : niveau de résultat `error`	High
Niveau de résultat `warning`	Medium
Niveau de résultat `note` ou `none`	Low
Pas de niveau de résultat non plus	Le niveau par défaut de la règle, converti de la même manière ; Low si la règle n’en a pas

Les identifiants CWE sont lus dans des tags comme external/cwe/cwe-89, qui servent ensuite à la correspondance OWASP (leçon 5). Plexicus retire le préfixe file:// et la barre oblique initiale de chaque emplacement : produisez donc du SARIF avec des chemins relatifs à la racine du dépôt. Sinon, le fichier et la ligne ne correspondront pas à votre code.

Connecteurs de scanners commerciaux

La page Connectors liste aussi des scanners commerciaux. Certains récupèrent les résultats via l’API de l’éditeur, une fois ses identifiants saisis sur la carte. D’autres acceptent un fichier d’export téléversé, comme Upload Scan. La carte GitHub SAST ingère les alertes GitHub code scanning. Les résultats de test dynamique d’un outil tiers sont distincts d’AI Swarm Pentest. Certains connecteurs ne sont disponibles qu’avec certaines offres ; contactez Plexicus pour en activer un.

Envois depuis la CI

L’API Plexicus expose une opération Upload Scan Results qui ingère, pour un dépôt, des résultats produits à l’extérieur. Un pipeline peut l’appeler avec un jeton d’API personnel une fois ses propres scanners exécutés ; le module 9 traite des jetons et de l’API REST.

Lancer des scans depuis la CI/CD

Plexalyzer est le scanner de Plexicus. En CI, il s’exécute dans votre pipeline et envoie les résultats à votre organisation Plexicus, où ils apparaissent dans le tableau de bord et dans Findings, comme pour tout autre scan. Vous disposez de trois façons de le mettre en place.

Plexicus ne lance pas de lui-même un scan à chaque push. Les nouveaux scans proviennent de votre pipeline CI (scans de pull request compris), de l’ajout d’un dépôt, de Relaunch scan dans l’Activity Center ou d’un Re-Scan. Pour scanner un dépôt au fil des modifications de son code, configurez son pipeline.

Le jeton Plexalyzer

Chaque exécution de Plexalyzer s’authentifie avec le jeton Plexalyzer de l’organisation, également appelé jeton du scanner CI/CD. Les administrateurs le gèrent sous Settings Plexalyzer Token . Dans certaines versions, ce même jeton apparaît dans la section du jeton du scanner CI/CD de Settings API Tokens . Vous pouvez créer un jeton avec un Token Name et une Expired Date facultative, le copier et le supprimer. Le jeton marqué Default ne peut pas être supprimé tant que d’autres jetons existent. Supprimer un jeton casse tous les pipelines qui l’utilisent encore.

Ce jeton appartient à l’organisation et n’est utilisé que par le scanner Plexalyzer, pas pour les appels d’API généraux. Les jetons d’API personnels, destinés aux scripts et au serveur MCP, ainsi que le jeton de la CLI, sont distincts (module 9).

Setup Pipeline depuis Assets

Le chemin le plus rapide part de Assets Repo Scan . La colonne Pipeline propose Setup Pipeline pour les dépôts GitHub, GitLab, Gitea, Forgejo et Bitbucket Cloud ; les autres fournisseurs affichent Not Available.

Cliquez sur Setup Pipeline et confirmez.
Plexicus ouvre dans votre dépôt une pull request qui ajoute le workflow Plexalyzer. Sur GitHub, il s’agit de .github/workflows/plexalyzer-scan.yml, et Plexicus enregistre le jeton comme secret de dépôt PLEXALYZER_TOKEN.
La colonne indique Pipeline Pending jusqu’à l’acceptation de la pull request, puis Pipeline Configured.

Rien ne s’exécute dans votre CI tant qu’un membre de votre équipe n’a pas relu et fusionné cette pull request. Votre équipe garde la maîtrise de la fusion.

Configurer manuellement la GitHub Action Plexicus

Si vous écrivez le workflow vous-même, utilisez l’action officielle plexicus/plexicus-action (présentée comme Plexalyzer Action sur le site Plexicus), qui exécute le scanner dans votre workflow et peut signaler les constats sur la pull request.

Copiez le jeton Plexalyzer depuis Plexicus.
Dans GitHub, ajoutez un secret de dépôt nommé PLEXALYZER_TOKEN dans la section Secrets and variables, Actions du dépôt.
Ajoutez la variable de dépôt contenant l’ID de votre dépôt Plexicus, comme indiqué dans le README de l’action.
Transmettez le secret à l’entrée plexalyzer-token, avec repo-id, repo-name, branch, url, pr-id et workspace-path.

Si votre organisation active Autonomous Scan sous Settings Platform , un scan de pull request terminé par le pipeline publie un commentaire « Analysis Results » sur la pull request (ou « No issues found »), lorsque votre fournisseur de gestion de code source prend en charge les commentaires de pull request. Plexicus génère ensuite des correctifs IA pour ces constats et ouvre une seule pull request groupée, intitulée « Multiple security fixes », depuis une nouvelle branche Plexicus-AI-Remediation-. Il ne la fusionne jamais : votre équipe la relit comme n’importe quelle autre pull request.

Jenkins

L’intégration Jenkins exécute l’image Docker de la CLI Plexalyzer : l’agent de build doit donc disposer de Docker. Ajoutez le jeton comme identifiant (credential) Jenkins de type Secret text, avec l’ID exact plexalyzer-token. Copiez Jenkinsfile, .plexalyzer/jenkins-plexalyzer-cli.groovy et .plexalyzer/custom_config.yml depuis le dépôt plexicus/jenkins-cli-pipeline, puis créez un job Pipeline qui utilise Pipeline script from SCM.

Choisissez les moteurs dans custom_config.yml à l’aide des noms de bundle :

# .plexalyzer/custom_config.yml
excluded_tools:
  - plexicus-iac   # pas de code d'infrastructure dans ce dépôt
  - plexicus-cicd

Utilisez plutôt included_tools pour limiter un scan à un ensemble fixe. Paramètres de build utiles :

Paramètre	Rôle
`PROJECT_NAME`, `BRANCH_NAME`	Nom du dépôt et libellé de branche affichés dans Plexicus
`REPOSITORY_ID`	ID du dépôt existant ; à laisser vide lors du premier scan
`OUTPUT_FORMAT`	`pretty`, `json` ou `sarif` ; JSON et SARIF sont aussi archivés comme artefacts de build
`ONLY_GIT_CHANGES`	Ne scanne que les fichiers modifiés dans le dernier commit ; nécessite une profondeur de checkout d’au moins 2
`PLEXICUS_URL`	L’URL de base de votre instance Plexicus, pour les déploiements auto-hébergés

Le code de sortie 0 signifie qu’aucun constat n’a été trouvé, et 1 que des constats ont été détectés. Dans les deux cas, le build est marqué Success : par défaut, les constats ne bloquent donc jamais la livraison. Le code de sortie 500 correspond à une erreur fatale, comme un jeton refusé ou un backend injoignable. Pour faire échouer le build en cas de constats, modifiez handleExitCode() dans le script du pipeline et faites en sorte que case 1 définisse le résultat du build sur FAILURE.

Un modèle de constat unique

Quelle que soit la source (un moteur Plexicus, une exécution CI, Upload Scan, un connecteur, un registre ou un compte cloud), chaque résultat aboutit dans un modèle de constat commun : vous pouvez ainsi filtrer, prioriser et produire des rapports sur l’ensemble en une seule fois.

Normalisation

Un processeur propre à chaque outil lit la sortie brute du scanner (JSON, SARIF, CSV ou XML) et l’inscrit dans le schéma commun : outil, ID de règle, titre, description, fichier, ligne et colonnes, CWE, et une sévérité sur cinq niveaux, Critical, High, Medium, Low et Informational. L’Activity Center affiche cette étape comme « Processing results » (« Normalizing and ingesting findings »), puis Completed, puis « Enriched » (« AI analysis and prioritization applied »). Dans une exécution marquée Partial, certains outils ont échoué. Ses constats sont réels, mais la couverture est incomplète ; utilisez Relaunch scan dans l’Activity Center pour relancer le scan tout en conservant vos constats (module 2).

Chaque constat reçoit aussi un type dérivé de son moteur, comme SAST, SCA, Secrets, License, Configuration ou Cryptography. Les constats Container sont de type SCA lorsqu’ils portent une CVE ou un paquet, et de type Configuration sinon. Les résultats importés en SARIF sont de type SAST.

Enrichissement

Champ	Ce qu’il apporte
CWE et OWASP	Les constats dotés d’une CWE sont rattachés à une catégorie de l’OWASP Top 10, avec une courte justification, par exemple CWE-89 sous A03 Injection. Les constats sont aussi rattachés à l’OWASP CI/CD Top 10 et aux référentiels de conformité que vous avez activés.
CVE et EPSS	Le score EPSS, la probabilité qu’une CVE soit exploitée en conditions réelles, n’est renseigné que pour les constats qui portent une CVE. Les autres affichent No data.
CVSS	Score et vecteur CVSS v3 et v4, disponibles comme colonnes du tableau.
Priorité et autres	Un score de priorité de 0 à 100, le langage et le type de remédiation. Le module 4 explique la priorité et l’atteignabilité.

SARIF 2.1.0 est aussi le format d’export des constats ; le module 8 détaille les exports et ce qu’ils contiennent.

Déduplication

Un nouveau constat devient un doublon (Duplicate) d’un constat antérieur du même dépôt lorsqu’il se situe dans le même fichier, à la même ligne, et qu’il partage soit la CVE et la CWE (constats de dépendances), soit le même type de constat (constats de code sans CVE). Le constat conservé hérite de la sévérité et du CVSS les plus élevés de ses doublons : la déduplication ne sous-estime donc jamais le risque.

Sous-constats

Les constats de dépendances qui portent sur la même bibliothèque, la même version et la même CVE au même emplacement sont regroupés sous un constat principal, en tant que sous-constats. La vue détaillée d’un sous-constat affiche Go to Parent Finding à la place de son propre bouton de remédiation. Par défaut, la liste des constats masque les doublons, les sous-constats, les faux positifs, les constats supprimés et ceux encore en cours d’enrichissement (module 4) ; les totaux du Dashboard sont traités dans le module 2.

Registres et comptes cloud comme sources complémentaires

Selon votre offre et les fournisseurs activés pour votre organisation, les registres et les comptes cloud apportent une couverture complémentaire qui alimente le même modèle de constat. Les registres de conteneurs se connectent sous Settings Integrations Registry : Docker Hub, JFrog Artifactory, Amazon ECR, Google GCR, Google GAR, Azure ACR, GitHub GHCR, GitLab Container Registry et Quay.io. Saisissez les identifiants dans l’onglet Setup et cliquez sur Connect ; Plexicus teste la connexion avant d’enregistrer. Dans l’onglet List, utilisez Discover images, puis Scan images. Ensuite, Plexicus resynchronise chaque registre connecté une fois par jour : n’utilisez donc ces boutons que si vous avez besoin d’une actualisation immédiate. Les images dont le Lifecycle est Old reçoivent un constat Medium « Outdated registry image ». Utilisez Link to repo avec le chemin d’un Dockerfile pour rattacher une image à sa source, ce qui active Remediate in repo. Les résultats arrivent dans l’onglet Registry de Findings.

Les comptes cloud s’ajoutent sous Settings Integrations Cloud Deployment , qui liste les fournisseurs cloud pris en charge, comme AWS, Azure et Google Cloud Platform. L’enregistrement d’un compte crée un actif sous Assets Cloud Assessment ; Scan Now lance le scan, et les résultats arrivent dans l’onglet Cloud, avec les filtres Provider, Region et Resource. Les constats Cloud et SCM ne proposent jamais de remédiation par IA, car il n’y a aucun fichier de dépôt à corriger.

Points clés à retenir

Les moteurs sont des bundles gérés. Définissez les valeurs par défaut de l’organisation sur la page Connectors et surchargez par dépôt, avec Configure, les moteurs SAST, SCA, Secrets, IaC, CI/CD et de nomenclature ; Container, License et SCM restent au niveau de l’organisation.
Enregistrer une sélection propre à un dépôt déclenche un Re-Scan qui efface les constats de ce dépôt, et les modifications de Severity et d’Advanced Options faites dans la console s’appliquent à toute l’organisation.
Le filtre Severity écarte des résultats après le scan : par défaut, les résultats Low et Informational ne sont donc remontés pour aucun moteur ; les scans de code ignorent déjà les chemins de test et de documentation courants, sauf pour les secrets.
Upload Scan, l’import SARIF 2.1.0 et les connecteurs commerciaux font entrer des résultats externes dans le même modèle, en tant que candidats qui exigent encore une preuve.
En CI, chaque exécution de Plexalyzer s’authentifie avec le jeton Plexalyzer de l’organisation ; Setup Pipeline ouvre une pull request que votre équipe relit, et les builds Jenkins passent malgré les constats, sauf si vous modifiez handleExitCode().
Quelle que soit sa source, chaque résultat est normalisé, enrichi (CWE, OWASP, CVE, EPSS et CVSS), dédupliqué en conservant la sévérité la plus élevée, et regroupé en sous-constats.