Automatisation, intégrations et outils pour développeurs

Plexicus Automation : déclencheurs, étapes et modèle de flux

Plexicus Automation fonctionne aux côtés du workflow Valider → Comprendre → Remédier de Proof-Driven AppSec. Il applique à chaque constat correspondant les décisions récurrentes de votre équipe (« à corriger tout de suite », « à passer en ticket », « à soumettre d’abord au responsable AppSec »). Ouvrez-le depuis la barre latérale principale, à gauche ; la page s’intitule Automations, et les chemins de ce module partent de là, par exemple Automations New automation .

Imaginez une injection SQL de sévérité Critical dans le gestionnaire de connexion de votre API de facturation. Un flux peut demander une pull request de remédiation, attendre l’approbation de votre responsable AppSec, ouvrir une issue Jira et publier une notification dans l’application. Rien n’est fusionné automatiquement ; votre équipe relit la pull request.

Déclencher → Décider → Agir → Consigner

Chaque flux comporte quatre parties :

1. Déclencher. Un événement lance une exécution. Chaque flux a exactement un déclencheur.
2. Décider. Les étapes de condition orientent l’exécution selon la sévérité, le type de constat, le dépôt ou les données du webhook. Chaque étape possède en outre un chemin de succès et un chemin d’erreur.
3. Agir. Les étapes d’action demandent une remédiation, ouvrent un ticket, notifient des personnes ou appellent un système connecté.
4. Consigner. Les exécutions sont enregistrées avec des logs par étape, les modifications des flux sont inscrites au journal d’audit (module 10) et les tickets sont liés dans la chronologie du constat.

Déclencheurs

Déclencheur	Une exécution démarre lorsque	Remarques
New finding	Plexicus crée un constat	Filtres facultatifs : Severity, Finding type, Repository ID
Finding enriched	Plexicus ajoute du contexte à un constat existant	Mêmes filtres facultatifs
Finding reopened	Un scan détecte de nouveau un constat après sa résolution	S’exécute à chaque réouverture, une fois l’exécution précédente terminée
Webhook	Une requête signée atteint l’Ingress URL du flux	Traité dans la leçon 3
Schedule	Une planification cron se déclenche	Cron à 5 champs, plus un fuseau horaire (UTC par défaut)
Manual	Quelqu’un lance l’exécution avec Run now	Affiché comme « Manual only » dans la liste

Pour définir le déclencheur, sélectionnez le nœud Trigger sur le canevas et modifiez son panneau ; les déclencheurs ne s’ajoutent pas par glisser-déposer depuis la palette. Après l’enregistrement, rouvrez le panneau du déclencheur pour vérifier que vos filtres ou votre planification ont bien été conservés, et lancez une exécution à blanc du flux avant qu’un administrateur ne l’active.

Deux règles encadrent les flux liés aux événements de constat. D’abord, un flux s’exécute automatiquement au plus une fois par constat. L’exception est un flux dont le déclencheur est Finding reopened : il s’exécute à chaque réouverture, à condition que son exécution précédente pour ce constat soit terminée. Un flux New finding ou Finding enriched ne s’exécute pas de nouveau lors d’une réouverture : créez donc un flux Finding reopened distinct pour agir sur les constats rouverts. Ensuite, Deduplicate by fingerprint rattache les constats qui partagent la même empreinte de secret à l’exécution déjà en cours : une clé d’API divulguée entraîne ainsi une seule rotation au lieu de cinq.

Étapes

Étape	Ce qu’elle fait	Paramètres requis
Remediation	Demande une remédiation IA, par exemple une pull request à relire (module 7)	Type de remédiation
Ticket	Ouvre un ticket auprès d’un fournisseur comme Jira	Fournisseur de tickets (clé de projet facultative)
Notify	Crée une notification dans l’application	Canal de notification, utilisé comme titre ; message facultatif
Wait for approval	Met l’exécution en pause jusqu’à ce que quelqu’un approuve ou rejette	Rôle d’approbateur et délai d’expiration facultatifs, ce dernier en secondes
Condition (if)	Suit l’arête « yes » si la condition est vraie, sinon l’arête « no »	Condition
Condition (switch)	Prend le premier cas correspondant, ou l’arête d’erreur si aucun ne correspond	Cas
Connector	Appelle une capacité d’une intégration enregistrée	Type de connecteur, capacité, nom du connecteur

