Aller au contenu

Notes de version ASPM 2026 🚀🚀

Notes de version ASPM de Boost Security pour 2026, de la plus récente à la plus ancienne.

2026-09-30

Politiques de Scanner

  • Suppression Sécurisée des Politiques de Scanner

    La liste des Politiques de Scanner indique désormais à combien de scanners chaque politique est assignée, dans une nouvelle colonne Scanners Assignés. Tant que ce nombre est supérieur à zéro, l'action Supprimer est grisée et indique ce qui doit se passer en premier, plutôt que d'échouer avec une erreur peu claire après confirmation de la suppression.

    Le nombre renvoie directement à la page Couverture des Scanners filtrée sur cette politique, pour que les scanners à déprovisionner ne soient qu'à un clic. La Couverture des Scanners dispose d'un filtre Politique de Scanner correspondant sous Plus.

Intégration Jira

  • Paramètres de Fermeture Automatique par Projet

    La fermeture automatique se configure désormais sur chaque projet Jira plutôt qu'une seule fois par connexion. Chaque projet dispose de son propre bouton Fermeture automatique et de son propre Statut de fermeture, choisi parmi les statuts que ce projet définit réellement dans Jira, de sorte qu'un statut d'un projet ne peut plus être appliqué à un autre. Chaque ligne est enregistrée indépendamment, et le choix d'un type de problème est désormais mis en attente derrière ce même bouton Enregistrer au lieu de s'appliquer dès sa sélection. Le bouton de fermeture automatique à l'échelle de la connexion et sa boîte de dialogue de statut ont disparu.

    Un projet ajouté à partir de maintenant démarre avec la fermeture automatique Désactivée et sans statut de fermeture, au lieu de copier les deux depuis le projet par défaut du compte. Activez-la pour chaque nouveau projet pour lequel vous la souhaitez. Les projets existants conservent les paramètres qu'ils ont déjà.

    Boost Security vérifie un statut par rapport au workflow Jira du projet avant de l'enregistrer, et signale un statut enregistré que Jira n'offre plus afin qu'il puisse être corrigé.

API

  • Les Clés API Sont Limitées à Leur Rôle

    Une clé API dispose désormais exactement de l'accès que son Rôle lui accorde. Une clé Endpoint, comme un jeton de déploiement créé depuis la page Installation de Endpoint Protection, enregistre des appareils. Une clé Data Upload, que Boost Security crée et gère pour des intégrations telles que l'Orchestration Zero Touch, téléverse les résultats de scan, de SBOM et de télémétrie. Aucune des deux ne peut lire quoi que ce soit d'autre dans la plateforme. Auparavant, chaque clé disposait également d'un accès en lecture à l'échelle de la plateforme en plus du rôle qui lui était attribué.

    Les clés existantes ont été migrées et continuent de se comporter comme avant, à une exception près : une clé dont le seul rôle était Data Upload ou Endpoint a perdu l'accès en lecture. Si vous utilisiez une clé Endpoint ou Data Upload pour interroger l'API GraphQL, ces requêtes échouent désormais — créez une clé User ou Viewer pour les lectures. Voir Rôles des Clés API.

Politiques

  • Les Règles de Politique Peuvent Correspondre à une Confiance Non Définie

    L'attribut Confidence dans l'éditeur de règles de politique propose désormais Non définie aux côtés de High, Medium et Low, afin qu'une règle puisse cibler les résultats dont le scanner n'a jamais signalé de confiance. Jusqu'à présent, cette valeur ne figurait pas dans la liste et ces résultats ne pouvaient être capturés qu'indirectement. Voir Correspondance avec une Confiance Non Définie.

    Cela change ce qu'une règle peut être écrite pour exprimer, pas ce que toute règle enregistrée correspond déjà : une confiance non définie a toujours été classée en dessous de Low, donc une règle correspondant à une confiance inférieure à Medium correspondait déjà à ces résultats. Aucune politique n'a été migrée.

