Nouveautés

Les équipes de développement ne peuvent pas définir de paramètres pour des jobs manuels individuels dans les pipelines, ce qui force de nouvelles exécutions coûteuses de pipelines complets pour de simples changements de paramètres. Certains paramètres d'intrant sont inconnus jusqu'à ce que les jobs précédents se terminent, les équipes sont donc obligées de prendre des décisions en temps réel basées sur le contexte du pipeline. Les intrants au niveau des jobs permettent la définition dynamique de paramètres lorsque les paramètres changent pendant l'exécution. Voici ce sur quoi nous travaillons :

La gestion d'images de conteneurs à travers plusieurs registres en amont est complexe et entraîne des incohérences. Le registre virtuel Docker agrège les images de plusieurs sources, y compris de Docker Hub, Harbor et Quay, via une interface unique avec des fonctionnalités de mise en cache et de gestion intelligentes. Voici ce que nous avons prévu :

Les équipes JavaScript/Node.js qui gèrent les dépendances dans plusieurs sources npm font face à une résolution incohérente et à une surcharge de configuration. Le registre virtuel NPM fournit une source unique de vérité pour les dépendances de paquets, une fonctionnalité critique pour les organisations qui migrent de JFrog Artifactory vers GitLab. Nous envisageons d'inclure :

Les discussions wiki n'ont pas lieu dans le contenu pertinent, ce qui freine l'efficacité et augmente les changements de contexte. Les commentaires contextuels inline assurent des fils de discussion liées directement au texte surligné et maintiennent les conversations connectées au contenu qu'elles référencent. Nous travaillons sur les éléments suivants :

Les attaques de la chaîne d'approvisionnement via des paquets malveillants posent un risque immédiat. Contrairement aux vulnérabilités ou expositions communes (CVE) qui peuvent rester dormantes pendant des mois, un paquet malveillant cause des dommages dès qu'il est ingéré. GitLab fait maintenant remonter les paquets malveillants directement dans les résultats d'analyse des dépendances afin que les équipes puissent identifier et répondre aux menaces actives avant qu'elles ne compromettent les systèmes de production. Voici les fonctionnalités prévues pour les pipelines :

Les responsables sécurité ont besoin de déployer la protection contre le push de secrets à grande échelle sans configuration manuelle projet par projet. Les profils de configuration de scan introduiront l'activation en masse via l'inventaire de sécurité et protégeront les projets sans nécessiter de changements YAML ou d'intervention des équipes de développement. Nous construisons actuellement les éléments suivants :

Alors que la protection contre le push de secrets bloque les commits en temps réel, le scan de pipeline fournit une couverture complémentaire, car il détecte les secrets dans l'historique du dépôt et les artefacts de pipeline. Ce profil permettra aux responsables sécurité d'activer une détection des secrets étendue dans les projets avec la même approche basée sur les profils, et créera une défense en profondeur sans surcharge de configuration. Fonctionnalités en cours :

Les tests statiques de sécurité des applications (SAST) restent fondamentaux pour la sécurité des applications, mais les exigences de configuration CI/CD freinent leur adoption. Le profil de scan des SAST permettra aux responsables sécurité de déployer l'analyse statique dans les projets via l'inventaire de sécurité, avec une détection automatique des langages et une activation d'Advanced SAST pour les langages pris en charge dans l’édition GitLab Ultimate. Voici les fonctionnalités prévues dans les prochaines versions :

Les équipes de sécurité effectuent actuellement des vérifications régulières pour s'assurer que la protection contre le push de secrets est activée pour les nouveaux projets, un processus manuel qui crée des lacunes dans la couverture. Les nouveaux projets GitLab Ultimate privés auront la protection contre le push de secrets activée par défaut, et les équipes avec des exigences spécifiques pourront la désactiver lors de la création de projet. Voici ce sur quoi nous travaillons :

Les équipes qui rencontrent des faux positifs dans la détection des secrets ont besoin de pouvoir exclure des chemins et valeurs spécifiques sans désactiver entièrement la protection. Les profils de configuration prendront en charge les exclusions afin que les équipes puissent ajuster la détection tout en maintenant une couverture étendue. Nous travaillons actuellement sur les éléments suivants :

La gravité des vulnérabilités par défaut ne reflète pas toujours les priorités de risque de l'organisation. Les équipes de sécurité peuvent automatiser les remplacements de gravité basés sur des règles (KEV/EPSS, CVSS, atteignabilité, CVE, CWE et type de scan) afin de mapper le risque aux besoins métiers et d'automatiser les processus de tri qui nécessitaient précédemment une intervention manuelle. Fonctionnalités prévues pour les prochaines versions :

La détection de secrets basée sur les modèles ne signale pas les mots de passe génériques comme admin_password=Password123!, car ils ne présentent pas un format reconnaissable. La détection contextuelle identifie les mots de passe génériques en analysant les modèles de code environnants et les conventions de nommage des variables, comblant un écart significatif dans la couverture de détection de secrets. Nous travaillons actuellement sur les éléments suivants :