Cinq étapes de rotation de secrets alimentent le modèle Secret rotation. Notify fonctionne uniquement dans l’application. Pour atteindre un autre système, utilisez une étape Ticket ou une étape Connector qui appelle une intégration HTTP API.

Les conditions utilisent une logique JSON restreinte. Celle-ci est censée correspondre aux constats Critical :

{ "==": [{ "var": "finding.severity" }, "Critical"] }

Opérateurs autorisés : ==, !=, >, <, >=, <=, and, or, not, in et var. Vous pouvez tester des champs du constat comme severity, type, status et repository_id, ainsi que les données du webhook sous la forme trigger.payload.FIELD. Les valeurs sont comparées à l’identique, casse comprise. Privilégiez le générateur visuel de conditions, et lancez une exécution à blanc sur un constat dont vous savez qu’il est Critical avant de vous fier à une condition écrite à la main.

Créer des flux en toute sécurité

Plexicus place plusieurs garde-fous entre une idée et un flux actif : brouillons désactivés, exécutions à blanc, activation réservée aux administrateurs, versions et historique des exécutions.

Trois façons de commencer

Modèles. Automations Start from a template propose des flux prêts à l’emploi :

• Auto-remediate + ticket : sur un nouveau constat, demande une remédiation IA, ouvre un ticket Jira et envoie une notification dans l’application si une étape échoue.
• Conditional remediation : les constats High et Critical passent en remédiation automatisée avec une pull request, et tous les autres deviennent un ticket Jira à trier.
• Secret rotation : effectue la rotation d’un secret divulgué, le stocke dans HashiCorp Vault, ouvre une PR en brouillon qui remplace la valeur codée en dur par une variable d’environnement, vérifie la nouvelle valeur en la relisant, attend l’approbation d’un administrateur, puis sort la PR de l’état de brouillon. Tout échec ouvre un ticket Jira.

Du prompt au flux. Automations New from prompt transforme en brouillon une description en langage naturel de 4 000 caractères au maximum, à l’aide du modèle d’IA configuré pour votre organisation. Par exemple : « When a critical finding is created, wait for admin approval, then open a Jira ticket. » Le brouillon liste tous les systèmes externes qu’il contactera sous This flow will contact:, et rien n’est enregistré tant que vous n’avez pas cliqué sur Confirm and save draft.

Éditeur visuel. Automations New automation ouvre trois volets : la palette d’étapes à gauche (Triggers, Logic, Actions et Integrations), le canevas au centre et l’inspecteur à droite, avec les onglets Config, Last run I/O et Notes. Faites glisser une étape sur le canevas ou double-cliquez pour en ajouter une. L’inspecteur indique pour chaque étape Configured ou Incomplete. La version actuelle ajoute l’annulation et le rétablissement, ainsi qu’un générateur de planification avec un aperçu de la prochaine exécution.

Quelle que soit la façon dont vous commencez, vous obtenez un brouillon désactivé qui ne fait rien tant qu’un administrateur ne l’a pas activé. Plexicus valide le flux à l’enregistrement, et les problèmes, comme deux arêtes qui partent d’une même branche vers des cibles différentes, apparaissent sous This flow has validation errors.

Exécutions à blanc

Une exécution à blanc parcourt l’ensemble du flux et simule chaque étape qui toucherait un système externe. Chaque étape consigne ce qu’elle aurait fait, par exemple « Would create jira ticket in project SEC », et les paramètres qui ressemblent à des secrets sont masqués. Les exécutions à blanc fonctionnent sur les brouillons, ne sont pas décomptées des limites d’exécution et apparaissent dans l’historique des exécutions avec un badge Dry run. Saisissez un Finding ID dans la barre supérieure de l’éditeur et cliquez sur Dry run. Dans la version actuelle, vous pouvez aussi tester des flux Schedule et Webhook sans Finding ID.

Activation et versions

Seuls les administrateurs de l’organisation peuvent créer, modifier, activer ou supprimer des flux ; les autres utilisateurs disposent d’un accès en lecture seule et peuvent toujours consulter l’historique des exécutions.

