Railway, PHP, CRA : quand l'IA transforme la veille de sécurité en décision

Une vulnérabilité critique vient d’être publiée. Être informé est une chose. Savoir si nos propres systèmes sont exposés en est une autre.

Cette semaine, deux alertes ont rappelé à quel point nos architectures dépendent de composants et de services que nous ne maîtrisons pas entièrement.

D’un côté, Railway annonçait une compromission de certains de ses systèmes internes, avec une exposition potentielle de secrets clients.

De l’autre, PHP publiait des correctifs pour des vulnérabilités critiques susceptibles de permettre l’exécution de code à distance.

Deux situations différentes, mais une question commune : quels sont les impacts possibles sur les systèmes dont nous avons la responsabilité ?

La sécurité commence bien avant l’alerte #

Depuis plus d’un an, j’ai choisi d’appliquer à mes projets une démarche qualité et d’analyse de risques inspirée du Cyber Resilience Act (CRA), même lorsqu’ils ne sont pas nécessairement soumis à ce règlement.

Architectures documentées, dépendances identifiées, analyses de risques, mesures de maîtrise et traçabilité des décisions font partie de ma manière de concevoir un système.

Ce travail représente un investissement.

Mais il permet de ne pas repartir de zéro lorsqu’un incident survient.

Quand la documentation devient opérationnelle #

J’ai progressivement intégré ces connaissances à des bases RAG et GraphRAG, accessibles à ELARA, mon assistante IA professionnelle.

ELARA surveille différents canaux de sécurité et rapproche les alertes des informations techniques et qualité de mes projets.

Elle peut ainsi identifier les projets potentiellement concernés, les technologies impliquées, les risques associés et les actions à envisager, selon trois niveaux de gravité.

Ces niveaux ne sont pas des appréciations arbitraires de l’IA : ils s’appuient sur les analyses et les critères que j’ai définis en amont.

L’IA effectue le rapprochement des informations. Le cadre d’évaluation vient de l’ingénierie.

Railway : l’intérêt d’avoir anticipé #

Je n’ai pas été directement touché par la compromission de Railway.

Mais lorsque l’alerte est apparue, j’ai pu vérifier très rapidement ma situation grâce à la connaissance déjà structurée de mes projets.

C’est précisément ce que je recherchais.

Ne pas découvrir son architecture au moment où il faut prendre une décision.

Et surtout, ne pas confondre l’absence d’alerte avec une preuve d’absence de risque.

L’IA amplifie une méthode, elle ne la remplace pas #

Un RAG ne garantit pas l’exactitude d’une analyse. Un GraphRAG ne garantit pas l’exhaustivité des dépendances.

La pertinence du résultat dépend notamment de la qualité, de l’actualité et de la traçabilité des informations disponibles.

L’IA peut accélérer les rapprochements, faire émerger des risques et préparer des actions.

Mais la décision reste liée à la réalité de l’architecture, aux conséquences possibles et au niveau d’incertitude acceptable.

Finalement, ce qui m’intéresse dans cette approche, ce n’est pas seulement d’automatiser la veille de sécurité.

C’est de rendre exploitable, au moment où elle devient nécessaire, toute la connaissance accumulée pendant la conception d’un système.

L’IA ne m’a pas permis d’improviser plus vite. Elle m’a permis d’exploiter plus vite ce que j’avais anticipé.

Et c’est peut-être là que se trouve une grande partie de sa valeur en ingénierie.