Les portées PAT larges comme read_api et api créent un rayon d'impact excessif si les tokens sont compromis. Les permissions fines autorisent les tokens avec accès spécifique uniquement dans les ressources et opérations requises, et sont restreints à des projets et groupes spécifiques avec des combinaisons précises de lecture et écriture pour différents types de ressources. Voici un aperçu des fonctionnalités à venir :

Les équipes qui utilisent les variables CI pour les secrets ont besoin d'une gestion appropriée du cycle de vie, de rappels de rotation et d'un contrôle d'accès granulaire. GitLab Secrets Manager fournit un stockage de secrets dédié avec gestion d'expiration, portée environnement/branche et permissions basées sur les rôles afin de réduire la dépendance aux gestionnaires de secrets tiers pour les workflows CI. Fonctionnalités en cours :

Les organisations qui produisent des attestations SLSA ont besoin de fonctionnalités de distribution et de vérification. Les API d'attestation, l'intégration UI et la prise en charge de la vérification glab permettent aux utilisateurs de vérifier les artefacts en vue de compléter le workflow de sécurité de la chaîne d'approvisionnement de la génération d'attestation à la vérification. Nous travaillons sur les fonctionnalités suivantes :

Les organisations manquent de visibilité en fonction du contexte métier (application, unité commerciale ou équipe de développement). Le filtrage des attributs de sécurité permet de filtrer les vulnérabilités et dépendances par entités logiques, avec prise en charge des URL pour marquer les vues filtrées et prise en charge des clics dans le tableau de bord. Fonctionnalités actuellement prévues :

L'auto-remédiation, qui ne s'applique plus uniquement aux vulnérabilités de gravité FAIBLE, prend désormais en charge les niveaux de gravité configurables et les cibles de version. Les utilisateurs peuvent choisir des merge requests groupées ou individuelles pour les mises à jour des dépendances, avec des indicateurs UI qui mettent en évidence les vulnérabilités auto-remédiées. Fonctionnalités prévues dans les prochaines versions :

Les informations concernant les licences Dart/Flutter s'affichent actuellement avec le statut INCONNU, ce qui force les équipes à utiliser des sources de données externes. La prise en charge des analyses de licence pour le gestionnaire de paquets pub permet une visibilité précise des licences pour les dépendances Dart et Flutter. Nous envisageons d'inclure les fonctionnalités suivantes :

L'analyse Advanced SAST dans les grands dépôts peut dépasser les limites de temps des jobs de pipeline. Le scan incrémental met en cache les résultats des analyses précédentes, analyse uniquement le code modifié, réduit significativement le temps d'analyse et produit des résultats précis. Nous envisageons d'inclure :

Les tableaux de bord de sécurité ont besoin de formats exportables pour la communication avec les parties prenantes et la documentation relative à la conformité. L'exportation PDF réplique les panneaux du tableau de bord avec les filtres appliqués et les configurations par groupe pour le partage hors ligne et l'archivage. Fonctionnalités en cours de développement :

La veille des vulnérabilité a été améliorée grâce à des signaux de données supplémentaires (disponibilité d'exploitation, activité de cybercriminels, améliorations CVSS) afin d'augmenter la proposition de valeur de la base de données consultative en tant que solution premium. Voici un aperçu des fonctionnalités à venir :

Les équipes sécurité passent un temps significatif à trier les résultats de détection des secrets qui s'avèrent être des identifiants de test ou des valeurs factices. La détection de faux positifs alimentée par l'IA analyse les résultats avant que les équipes de développement ne les voient afin de repérer les identifiants de test, les valeurs d'exemple et les secrets de substitution avec des explications claires et des scores de confiance, pour améliorer de manière significative le nombre d'éléments signalés à traiter. Voici ce sur quoi nous travaillons :

Quand le même modèle de vulnérabilité apparaît dans le code source, créer des merge requests individuelles pour chaque instance ralentit la révision et la remédiation. GitLab Duo regroupe de façon intelligente les résultats SAST par causes profondes partagées et génère des merge requests uniques qui traitent les vulnérabilités afin de transformer les corrections dispersées en remédiation coordonnée. Nous prévoyons d'inclure :

Les mises à jour automatisées des dépendances échouent souvent dans les pipelines CI/CD à cause de changements cassants et nécessitent une intervention manuelle qui retarde la remédiation de sécurité. Quand les merge requests de mise à jour des dépendances échouent, l'IA analyse les erreurs de pipeline et les changelogs de dépendances pour générer automatiquement des corrections de code qui résolvent les problèmes de compatibilité afin de réduire de manière significative l'effort manuel requis pour traiter les vulnérabilités. Voici ce que nous construisons :