L’activation revérifie chaque connexion utilisée par le flux, y compris les étapes Connector et le fournisseur de l’étape Ticket. Si un test échoue, vous voyez Activation failed avec le connecteur en cause. Selon votre offre, le nombre de flux actifs et d’exécutions manuelles peut être plafonné.

Modifier un flux actif puis cliquer sur Save new version crée la version suivante. Les exécutions en cours restent sur la version avec laquelle elles ont démarré, et les anciennes versions sont conservées. Après l’enregistrement, vérifiez la colonne Status et activez la nouvelle version si elle affiche Inactive.

Historique des exécutions, statuts et approbations

Ouvrez Automations Edit Runs pour voir, pour chaque exécution, les colonnes Automation, Finding, Status et Started. Dépliez une ligne pour afficher les logs par étape, ou utilisez Replay pour rejouer une exécution pas à pas, avec l’entrée et la sortie de chaque étape.

Statut	Signification
Running	Les étapes sont en cours d’exécution
Waiting	En pause à une étape Wait for approval
Completed	Le flux a atteint une fin, par un chemin de succès ou un chemin d’échec
Failed	L’exécution s’est arrêtée sur une erreur, ou a dépassé la durée maximale de 30 jours
Cancelled	L’exécution a été arrêtée avant sa fin

Les exécutions Waiting affichent Approve, Reject et Cancel. Approve poursuit sur le chemin de succès. Reject et l’expiration du délai suivent le chemin d’erreur. Cancel se comporte comme Reject : l’exécution se poursuit sur le chemin d’erreur. Le délai est défini en secondes et vaut 7 jours par défaut (604 800 secondes). Si l’étape désigne un rôle d’approbateur, seuls les utilisateurs qui ont ce rôle peuvent approuver ou rejeter.

Tickets et intégrations sortantes

Plexicus se connecte à d’autres systèmes à deux endroits : Settings Integrations regroupe les connecteurs de ticketing qui alimentent le bouton Create Ticket des constats, et la page des intégrations d’automatisation regroupe les systèmes utilisés par vos flux.

Connecter Jira et ServiceNow

Ouvrez Settings Integrations Ticket Management , qui liste Jira, ServiceNow et Webhook.

Jira comporte quatre onglets : Credentials, Stage Configuration, Test Connection et Create Ticket. L’onglet Credentials demande les champs Email Address, API Token et Server URL, cette dernière étant l’adresse de votre instance Jira Cloud, par exemple company.atlassian.net.

ServiceNow demande un OAuth Token et votre Instance URL, par exemple https://dev12345.service-now.com. Plexicus crée des incidents à l’état New, avec la catégorie Security. Les connecteurs que vous pouvez activer dépendent de votre offre.

Les deux connecteurs comportent deux phases, que vous activez ou désactivez sous Stage Configuration :

• Create Issue couvre les tickets créés à partir des constats.
• Pull Request s’applique lorsque Plexicus ouvre une pull request de remédiation. Un ticket lié reçoit un commentaire avec le lien de la PR et passe en cours de traitement. Si aucun ticket n’est encore lié, Plexicus en crée un.

Chaque phase dispose d’un Priority Mapping (par défaut, Jira associe Critical à Highest, et ServiceNow associe Critical à « 1 - Critical ») et d’un Field Mapping facultatif, qui remplit les champs du ticket à partir des données du constat grâce à des variables de substitution comme %Finding.title%. La phase propose aussi des options de filtrage ; testez-les sur un constat d’exemple avant de vous y fier. Lancez Test Connection après avoir enregistré les identifiants.

Créer un ticket à partir d’un constat

Sur la page de détail d’un constat, la liste déroulante Create Ticket affiche chaque fournisseur configuré. Jira ouvre un formulaire avec Service, Issue Type (Bug, Task, Story, Epic), Project Key et un Priority Override facultatif. ServiceNow crée l’incident immédiatement à partir des mappages de la phase. Webhook envoie le constat vers le point de terminaison que vous avez configuré.

Plexicus lie l’ID, l’URL et le statut du ticket au constat, et ajoute une entrée « ticket created » à sa chronologie. Ne partez pas du principe que le ticket se ferme de lui-même lorsque le constat est résolu ; fermez-le via le workflow habituel de votre outil de suivi.

