Nouveautés

Les entreprises souhaitent utiliser leurs propres abonnements aux modèles pour alimenter les fonctionnalités de GitLab Duo Agent Platform pour le contrôle des coûts, la résidence des données ou l'utilisation des contrats existants. La première itération Bring Your Own Key (BYOK) connecte les fournisseurs des clients par le biais d'une authentification basée sur un token via la passerelle d'IA (AI-Gateway) de GitLab. Nous travaillons à l'ajout des fonctionnalités suivantes :

Les équipes de sécurité consacrent beaucoup de temps à la hiérarchisation des résultats de détection de secrets qui se révèlent être des identifiants de test ou des valeurs factices. La détection des faux positifs alimentée par l'IA analyse les résultats avant que les équipes ne les voient et identifie les identifiants de test, les valeurs d'exemple et les secrets d'espace réservé avec des explications claires et des notes de confiance. Cette détection est distincte de la détection des faux positifs détectés par les tests statiques de sécurité des applications (SAST). Cette capacité est construite pour :

GitLab Duo Chat (Agentic) prendra en charge les téléchargements de fichiers et les contenus Web comme contexte de première classe, afin que les agents puissent utiliser la documentation, les logs, les spécifications et d'autres artefacts aux côtés des données du dépôt pour raisonner. Cette amélioration est destinée à :

Lorsque le même modèle de vulnérabilité apparaît dans un code source, la création de merge requests individuelles pour chaque instance ralentit les revues et la correction. En s'appuyant sur le flow de résolution SAST par vulnérabilité, cette extension regroupera intelligemment les résultats connexes par causes profondes partagées et générera des merge requests consolidées. Nous prévoyons d'inclure :

Aujourd'hui, GitLab ne suit les vulnérabilités que sur la branche par défaut, ce qui signifie que les organisations qui publient à partir de branches de longue durée n'ont aucune visibilité sur la posture de sécurité du code exécuté en production. Le suivi des branches autres que celles par défaut est une demande majeure pour obtenir des informations de sécurité et un obstacle documenté à l'adoption. Voici ce sur quoi nous travaillons :

Les attributs de sécurité du contexte commercial introduits précédemment doivent pouvoir être filtrés dans le tableau de bord de sécurité lui-même. Les responsables de sécurité pourront filtrer par impact commercial, application, unité commerciale, etc. dans les tableaux de bord. Nous prévoyons :

Les données d'entrée CI/CD existent aujourd'hui pour la configuration au niveau du pipeline, mais les équipes de développement ne peuvent toujours pas définir les paramètres des jobs manuels individuels dans les pipelines, ce qui force de nouvelles exécutions coûteuses du pipeline complet pour de simples modifications de paramètres. Les données d'entrée au niveau du job fourniront un paramétrage dynamique aux jobs manuels lorsque les paramètres changent pendant l'exécution. Cette capacité est construite pour :

L'extension du suivi des branches autres que celles par défaut dans le tableau de bord de sécurité et la nomenclature logicielle (SBOM) signifie que les tendances des vulnérabilités, les listes de dépendances et les exportations SBOM deviennent conscients des branches. Cette extension est destinée à :

La gravité CVSS seule n'indique pas si une vulnérabilité est activement exploitée ou susceptible de l'être. L'ajout d'une base de données des vulnérabilités exploitées connues (Known Exploited Vulnerabilities ou KEV) et d'un score EPSS (Exploit Prediction Scoring System) comme critères de filtrage dans les politiques d'approbation des merge requests déplace l'application de la gravité théorique à l'exploitabilité du monde réel. Ce filtre est créé pour :

Il s'agit de l'une des fonctionnalités les plus demandées de GitLab et un obstacle documenté pour les organisations en migration. Les épics sont actuellement au niveau du groupe uniquement, ce qui force les équipes à créer des sous-groupes inutiles ou à abuser des jalons. Les épics au niveau du projet sont construits pour :

