Le seul outil d’intelligence artificielle dont AppSec a besoin. Évidemment

Les logiciels gèrent silencieusement les systèmes dont nous dépendons : nos banques, notre logistique, nos communications et nos voitures. Mais pour de nombreuses équipes AppSec, ce logiciel est un enchevêtrement d’alertes déconnectées et de vulnérabilités majeures.

Le mouvement de virage à gauche n’était pas censé ajouter du bruit ; Il était censé intégrer la sécurité à notre façon de construire. Aujourd’hui, avec des responsabilités croissantes et une complexité qui s’accélère, cette promesse doit devenir réalité.

Bonjour les cyber-constructeurs 🖖

Quand nous avons commencé à travailler sur ce qui est devenu Glev.ainous ne recherchions pas le battage médiatique. Nous recherchions un problème avec lequel toutes les équipes AppSec à qui nous avons parlé se débattaient discrètement.

La sécurité des applications n’est pas en reste faute d’outils. Il est interrompu parce que le travail est enterré, déconnecté et arrive constamment trop tard.

Cet article marque le début d'une série dans laquelle je partagerai ce que nous avons appris, ce que nous avons construit et pourquoi cela est plus important que jamais.

Si vous souhaitez plus d'informations, n'hésitez pas à me contacter. Commençons par le « pourquoi ».

Le logiciel ne consiste pas seulement à exécuter votre application. est en cours d'exécution le monde– votre voiture, votre banque, votre hôpital, vos élections. Chaque industrie est désormais une industrie du logiciel, qu’elle l’admette ou non.

