Du signal au correctif testé : le parcours annoncé par Security Factory

En préversion privée, Security Factory relie l’analyse des vulnérabilités à leur correction. Les validations dépendent aussi des protections du dépôt.

Les éléments réunis pendant une enquête de sécurité doivent suivre le correctif jusqu’à sa vérification. C’est le lien que propose Security Factory, une offre qui applique les agents de programmation de Factory à l’analyse et à la correction des vulnérabilités. Le service est en préversion privée, accessible à un groupe restreint de clients.

Les alertes proviennent des outils déjà utilisés par l’organisation : analyse du code, dépendances, secrets ou infrastructure. Les connecteurs ajoutent le contexte des inventaires logiciels, des tickets et des échanges d’équipe. L’enquête doit établir quels systèmes sont exposés, comment une faille pourrait être exploitée et quels accès elle ouvrirait avant de préparer une correction. Conserver les preuves jusqu’au correctif

Une vulnérabilité signalée sur un composant prend un sens différent selon son déploiement et ses permissions. L’exemple du fournisseur associe un service accessible depuis Internet à un compte disposant de droits excessifs. Leur examen conjoint doit déterminer si une compromission du premier pourrait donner accès aux identifiants du second, puis à d’autres systèmes.

Les Workstreams répartissent les investigations entre tâches spécialisées et conservent les résultats, les preuves et les questions non résolues. Les hypothèses peuvent être testées dans des environnements contrôlés, sur les machines Droid Computers, dans un sandbox ou sur l’infrastructure cloud du client avec OpenCompute.

Les agents réutilisent ensuite ces informations pour modifier du code, mettre à jour une dépendance ou corriger une configuration. Le parcours annoncé prévoit de tester la modification dans les conditions ayant permis de reproduire la vulnérabilité, puis de rechercher des régressions avant de préparer un patch ou une pull request. Un agent par correction dans le parcours CVE

La documentation de remédiation des CVE décrit une mise en œuvre précise. Un agent interroge périodiquement le scanner et crée une tâche pour chaque correction. Un autre agent prend cette tâche en charge, depuis le triage jusqu’à la proposition de modification et au suivi des tests d’intégration continue.

Une tâche peut réunir plusieurs vulnérabilités résolues par le même changement. Le plan doit préciser la modification, les risques de rupture, sa méthode de validation et le retour arrière prévu. Après fusion, le statut attend une nouvelle lecture du scanner : la correction est confirmée lorsque le signalement n’apparaît plus.

Les sources documentées comprennent Snyk, les alertes Dependabot et d’analyse de code de GitHub, ainsi que les vulnérabilités de GitLab. Le parcours ne crée pas de tâche pour une dépendance dont le scanner n’indique aucune version corrigée. Le périmètre automatisé dépend donc aussi des informations et des possibilités de correction fournies en amont. Les validations reposent aussi sur les protections du dépôt

Le mode d’autonomie choisi modifie le passage par l’approbation du plan. Dans l’option la plus autonome décrite, une mise à jour corrective ou mineure d’une dépendance sans rupture peut avancer sans cette validation ; les autres plans restent soumis à l’utilisateur. Pour la fusion, les agents reçoivent la consigne d’attendre une décision humaine.

La documentation des tâches précise toutefois que Factory n’impose pas techniquement l’approbation des plans ou des fusions. Les revues obligatoires et les vérifications bloquantes doivent être configurées dans les protections de branche du dépôt.

À ces règles s’ajoutent les contrôles d’exécution des agents : permissions sur les commandes, restrictions réseau et isolation des accès aux fichiers. La documentation distingue ces contrôles des instructions adressées au modèle, qui les complètent sans constituer à elles seules une barrière technique.