Webhooks sortants et intégrations d’automatisation

Le connecteur Webhook envoie les constats vers un point de terminaison HTTP que vous contrôlez. Son assistant comporte quatre étapes : Settings (Webhook Name, Webhook URL, HTTP Method POST ou PUT, Data Format), Authentication (None, Basic ou Bearer Token), Headers et Preview, où vous vérifiez la charge utile et envoyez un test.

La page des intégrations d’automatisation liste les systèmes externes connectés que vos automatisations peuvent utiliser : HashiCorp Vault, Kubernetes Secrets, Jira, ServiceNow, Source control, HTTP API et Outgoing webhook. Le champ Credentials reference contient un pointeur vers des identifiants stockés, jamais le secret lui-même. Chaque carte affiche Unverified, Healthy ou Unhealthy, et Save and test vérifie immédiatement une nouvelle intégration. Vous ne pouvez pas supprimer une intégration qu’un flux utilise encore.

Webhooks entrants signés

Un flux doté d’un déclencheur Webhook obtient sa propre Ingress URL. Dans le panneau du déclencheur, cliquez sur Generate new secret et copiez le secret immédiatement, car il ne s’affiche qu’une seule fois. Générer un nouveau secret remplace l’ancien sur-le-champ : mettez donc à jour tous les appelants en même temps. L’appelant signe le corps brut de la requête en HMAC-SHA256 avec ce secret et envoie le condensat hexadécimal dans l’en-tête X-Plexicus-Signature, sous la forme sha256=HEX_DIGEST. Le panneau fournit un exemple de requête prêt à l’emploi. Dans un shell, l’étape de signature se présente ainsi :

BODY='{"service":"billing-api","event":"deploy"}'
SIG=$(printf '%s' "$BODY" | openssl dgst -sha256 -hmac "$WEBHOOK_SECRET" | awk '{print $NF}')
curl -X POST "$INGRESS_URL" \
  -H "Content-Type: application/json" \
  -H "X-Plexicus-Signature: sha256=$SIG" \
  --data "$BODY"

Signez exactement les octets que vous envoyez. Si l’appelant resérialise le JSON après l’avoir signé, la signature ne correspond plus.

Réponse HTTP	Libellé dans Recent deliveries	Signification
202	Accepted	Une nouvelle exécution démarre pour chaque livraison acceptée
401	Invalid signature	La signature est absente ou ne correspond pas au corps et au secret actuel, ou aucun secret n’a encore été généré
409	Inactive	Le flux est inactif ou n’utilise pas de déclencheur Webhook
400	Invalid JSON	Le corps n’est pas un JSON valide
413	Payload too large	Le corps dépasse la taille maximale
429	Rate limited	Trop de livraisons pour l’organisation

Accès développeur : jetons d’API et API REST

Les scripts, les pipelines CI et les agents d’IDE accèdent tous à Plexicus au moyen de jetons. Choisir le bon jeton permet de garder des accès traçables et faciles à révoquer.

Jetons d’API personnels

Accédez à Settings API Tokens . Saisissez un Token name, choisissez une Expiration (30 days, 90 days ou No expiration) et cliquez sur Generate token. La valeur s’affiche une seule fois, sous « Save your token now ». Copiez-la, puis cliquez sur I’ve saved it. Le tableau Active tokens liste Name, Created, Expires et Type, avec Revoke sur chaque ligne.

Un jeton personnel n’a pas de scopes distincts. Il agit en votre nom, avec votre rôle et vos permissions dans l’organisation. Un jeton créé par un développeur peut faire ce que ce développeur peut faire dans la console, et rien de plus. La révocation d’un jeton prend effet immédiatement, et tout appel ultérieur avec ce jeton renvoie 401. La création des jetons est consignée dans le journal d’audit.

Bonnes pratiques :

• Créez un jeton par outil (un script de reporting, votre IDE, un job CI) afin de pouvoir en révoquer un sans casser les autres.
• Préférez une expiration à 30 ou 90 jours. Si vous choisissez No expiration, vérifiez la colonne Expires, car une longue durée de vie par défaut peut tout de même s’appliquer.

Le jeton Plexalyzer de l’organisation