Provisionner les Scanners

  • Ignorer le Scan Initial Lors du Provisionnement

    La fenêtre modale de provisionnement des scanners propose désormais une case à cocher Ignorer le scan initial après le provisionnement à côté du bouton Terminer, à la fois en provisionnement Simple et Avancé. La cocher provisionne les scanners sélectionnés sans lancer de tâches de scan, afin que la mise sous couverture d'un grand nombre de dépôts n'inonde plus vos pipelines CI/CD. Le scan initial s'exécute toujours sauf si vous cochez la case, et ce choix ne s'applique qu'au provisionnement en cours.

    Ignorer le scan laisse les catégories de sécurité concernées afficher l'état En attente jusqu'à ce qu'un scan analyse l'actif — y compris les catégories actuellement couvertes, car une catégorie affiche En attente dès que l'un de ses scanners attend un premier scan. Rien n'est mis en file d'attente : la prochaine poussée vers la branche par défaut, ou un scan manuel, lève cet état. Voir Ignorer le Scan Initial.

Findings

  • Tickets Jira dans l'Export CSV des Findings

    Les exports CSV Findings et Violations se terminent désormais par trois colonnes décrivant le ticket Jira qui suit un résultat : ticket_key, ticket_url et ticket_status. Un résultat sans ticket exporte trois cellules vides. Voir Colonnes du Ticket Jira.

    Les colonnes sont ajoutées après les colonnes existantes, qui conservent leur nom, leur position et leur valeur, de sorte qu'un script existant lisant l'export par en-tête ou par index de colonne continue de fonctionner.

Intégration Azure DevOps

  • Organisations Déclarées pour les Intégrations Microsoft Entra ID et App Registration

    Les intégrations Azure DevOps reposant sur Microsoft Entra ID ou une App Registration couvrent désormais exactement les organisations que vous déclarez, au lieu de les découvrir. Les deux assistants d'installation gagnent une étape permettant de déclarer la liste avant l'installation des webhooks, et chaque organisation est validée par rapport aux identifiants de l'intégration lorsque vous cliquez sur Suivant : elle doit être lisible et contenir au moins un projet visible. Les projets au sein d'une organisation déclarée sont toujours découverts automatiquement, et les intégrations par jeton d'accès personnel restent inchangées.

    Après l'installation, la liste se modifie depuis l'onglet Configuration des détails de l'intégration, où un chevron sur chaque ligne Microsoft Entra ID ou App Registration ouvre l'éditeur. Supprimer une organisation détache ses projets tout en conservant leurs résultats existants. Les intégrations existantes ont été initialisées avec les organisations que Boost Security couvrait déjà ; vérifiez cette liste initiale une fois, car les organisations qui avaient déjà cessé d'être couvertes n'ont pas été reportées. Voir Organisations Déclarées.

2026-08-19

API

  • Expiration des clés API

    Les clés d'application peuvent désormais recevoir une expiration. La boîte de dialogue Ajouter une clé d'application propose une Expiration de 30 jours, 60 jours, 90 jours ou 1 an, et les clés restent par défaut sans expiration. Une nouvelle colonne Expiration dans la liste des clés d'application indique quand chaque clé expire.

    L'expiration d'une clé existante — y compris une clé créée sans expiration — peut être modifiée depuis la ligne de la clé à tout moment, et peut être avancée ou reportée. Une clé expirée cesse de s'authentifier et reste dans la liste, marquée EXPIRED, jusqu'à ce qu'un administrateur la supprime.

2026-08-13

Rapports de posture

  • Couverture de scanner en attente sur le graphique de couverture

    Le graphique de couverture sur la page Rapport empile désormais un quatrième état, En attente, à côté de Couvert, Erreur de scan et Non couvert. Il comptabilise les actifs dont les scanners provisionnés n'ont pas encore rapporté de résultat de scan — l'état dans lequel se trouve un scanner entre le moment où il est provisionné et celui où il termine son premier scan. Ces actifs étaient auparavant exclus des barres, donc les comptes ayant récemment provisionné des scanners verront des barres plus hautes qu'auparavant, et la légende du graphique nomme désormais chacun des quatre états.

  • Comptes exacts sur les graphiques de rapport

    Survoler n'importe quel graphique sur la page Rapport — Couverture, Violations, Résultats, Risques critiques, et les tendances de Vulnérabilité et de Couverture par type de résultat — affiche désormais les comptes exacts derrière la barre ou le point, au lieu de devoir les lire sur l'axe.