GitLab souhaite appliquer des attributions automatisées CODEOWNERS pour résoudre les étapes manuelles pour chaque merge request et réduire les goulots d'étranglement pour les équipes de développement ainsi que le risque lié à la sélection des relecteurs. Cette fonctionnalité est créée pour :

De nombreuses équipes hésitent à adopter les fonctionnalités des éléments de travail (statuts personnalisés, champs personnalisés, types d'éléments de travail) qui ne sont disponibles que via GraphQL. L'API REST supprime le frein à cette adoption pour les intégrations, les scripts d'automatisation et les outils qui dépendent de REST. Cette API est créée pour :

Les discussions wiki se déroulent loin du contenu pertinent, ce qui réduit l'efficacité et augmente le changement de contexte. Les commentaires contextuels inline relieront les fils de discussions directement au texte en surbrillance et garderont les conversations connectées au contenu auquel elles font référence. Nous travaillons sur les éléments suivants :

Maven passe en disponibilité générale, tandis que npm est en version bêta, afin de couvrir les deux écosystèmes d'artefacts d'entreprise les plus volumineux. Le registre virtuel Docker cible également la disponibilité générale dans ce délai. D'ici le milieu de l'année, GitLab aura des registres virtuels en disponibilité générale pour Maven, Docker et npm. Ces registres sont créés pour :

Les métriques DORA (fréquence de déploiement, délai d'exécution des modifications, taux d'échec des modifications, délai de rétablissement du service) représentent la norme du secteur pour mesurer les performances de livraison de logiciels. La maturité complète de l'API signifie une parité complète des fonctionnalités pour la consommation programmatique. Ce jalon est destiné à inclure :

Les attributs de sécurité qui ont été introduits sur le tableau de bord de sécurité intégreront le rapport de vulnérabilité. Les équipes pourront filtrer les vulnérabilités par application, unité commerciale ou équipe directement dans le rapport. Elles pourront aussi ajouter des URL filtrées à leurs favoris et partager des vues filtrées. Ce filtre est développé pour :

Sur la base des vulnérabilités de gravité inférieure, la correction automatique prendra en charge les niveaux de gravité configurables et les cibles de version. Nous travaillons sur les éléments suivants :

SAST reste fondamental pour la sécurité des applications, mais les exigences de configuration CI/CD créent des obstacles à son adoption. Le profil de scan SAST permettra aux responsables de sécurité de déployer l'analyse statique sur les projets via l'inventaire de sécurité, avec détection automatique du langage et analyseur Advanced SAST pour les langages pris en charge sur GitLab Ultimate. Ce profil est conçu pour :

Les responsables de sécurité doivent pouvoir 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 modifications YAML ni intervention des développeurs. Ce profil est créé pour :

Bien que la protection contre le push de secrets bloque les commits en temps réel, le scan du pipeline fournit une couverture complémentaire en détectant les secrets dans l'historique du dépôt et les artefacts du pipeline. Ce profil permettra aux responsables de sécurité d'appliquer une détection large des secrets en utilisant la même approche basée sur les profils et de créer une défense en profondeur sans configuration complexe. Nous construisons ce profil pour :

Complétant la famille des profils de configuration de scan, le profil de scan des dépendances permettra aux équipes de sécurité d'appliquer l'analyse des dépendances sur les projets sans demander aux équipes de développement de modifier les configurations CI. Nous travaillons à la création de ce profil pour :

Les organisations avec des formats d'identifiants propriétaires ont besoin de pouvoir définir leurs propres modèles de secrets au-delà des règles intégrées de GitLab. Les règles personnalisées permettront aux équipes de sécurité d'ajouter des modèles spécifiques à l'organisation qui sont automatiquement appliqués lors de la détection des secrets. Cette capacité est conçue pour :

Les gravités de vulnérabilité par défaut ne reflètent pas toujours les priorités en matière de risque de l'organisation. Les équipes de sécurité pourront automatiser les remplacements de gravité en fonction de règles qui incluent une base KEV/un score EPSS, un Common Vulnerability Scoring System (CVSS), l'accessibilité, des vulnérabilités et expositions communes (CVE), des CWE et un type de scan, en vue de mapper le risque aux besoins commerciaux tout en automatisant les processus de hiérarchisation qui nécessitaient auparavant une intervention manuelle. Cette politique est destinée à :

Les équipes de sécurité ont actuellement besoin d'un accès Développeur ou Chargé de maintenance pour utiliser les fonctionnalités de gestion des vulnérabilités, des rôles avec beaucoup plus de permissions que nécessaire. Le rôle de Responsable de sécurité hérite du Rapporteur et possède des permissions spécifiques à la sécurité. Ce rôle est créé pour aider à :

Les informations de licence Dart et Flutter s'affichent actuellement avec le statut INCONNU, ce qui force les équipes à utiliser des outils externes pour la conformité des licences. La prise en charge de l'analyse des licences pour le gestionnaire de paquets pub comble cette lacune pour l'écosystème Flutter en pleine croissance. Nous travaillons sur les éléments suivants :

La détection des secrets basée sur les modèles manque les mots de passe génériques comme admin_password=Password123!, qui ne suivent pas un format reconnaissable. La détection consciente du contexte identifie les mots de passe génériques en analysant les modèles de code environnants et les conventions de dénomination des variables et étend la couverture actuelle de la détection des secrets. Nous travaillons actuellement sur les éléments suivants :

Les attaques de la chaîne d'approvisionnement par le biais de paquets malveillants posent un risque immédiat : contrairement aux CVE qui peuvent rester dormantes pendant des mois, un paquet malveillant cause des dommages dès qu'il est ingéré. GitLab explore la surface des paquets malveillants directement dans les résultats de l'analyse des dépendances pour aider les équipes à identifier et à répondre aux menaces actives. Nous explorons les éléments suivants :

L'analyseur Advanced SAST dans les grands dépôts peut dépasser les limites de temps des jobs du pipeline. L'analyse incrémentale mettra en cache les résultats des scans précédents et n'analysera que le code modifié, ce qui réduit considérablement le temps de scan tout en produisant des résultats précis. Il s'agit d'une initiative de performance distincte du travail de découpage rétroactif de l'analyseur Advanced SAST. Cette optimisation est destinée à :

Les tableaux de bord de sécurité ont besoin de formats exportables pour la communication avec les parties prenantes et la documentation de conformité. L'export PDF répliquera les panneaux du tableau de bord avec les filtres appliqués et les configurations de groupe pour le partage hors ligne et l'archivage. Cet export est créé pour :

Les organisations doivent prouver la provenance et l'intégrité de leurs artefacts dans la chaîne d'approvisionnement. Les API d'attestation, l'intégration de l'interface utilisateur et les commandes GitLab CLI (glab) pour la vérification valideront les artefacts, tandis que la signature et la vérification des images de conteneur étendent cette fonctionnalité à l'écosystème des conteneurs. Nous travaillons à :

Les portées PAT larges comme read_api et api créent un rayon d'impact excessif si les jetons sont compromis. Les permissions granulaires limiteront les jetons à des ressources et des opérations spécifiques, limitées à des projets et des groupes spécifiques. Nous travaillons sur les éléments suivants :

Les équipes qui utilisent des variables CI pour les secrets manquent de gestion appropriée du cycle de vie, de rappels de rotation et de contrôle d'accès granulaire. Le gestionnaire de secrets Gitlab fournira un stockage de secrets spécialisé avec gestion de l'expiration, portée de l'environnement/branche et permissions basées sur les rôles. Ce gestionnaire est étendu pour :

Les attributs de sécurité introduits pour l'attribution de tags et le filtrage seront appliqués au moteur de politique. Les équipes de sécurité pourront écrire des politiques qui référencent les attributs de sécurité personnalisés pour des règles de gouvernance granulaires. Voici ce sur quoi nous travaillons :

Les équipes de sécurité pourront appliquer les scans programmés (test dynamique de sécurité des applications (DAST) nocturne, analyse des dépendances hebdomadaire) via des politiques afin d'assurer la conformité continue sans action des équipes de développement. Cette politique est destinée à :