Le jeton Plexalyzer, également appelé jeton du scanner CI/CD, appartient à l’organisation plutôt qu’à une personne. Il authentifie le scanner Plexalyzer dans vos pipelines. Les administrateurs le créent, avec une date d’expiration facultative, 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 . Le module 3 explique comment le stocker comme secret CI PLEXALYZER_TOKEN et comment configurer les pipelines.

Plexicus ne propose pas de jeton d’organisation pour les appels d’API généraux. Un script censé survivre à l’accès d’une seule personne nécessite donc tout de même un jeton d’API personnel : choisissez délibérément son propriétaire, donnez au jeton un nom qui lui est propre et révoquez-le dès qu’il n’est plus utile.

Jeton	Appartient à	À utiliser pour
Jeton d’API personnel	Vous, avec votre rôle	Les scripts, les intégrations, le serveur MCP
Jeton de la CLI	Vous, avec votre rôle	Plexicus TUI, jeton créé par plexicus login
Jeton Plexalyzer	L’organisation	Uniquement le scanner Plexalyzer en CI/CD

Les bases de l’API REST

Chaque requête envoie Authorization: Bearer suivi de votre jeton et Accept: application/json, ainsi que Content-Type: application/json pour les requêtes POST, PUT et PATCH. L’URL de base SaaS figure dans le guide de l’API sur docs.plexicus.ai ; un déploiement auto-hébergé utilise sa propre URL. Les chemins de ressources sont au pluriel, par exemple /repositories, /findings, /remediations, /repository-scans et /automations.

curl -H "Authorization: Bearer $PLEXICUS_API_TOKEN" \
     -H "Accept: application/json" \
     "$PLEXICUS_API_URL/findings?filters%5Bseverity%5D=critical,high&limit=25"

Les listes utilisent une pagination par curseur. Une réponse contient items, total et un lien next ; transmettez son curseur pour obtenir la page suivante. La plupart des points de terminaison renvoient 25 éléments par page par défaut, et limit permet de modifier ce nombre.

Les actions de longue durée renvoient 202 et se poursuivent en arrière-plan. POST /repository-scans avec un repository_id et un scan_type valant app ou sbom lance un scan. POST /remediations avec un finding_id demande un correctif IA ; interrogez GET /remediations?finding_id=... jusqu’à ce qu’il renvoie le diff et les recommandations (un 404 signifie que le résultat n’est pas encore prêt). Les actions d’IA sont imputées sur votre quota d’utilisation de l’IA, affiché dans Settings Billing et dans votre menu de profil (modules 7 et 10). Vous pouvez aussi lancer un flux via le point de terminaison des exécutions de /automations, pour 100 constats au maximum par appel, et éventuellement sous forme d’exécution à blanc.

Les erreurs suivent le format Problem Details de la RFC 7807. Une réponse 401 signifie que le jeton est invalide, expiré ou révoqué. Une réponse 403 signifie que le jeton fonctionne, mais que votre rôle ou votre offre n’autorise pas l’action. Une réponse 429 signifie que vous avez atteint une limite de débit : réessayez avec un backoff exponentiel.

Travailler depuis le terminal et l’IDE

Deux outils pour développeurs amènent les constats là où vous travaillez déjà : Plexicus TUI dans votre terminal et le Plexicus MCP server dans votre IDE.

Plexicus TUI

Téléchargez le binaire pour macOS Apple Silicon, macOS Intel ou Linux x86-64 depuis la page GitHub Releases de github.com/plexicus/tui. Ensuite :

plexicus --version   # vérifier l'installation
plexicus login       # se connecter via le navigateur
plexicus             # parcourir les constats et les dépôts connectés

Au premier lancement, un assistant de configuration vous demande l’URL de votre serveur Plexicus.

Touche	Action
F	Ouvrir les filtres
/	Rechercher
Entrée	Ouvrir le détail du constat
r	Demander une remédiation IA
p	Créer une pull request

Appuyez sur r, relisez le diff, et seulement ensuite appuyez sur p. La pull request suit votre processus de revue habituel, et votre équipe garde la maîtrise de la fusion.

Ce que fait plexicus login