J'ai récemment parlé avec un cadre d'une grande entreprise de publicité. Ma tendance (dont j'ai honte) était que si vous faites de la publicité, vous devriez avoir des tonnes d'artistes créatifs, de directeurs créatifs, participer à des séances de brainstorming et faire des choses fantaisistes. Imaginez un film hollywoodien qui montre ces créatifs… Mais le dirigeant a été clair : ils comptent 20 000 développeurs de logiciels. Parce que dans la publicité, tout est désormais piloté par logiciel, l'analyse des données, l'apprentissage automatique et l'intelligence artificielle étant les moteurs des activités publicitaires.

Combien de soi-disant « sociétés de logiciels » comptent 20 000 développeurs de logiciels ?

Malheureusement, chaque entreprise comporte le même risque caché : un code non sécurisé intégré à ses fondations. La partie effrayante ? La majeure partie n’a jamais été construite dans un souci de sécurité.

Je n'aime pas générer la peur, mais Les PDG doivent comprendre que s’ils continuent à considérer la sécurité après coup, ils ne seront pas seulement laissés pour compte ; Ils font partie de la prochaine infraction qui est sur le point de se produire.

Ils auront :

• Fuite de données confidentielles de l'entreprise

• Site Internet, site e-commerce, application mobile : Indisponible pendant les horaires d'ouverture

• Fuite d’informations personnellement identifiables (PII)

Tous ces impacts créent d’énormes responsabilités à l’encontre des régulateurs, des clients et des actionnaires.

Et la situation empire à mesure que les vulnérabilités connues augmentent. plus rapide que la capacité de n'importe quelle équipe à les corriger.

Cette image ci-dessus est la réalité. Presque 40 000 CVE n’ont été signalées qu’en 2024. Cela représente une multiplication par 6 par rapport à 2015. En 2025, on s’attend à ce qu’il y ait environ 50 000 vulnérabilités (+25 % par rapport à 2024).

Bref, il est temps d'agir.

La situation et son urgence sont connues depuis des années. Et, comme c'est souvent le cas en matière de cybersécurité, lorsque de nouvelles menaces et de nouveaux problèmes apparaissent, nous commençons généralement par des réglementations (du moins en Europe), des conférences sur les hackers et des initiatives du secteur public.

Il Loi européenne sur la cyber-résilience nécessite désormais la preuve que votre logiciel est conçu pour être sécurisé. J'en ai parlé il y a deux ans (déjà !)

Aux États-Unis, la situation est tout aussi grave. Voici ce que Jen Easterly (ancienne directrice de CISA) a dit lors de Black Hat 2024 :

“Nous entrons dans un régime de responsabilité logicielle.”

Jen Easterly (ancienne directrice de la CISA du gouvernement américain)

CISA a lancé un engagement de sécurité, dans le cadre duquel les entreprises s'engagent à soutenir des actions importantes et sont encouragées à rendre compte chaque année de leurs progrès. vois-le ici.

Nous n'avons pas besoin d'un autre outil – Appsec Teams

Et ils ont tout à fait raison. Les équipes AppSec n'ont pas besoin d'un autre outil.

Lorsque nous lançons une nouvelle entreprise chez CyGO Entrepreneurs, nous commençons toujours sur le terrain, avec des professionnels qui agissent et font des travaux de sécurité au quotidien. On demande un peu de leur temps et on écoute, on demande souvent, on ne pitche jamais.

Pour créer Glev, nous avons eu plus de 80 conversations et entendu cinq commentaires clés.

“Je me noie sous des listes de problèmes.”

Les clients potentiels d'AppSec sont obligés de jouer au contrôle du trafic aérien. Ils ont un arriéré de milliers de vulnérabilités dans Jira et les résultats du scanner sur les tableaux de bord. Certains fichiers PDF pentest, requis par certains clients comme « vérifications annuelles », se perdent dans les e-mails. Les rapports de récompenses se trouvent quelque part sur une plateforme SaaS.

En conséquence, ils négligent les vrais problèmes parce que rien n'est centralisé, dédupliqué ou priorisé.

J'ai besoin d'une source de vérité qui en fait, me laisse agir.

Ingénieur Appsec sur un site e-commerce.

Ils n’ont pas besoin d’autres aliments ou outils.

“Nous perdons des heures à trier les déchets.”

Si vous exécutez un outil SAST, SCA, Secret Leakage ou DAST, vous vous retrouverez avec de nombreuses alertes, dont la plupart sont classées « critiques » ou « très élevées ».

Cependant, le contexte compte : est-il exploitable dans notre configuration, étant donné notre chemins de données ?

Imaginez que vous vous retrouviez avec une alerte concernant une injection SQL. On ne sait souvent pas si le paramètre est lié à la saisie de l'utilisateur, ni si l'appel précédent impliquait des fonctions de nettoyage de l'équipe de développement. Sans ce contexte, les ingénieurs AppSec deviennent des agents du service d'assistance, perdant du temps avec des faux positifs et recherchant continuellement plus d'informations.

Lors de nos entretiens, nous avons discuté avec une équipe AppSec travaillant avec 200 ingénieurs logiciels qui avaient presque complètement abandonné.

Ils ont déclaré : “Nous signalons uniquement les problèmes critiques aux développeurs et publions un rappel après 3 semaines pour voir s'ils l'ont résolu ; les meilleures équipes d'ingénierie posent des questions et résolvent les problèmes, les pires voient leur retard continuer de croître.”

ce dont tu as besoin c'est Triage contextuel qui comprend votre environnement.il ne s'agit pas d'un rapport de conformité ou d'une liste de contrôle du scanner.

“Nous trouvons les problèmes plus rapidement que nous ne les résolvons.”

Découvrir les problèmes est la partie la plus facile.

La détection et la visibilité constituaient autrefois un problème lorsque la sécurité du code n'était pas aussi mature que la sécurité du réseau ou des points finaux. Cependant, au cours des 10 dernières années, nous avons constaté des améliorations significatives et pouvons désormais compter des centaines de solutions disponibles. De plus, les scanners open source arrivent à maturité et les grands fournisseurs proposent des outils open source matures (par ex. Google, etc.)

Une remédiation ? C’est là que se trouvent actuellement les goulots d’étranglement d’AppSec. Les développeurs sont critiqués. Les solutions ne sont pas claires. Les tickets restent intacts car personne n’a le temps d’enquêter.

Les équipes AppSec ont besoin des workflows de remédiation évolutifs– qui simplifient l'évidence et donnent un sens aux tâches de remédiation.

“On ne peut pas être partout en même temps.”

D'après nos entretiens, les équipes d'ingénierie sont 30 fois plus nombreuses que les équipes AppSec. Elles prennent en charge chaque équipe, chaque référentiel, chaque version, mais elles restent la seule équipe de sécurité.

Les équipes AppSec se retrouvent souvent à répondre à plusieurs reprises aux mêmes questions, à réexpliquer les meilleures pratiques et à intégrer des développeurs qui manquent même des connaissances les plus élémentaires.

Cette situation n’est pas due à la paresse ; cela reflète plutôt un sentiment de dépassement et de surcharge de travail.

Les équipes AppSec devraient en profiter les connaissances collectives de l'équipe, en créant une pratique et une culture AppSec dans toute l'organisation.

“La sécurité passe toujours en dernier.”

Les équipes AppSec tentent souvent de s'impliquer dès le début du processus de développement. Pourtant, l’équipe de sécurité arrive souvent en retard et seulement après une revue de conception, après un gel du code (vraiment ?), ou même après qu’une faille de sécurité se soit produite.

Chaque fois que cela se produit, un exercice d’incendie effréné est déclenché. Les équipes réagissent rapidement, tandis que les développeurs ont tendance à repousser les mesures de sécurité supplémentaires. En conséquence, les risques de sécurité sont parfois acceptés simplement parce qu'il n'y a pas deil n'y a pas de temps” il partit pour s'adresser à eux.

Ce que les équipes AppSec visent réellement, c'est un flux de travail dans lequel la sécurité est intégrée de manière transparente dans le cycle de vie du développement, devenant ainsi une partie naturelle et proactive du processus plutôt qu'un obstacle inséré après coup.

Ils n’exigent pas de solutions impossibles ; Son objectif est que la sécurité soit reconnue et traitée comme la discipline d'ingénierie essentielle qu'elle est : globale, proactive et collaborative dès le départ.

Ces cinq problèmes ne sont pas théoriques : ils sont une réalité quotidienne pour les équipes AppSec du monde entier. Si vous en avez ressenti ne serait-ce qu'un, vous n'êtes pas seul.

C'est pourquoi nous avons créé Glev.ai. Pas comme un autre outil, mais comme une nouvelle façon de penser la sécurité logicielle, basée sur l'empathie et le contexte du monde réel.et enfin donner l'avantage aux équipes AppSec ils méritent.

Dans le prochain article, j'expliquerai pourquoi l'IA à elle seule ne résoudra pas l'AppSec et quel changement de mentalité fait la différence.

D'ici là, j'aimerais avoir de vos nouvelles :

👉 Lequel de ces cinq défis est le plus proche de vous ?
👉 Qu'est-ce que votre équipe a essayé et qu'est-ce qui a fonctionné ?

Appuyez sur Répondre, laissez un commentaire ou partagez-le avec votre équipe AppSec. Bâtissons une sécurité qui se développe et se maintient.

Laurent 💚