2026-08-03

Couverture des scanners

  • Politiques de Scanner

    Les Politiques de Scanner sont des ensembles nommés et réutilisables de directives qui régissent le comportement des scanners auxquels elles sont assignées. Définissez une politique une fois sur la nouvelle page Couverture des scanners → Politique de Scanner, puis assignez-la aux scanners sur l'ensemble de vos actifs.

    Cette première version inclut une directive, Correspondance de motif de fichier, qui restreint un scanner aux fichiers qu'il est censé couvrir : le scanner ne s'exécute que lorsque les fichiers modifiés par une pull request ou un commit poussé incluent une correspondance avec l'un des motifs de la politique ; sinon, le scan est ignoré et une vérification réussie est publiée sur le SCM. Utilisez-la pour restreindre un scanner Infrastructure-as-Code aux manifestes Terraform et Kubernetes, ou un scanner SCA aux fichiers de verrouillage de dépendances. D'autres directives étendront ce qu'une Politique de Scanner peut régir.

2026-05-13

Intégrations SCM

  • Bitbucket : authentification par jeton API (transition de l'application Marketplace)

    L'intégration Bitbucket de Boost utilise désormais uniquement l'authentification par jeton API suite à l'abandon par Atlassian du modèle d'application Marketplace. Les utilisateurs se connectent via un e-mail et un jeton API et sélectionnent leur espace de travail dans une liste déroulante au sein de la carte d'intégration.

    • L'activation de l'orchestration ZTP utilise automatiquement le jeton configuré — aucune configuration d'identifiant distincte n'est requise.
    • Conseils de migration : ne supprimez pas et ne recréez pas votre intégration Bitbucket existante avant que les outils et la documentation de migration ne soient disponibles. Le chemin recommandé sera communiqué le moment venu.

Remédiation et gouvernance alimentées par l'IA

  • Corriger avec l'IA : disponible en général

    Corriger avec l'IA est désormais disponible en général pour tous les utilisateurs — aucun indicateur de fonctionnalité requis. Le bouton Corriger avec l'IA est visible et actionnable sur tous les résultats pris en charge. Si la création de la pull request échoue, un lien direct vers les journaux du pipeline est fourni pour faciliter le dépannage.

Politique

  • Politique paramétrée : configuration Jira et notification sortante par actif

    Les équipes peuvent désormais configurer les paramètres Jira et de notification sortante par actif à l'aide de la Configuration externe, accessible depuis la page Gestion des actifs sous Actions. Lors de la création d'une action de règle de politique pour les notifications ou les tickets, les utilisateurs choisissent entre le Concepteur de politique (paramètres à l'échelle de l'organisation) ou la Configuration externe (dérogations spécifiques à l'actif).

2026-04-21

Scanners

  • SBOM : détection de paquets NuGet sans fichier de verrouillage

    Boost prend désormais en charge l'analyse SBOM pour les projets .NET n'utilisant pas de fichiers de verrouillage, à l'aide du scanner OSV Scalibr. Cela étend la couverture de l'analyse de composition logicielle aux dépendances NuGet auparavant indétectables sans fichier de verrouillage.

    Recommandation

    N'activez qu'un seul scanner SBOM à la fois. Les scanners concurrents écrasent mutuellement leurs résultats à chaque exécution ; l'interface utilisateur n'empêche pas actuellement cette configuration.

Intégration avec les fournisseurs de contexte Code au Cloud

  • Intégration Upwind : accessibilité en temps réel pour les charges de travail conteneurisées

    Boost s'intègre désormais avec Upwind pour enrichir les résultats avec le contexte d'accessibilité en temps réel. Les équipes peuvent identifier les vulnérabilités exposées sur Internet dans les charges de travail conteneurisées et corréler les images à travers plusieurs sources telles que ECR et Google Artifact Registry. - Le contexte d'accessibilité Internet d'Upwind peut être utilisé directement dans les règles de politique pour prioriser les risques exposés en temps réel. - Disponible sous un indicateur de fonctionnalité au niveau du compte.

Remédiation et gouvernance alimentées par l'IA

  • Corriger avec l'IA : prise en charge de toutes les plateformes SCM

    La génération de correctifs alimentée par l'IA est désormais prise en charge sur les quatre plateformes de gestion de code source prises en charge : GitHub, GitLab, Bitbucket et Azure DevOps. Les équipes sur n'importe quel SCM peuvent désormais recevoir des pull requests de remédiation générées par l'IA directement dans leurs dépôts.

    Remarque

    Les modèles de branche peuvent nécessiter une mise à jour manuelle pour activer cette fonctionnalité sur les intégrations existantes. Une documentation complète est fournie pour le processus de configuration.

  • Corriger avec l'IA : détection des faux positifs et agent de contrôle qualité

    Deux nouveaux contrôles de qualité ont été ajoutés au flux de remédiation par l'IA.

    • Détection des faux positifs : l'agent IA évalue désormais si un résultat est probablement un faux positif avant de générer un correctif. Lorsqu'un faux positif est identifié, il ajoute un commentaire de suppression noboost plutôt que de produire une modification de code.
    • Agent de contrôle qualité : un second agent examine le correctif généré. S'il n'est pas satisfait, il renvoie le correctif à l'agent de génération avec des commentaires pour un maximum de trois cycles d'amélioration avant d'échouer de manière ouverte.

2026-03-30

Remédiation et gouvernance alimentées par l'IA

  • Corriger avec l'IA : intégration des pull requests

    Le flux de correction alimenté par l'IA affiche désormais l'état directement dans le panneau Détails du résultat. Lorsqu'un correctif est soumis sous forme de pull request, son statut de PR est visible en ligne — donnant aux développeurs un retour immédiat sans quitter l'interface Boost.

  • Corriger avec l'IA : validation des secrets et conseils de rotation

    Lorsque l'agent IA corrige un résultat de type Secrets, Boost valide désormais la modification proposée avant de l'appliquer. Un avertissement est automatiquement publié dans la pull request résultante conseillant au développeur de faire tourner ou de désactiver le secret concerné, garantissant que la remédiation est complète — pas seulement au niveau du code.

Intégration avec les services de notification tiers

  • Intégration Jira : sélection du type de problème

    Les utilisateurs peuvent désormais configurer le type de problème Jira (par ex., Bug, Tâche, Story) directement depuis la carte d'intégration Boost, garantissant que les résultats exportés vers Jira sont créés avec le type de problème correct pour le flux de travail de chaque équipe.

Gestion des actifs

  • Export : colonne Type d'actif

    L'export CSV de Gestion des actifs inclut désormais une colonne dédiée Type d'actif, fournissant un contexte supplémentaire lors de l'examen des données d'actifs exportées en dehors de la plateforme Boost.

Scanners

2026-03-11

Intégration avec les scanners tiers

  • Test de sécurité dynamique des applications (DAST) avec StackHawk

    Boost prend désormais en charge le DAST via une nouvelle intégration StackHawk, permettant aux équipes de détecter les vulnérabilités d'exécution dans les applications web en plus de la couverture existante des risques statiques et de la chaîne d'approvisionnement.

    • Une nouvelle carte d'intégration StackHawk est disponible sur la page Intégrations. L'activation nécessite une clé API StackHawk et un webhook configuré manuellement dans StackHawk.
    • Les nouvelles applications ajoutées dans StackHawk sont automatiquement synchronisées lors du prochain cycle de synchronisation planifié.
    • L'analyse DAST peut être activée via l'Orchestration Zero Touch (ZTP), et les résultats apparaissent sous une catégorie dédiée de scanner de Politique.
    • Remarque : cette fonctionnalité est actuellement disponible sous un indicateur de fonctionnalité.

Gestion des actifs

  • Regroupement au niveau de l'application

    La page Gestion des actifs introduit une nouvelle vue de regroupement Application qui organise les actifs par nom d'application. Chaque application peut contenir plusieurs environnements, offrant une structure plus claire pour les équipes gérant des déploiements multi-environnements.

Intégration avec les services de notification tiers

  • Prise en charge de plusieurs comptes Jira

    Boost prend désormais en charge l'ajout de plusieurs intégrations Jira à un seul compte. Les équipes peuvent mélanger les connexions par jeton d'accès personnel (PAT) et authentifiées via le marketplace, et configurer plus de deux intégrations si nécessaire.

    • Les identifiants de tickets sont affichés sur la page Résultats. Remarque : les identifiants peuvent apparaître identiques dans différents projets Jira, mais chacun renvoie vers l'URL de problème correcte dans le backend.

Paramètres du compte

  • Augmentation de la longueur des messages personnalisés de pull request

    La limite de caractères pour les messages de PR personnalisés a été augmentée de 200 à 1 000 caractères, donnant aux équipes de sécurité et de plateforme plus de marge pour communiquer le contexte de la politique et les conseils de remédiation aux développeurs dans les commentaires de pull request.

2026-02-19

Améliorations de la chaîne d'approvisionnement logicielle et de la politique

  • Cette version affine le moteur de politique, étend le filtrage SBOM, et introduit un accès anticipé à la visibilité des postes de travail des développeurs pour gérer les risques à travers chaque couche de la chaîne d'approvisionnement.

    • Politique de délai de refroidissement pour paquets à faible maturité

      Pour se prémunir contre le « brandjacking » et les paquets malveillants zero-day, Boost signale désormais les dépendances de moins de 7 jours comme étant de faible maturité. Cela permet aux équipes de créer une barrière configurable contre l'introduction précipitée de code neuf non vérifié en production.

    • Filtrage avancé des versions de paquets SBOM

      Les utilisateurs peuvent désormais filtrer les SBOM par écosystème, nom de paquet et plages de versions spécifiques (compatible semver). Cela permet d'identifier bien plus rapidement si des versions vulnérables spécifiques existent quelque part dans l'environnement.

Améliorations cloud et intégration

  • AWS Bedrock : expérience de configuration améliorée

    Le processus de configuration de Bedrock a été simplifié avec une nouvelle boîte de dialogue présentant les détails des autorisations requises, des listes déroulantes de sélection de région, des info-bulles guidées, et la possibilité de sélectionner des profils d'inférence spécifiques pour les modèles applicables.

  • Jira : attribution automatisée des contributeurs

    Lors de l'exportation des résultats SAST ou Secrets vers Jira, Boost identifie et inclut désormais automatiquement le développeur qui a introduit le code en tant que contributeur. Cela élimine les recherches manuelles dans l'historique git lors de l'attribution des tickets.

2026-01-29

Sécurité de la chaîne d'approvisionnement et détection de logiciels malveillants

  • Bannière de signalement des logiciels malveillants

    Boost dispose désormais d'une bannière de signalement des logiciels malveillants à haute visibilité. Si un paquet malveillant est identifié dans votre environnement, une alerte immédiate apparaît lors de la connexion, fournissant des détails sur l'incident et des conseils sur la manière d'identifier les actifs impactés.

Gestion de politique d'entreprise

  • Héritage de politique

    Maintenez la cohérence organisationnelle en définissant des « Politiques de base » sur lesquelles d'autres politiques peuvent s'appuyer. Les règles de base s'exécutent en premier pour créer un socle de sécurité global, tandis que les politiques enfants ajoutent des configurations spécifiques pour les scanners et les composants.

  • Règle de politique : bloquer lorsqu'un correctif est disponible

    Une nouvelle action de politique permet aux équipes de déclencher spécifiquement des blocages ou des alertes sur les résultats open source dont une version corrigée connue est disponible, priorisant la remédiation actionnable plutôt que les vulnérabilités non corrigeables.