plexicus login ouvre votre navigateur sur la page d’autorisation de Plexicus. Connectez-vous si nécessaire, y compris avec la 2FA si elle est activée. La page affiche « Authorizing Plexicus CLI… », puis « CLI authorized ». En coulisses, Plexicus crée un jeton d’API personnel nommé CLI - YYYY-MM-DD, valable 365 jours, et votre navigateur le transmet à la CLI sur une adresse locale 127.0.0.1. La CLI le stocke dans ~/.config/plexicus.

Comme il s’agit d’un jeton personnel ordinaire, il apparaît dans Settings API Tokens , où vous le révoquez. plexicus logout supprime uniquement la copie locale. Sur une machine sans interface graphique ni navigateur, générez plutôt un jeton personnel et exportez-le sous le nom PLEXICUS_API_TOKEN.

Le Plexicus MCP server

Le Plexicus MCP server (paquet plexicus-mcp) s’exécute localement sur votre machine et donne à un agent d’IDE compatible MCP un accès à l’API REST de Plexicus avec votre jeton personnel. Les clients documentés comprennent Cursor, VS Code, Windsurf et un agent de code en ligne de commande. La configuration se fait en trois étapes :

1. Choisissez un client.
2. Choisissez une méthode de lancement : uvx plexicus-mcp (recommandée), pipx run plexicus-mcp ou pip install plexicus-mcp.
3. Configurez votre jeton et établissez la connexion. Une fois un jeton généré, la section Use with your IDE (MCP) de la page API Tokens affiche des extraits préremplis : une commande d’une ligne pour les clients en ligne de commande et une configuration JSON pour Cursor, VS Code et Windsurf.

{
  "mcpServers": {
    "plexicus": {
      "command": "uvx",
      "args": ["plexicus-mcp"],
      "env": {
        "PLEXICUS_API_TOKEN": "YOUR_TOKEN",
        "PLEXICUS_API_URL": "YOUR_API_URL"
      }
    }
  }
}

La variable PLEXICUS_API_TOKEN est obligatoire. La variable PLEXICUS_API_URL est facultative ; elle pointe par défaut vers l’API SaaS et se définit pour les déploiements auto-hébergés. Avec un jeton incorrect, les outils renvoient « Authentication failed — the API token is invalid, expired or revoked. »

Le serveur expose 10 outils. Seuls request_scan et generate_remediation modifient quelque chose ; les autres sont en lecture seule.

Outil	Rôle
get_current_repository	Associer le remote git de votre espace de travail à un dépôt Plexicus
list_repositories, get_repository	Parcourir les dépôts, le nombre de constats par sévérité et l’état des scans
list_findings, get_finding	Filtrer par sévérité, statut, CWE ou titre, puis lire le détail
request_scan, get_scan_status	Lancer un scan app ou SBOM et en suivre l’avancement
generate_remediation, get_remediation	Demander un correctif IA, puis récupérer son diff et ses recommandations
get_security_posture	Totaux à l’échelle du compte et dépôts les plus à risque

Il fournit aussi trois prompts guidés (fix_finding, triage_findings, security_review) et deux ressources : plexicus://repositories et une ressource de constats par dépôt. Chaque outil renvoie un résumé lisible ainsi que les données brutes de l’API.

Points clés à retenir

• Chaque flux a un déclencheur, des étapes dotées de chemins de succès et d’erreur, et une exécution consignée. Un flux s’exécute une fois par constat ; seul un flux doté d’un déclencheur Finding reopened s’exécute de nouveau, à chaque réouverture.
• Les flux démarrent sous forme de brouillons désactivés. Exécutez-les à blanc, faites-les activer par un administrateur (l’activation reteste les connexions) et lisez les logs par étape, car Completed peut inclure une étape en échec.
• Jira, ServiceNow et les webhooks sortants se trouvent sous Settings Integrations Ticket Management . Les webhooks entrants doivent être signés en HMAC-SHA256 avec le secret actuel du flux.
• Les jetons d’API personnels agissent avec votre propre rôle ; le jeton Plexalyzer de l’organisation est réservé au scanner. Utilisez un jeton par outil et révoquez ceux dont vous ne vous servez pas.
• plexicus login crée un jeton personnel révocable pour Plexicus TUI. Le serveur MCP met 10 outils à la disposition des agents d’IDE, et les correctifs suggérés ne deviennent jamais des pull requests sans vous.