Contexte et portée du nouveau programme d’essai

GitHub a relevé la barre d’éligibilité des essais auto‑service de GitHub Advanced Security (GHAS) : le plafond passe de 100 à 300 licences d’Enterprise Cloud. Toute organisation située sous ce seuil peut déclencher, depuis la page « Billing and licensing », un essai de 30 jours sans aucune interaction commerciale. L’offre inclut les deux modules séparés depuis l’année précédente – Code Security et Secret Protection – et s’applique à tous les dépôts de l’entreprise, sans limitation du nombre de contributeurs.

Fonctionnalités incluses et mécanisme d’analyse

Le volet Code Security exécute CodeQL, un moteur d’analyse statique qui parcourt l’arbre syntaxique du code pour identifier des motifs de vulnérabilité connus et des dépendances à risque. En parallèle, Secret Protection scrute chaque commit à la recherche de chaînes ressemblant à des clés d’API ou des mots de passe, et peut bloquer immédiatement la pull request lorsqu’une fuite est détectée, au lieu de générer un simple rapport post‑mortem. Ces deux processus fonctionnent en temps réel, s’appuyant sur des bases de données de signatures régulièrement mises à jour par GitHub.

Analyse des impacts pour les équipes moyennes

Le passage à 300 licences cible les équipes de taille moyenne, souvent dépassées par la secret sprawl et la complexité des graphes de dépendances. Le texte souligne que, avec l’essor du codage assisté par IA, le volume de commits peut dépasser la capacité de révision humaine. Ainsi, la métrique la plus pertinente devient la capacité de prévention à l’instant du commit plutôt le nombre d’issues recensées à la fin du mois. Les organisations qui utilisent l’essai pour tester le blocage en temps réel obtiennent une mesure plus fiable de la résilience de leur chaîne d’intégration continue.

Limites et contraintes du modèle d’essai

Le programme reste limité à un essai unique par organisation ; si aucune souscription n’est réalisée, la prochaine opportunité n’arrive qu’après un cool‑down de 180 jours. De plus, la mise en place initiale nécessite de configurer les deux modules sur l’ensemble des dépôts, ce qui consomme du temps pendant les premiers jours du mois d’essai. Les premiers scans génèrent inévitablement des faux positifs, imposant une phase de calibration pour éviter que les équipes ne soient submergées de tickets. Enfin, l’absence de contrat de vente ne supprime pas la nécessité d’une gouvernance interne : les décideurs doivent planifier le déploiement, mesurer les blocages effectifs et décider d’un achat avant la clôture du délai de 30 jours.