Plongée profonde : Trouver et corriger des vulnérabilités de haute sévérité dans libcurl/curl
Il y a peu, les communautés de la sécurité et du développement ont été averties par un avis du développeur principal du projet curl, Daniel Stenberg, qui a publié une malheureuse missive indiquant qu'une nouvelle version de curl - distribuée le 11 octobre - avait été publiée pour corriger deux vulnérabilités de sécurité à fort impact, dont l'une qu'il décrit comme "probablement la pire faille de sécurité de curl depuis longtemps".
Un postmortem sur le blog de Stenberg indique que les versions concernées de la bibliothèque curl sont susceptibles de présenter une vulnérabilité de débordement de mémoire tampon basée sur un tas, liée à un problème hérité du protocole proxy SOCKS5 utilisé depuis 2002.
Avec son utilisation en tant qu'outil de ligne de commande remontant à 1998, curl est largement considéré comme un pilier fondamental de l'internet. Avec une histoire aussi riche et une utilisation aussi répandue, il s'agit d'une dépendance qui, si elle s'avère vulnérable, pourrait avoir des conséquences permanentes sur la cybersécurité en général.
Cet incident présente des similitudes avec l'attaque dévastatrice Log4Shell dans Log4j, une autre dépendance vulnérable qui est toujours exploitée près de deux ans plus tard.
>>> Testez vos connaissances dès maintenant avec notre mission curl!
La vulnérabilité : Débordement de mémoire tampon
L'exploitation est détaillée sous CVE-2023-38545, et concerne les versions curl 7.69.0 à 8.3.0 incluse. Le bogue principal est une vulnérabilité de débordement de tampon basée sur le tas, les rapports initiaux notant qu'une exploitation réussie pourrait conduire à une attaque d'exécution de code à distance (RCE) plus dévastatrice. Bien qu'il s'agisse d'un flux de travail possible pour un acteur de la menace, il s'agit d'un cas d'utilisation rare plutôt que d'une évidence.
Le seul point positif permettant d'atténuer certains risques est que la communication malveillante doit passer par un proxy SOCKS5, ce qui est un déploiement relativement rare.
Comparable à l'exploit curl, jetons un coup d'œil à cette explication sur le débordement de tampon :
Lorsque l'on demande à curl d'utiliser un proxy SOCKS5, il transmet le nom d'hôte et le proxy le résout. Cependant, si le nom d'hôte dépasse la limite de 255 octets, curl résoudra le nom d'hôte localement (comme le montre l'extrait de code ci-dessous : source).
En cas de lenteur de l'échange entre le client et le mandataire, il est possible que le nom d'hôte long soit copié dans la mémoire tampon au lieu de l'adresse résolue (plus courte). La portion de mémoire allouée ne permet qu'une valeur de 255 octets, donc si elle reçoit une valeur qui dépasse cette limite, les données déborderont des limites de la mémoire tampon.
>>> Essayez-le par vous-même dans cette mission jouable!
Le débordement de mémoire tampon est un vecteur d'attaque puissant, qui peut être présent dans de nombreux langages de programmation anciens. Dans ce cas particulier, l'exploitation a ouvert la voie à une attaque plus sérieuse et plus dommageable sous la forme d'un RCE dans certains contextes, bien que cette voie reste peu courante et peu probable.
Comment pouvez-vous atténuer le risque de dépassement de tampon ?
À ce stade, la priorité absolue est d'appliquer les correctifs à toutes les instances vulnérables, en rappelant que l'utilisation de curl est tellement répandue qu'il n'est pas nécessairement évident ou annoncé que les composants de votre système incluent la dépendance en cours d'utilisation. Dans ce cas, un audit et des correctifs ultérieurs sont nécessaires.
En général, les failles de débordement de mémoire peuvent être atténuées par l'utilisation d'un langage à mémoire sécurisée comme Rust. Cependant, comme c'est le cas avec un projet tentaculaire comme curl, il n'est pas pratique de le porter à un autre langage ou de le réécrire sur un coup de tête. Comme le note Stenberg en évoquant la possibilité d'utiliser et de prendre en charge davantage de dépendances écrites dans des langages à mémoire sécurisée - ou l'alternative consistant à remplacer progressivement certaines parties de curl - "... le développement se fait... actuellement à une vitesse presque glaciale et montre avec une clarté douloureuse les défis à relever. curl restera écrit en C dans un avenir prévisible". Ce n'est pas une mince affaire, et les implications en matière de sécurité sont immenses.
Des erreurs de sécurité peuvent se produire et se produiront, et il n'est pas toujours possible de compter sur les scanners et les tests pour détecter tous les vecteurs d'attaque possibles. C'est pourquoi notre meilleure arme dans la lutte contre ces bogues est un engagement à une sensibilisation permanente à la sécurité et au renforcement des compétences.
Vous souhaitez en savoir plus sur la manière d'écrire du code sécurisé et de réduire les risques ?
Essayez notre Heap Overflow gratuitement.
Si vous souhaitez obtenir plus de conseils gratuits en matière de codage, consultez les sites suivants Secure Code Coach pour vous aider à rester au fait des meilleures pratiques en matière de codage sécurisé.
.avif)
Les versions affectées de la bibliothèque curl sont susceptibles de présenter une vulnérabilité de type débordement de mémoire tampon basée sur un tas, liée à un problème hérité du protocole proxy SOCKS5. Apprenez à trouver et à corriger ce type de vulnérabilité à l'aide d'une mission jouable.
Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Réservez une démonstration
Laura Verheyde est développeuse de logiciels à l'adresse Secure Code Warrior . Elle se consacre à la recherche de vulnérabilités et à la création de contenu pour Missions et Coding labs.
Il y a peu, les communautés de la sécurité et du développement ont été averties par un avis du développeur principal du projet curl, Daniel Stenberg, qui a publié une malheureuse missive indiquant qu'une nouvelle version de curl - distribuée le 11 octobre - avait été publiée pour corriger deux vulnérabilités de sécurité à fort impact, dont l'une qu'il décrit comme "probablement la pire faille de sécurité de curl depuis longtemps".
Un postmortem sur le blog de Stenberg indique que les versions concernées de la bibliothèque curl sont susceptibles de présenter une vulnérabilité de débordement de mémoire tampon basée sur un tas, liée à un problème hérité du protocole proxy SOCKS5 utilisé depuis 2002.
Avec son utilisation en tant qu'outil de ligne de commande remontant à 1998, curl est largement considéré comme un pilier fondamental de l'internet. Avec une histoire aussi riche et une utilisation aussi répandue, il s'agit d'une dépendance qui, si elle s'avère vulnérable, pourrait avoir des conséquences permanentes sur la cybersécurité en général.
Cet incident présente des similitudes avec l'attaque dévastatrice Log4Shell dans Log4j, une autre dépendance vulnérable qui est toujours exploitée près de deux ans plus tard.
>>> Testez vos connaissances dès maintenant avec notre mission curl!
La vulnérabilité : Débordement de mémoire tampon
L'exploitation est détaillée sous CVE-2023-38545, et concerne les versions curl 7.69.0 à 8.3.0 incluse. Le bogue principal est une vulnérabilité de débordement de tampon basée sur le tas, les rapports initiaux notant qu'une exploitation réussie pourrait conduire à une attaque d'exécution de code à distance (RCE) plus dévastatrice. Bien qu'il s'agisse d'un flux de travail possible pour un acteur de la menace, il s'agit d'un cas d'utilisation rare plutôt que d'une évidence.
Le seul point positif permettant d'atténuer certains risques est que la communication malveillante doit passer par un proxy SOCKS5, ce qui est un déploiement relativement rare.
Comparable à l'exploit curl, jetons un coup d'œil à cette explication sur le débordement de tampon :
Lorsque l'on demande à curl d'utiliser un proxy SOCKS5, il transmet le nom d'hôte et le proxy le résout. Cependant, si le nom d'hôte dépasse la limite de 255 octets, curl résoudra le nom d'hôte localement (comme le montre l'extrait de code ci-dessous : source).
En cas de lenteur de l'échange entre le client et le mandataire, il est possible que le nom d'hôte long soit copié dans la mémoire tampon au lieu de l'adresse résolue (plus courte). La portion de mémoire allouée ne permet qu'une valeur de 255 octets, donc si elle reçoit une valeur qui dépasse cette limite, les données déborderont des limites de la mémoire tampon.
>>> Essayez-le par vous-même dans cette mission jouable!
Le débordement de mémoire tampon est un vecteur d'attaque puissant, qui peut être présent dans de nombreux langages de programmation anciens. Dans ce cas particulier, l'exploitation a ouvert la voie à une attaque plus sérieuse et plus dommageable sous la forme d'un RCE dans certains contextes, bien que cette voie reste peu courante et peu probable.
Comment pouvez-vous atténuer le risque de dépassement de tampon ?
À ce stade, la priorité absolue est d'appliquer les correctifs à toutes les instances vulnérables, en rappelant que l'utilisation de curl est tellement répandue qu'il n'est pas nécessairement évident ou annoncé que les composants de votre système incluent la dépendance en cours d'utilisation. Dans ce cas, un audit et des correctifs ultérieurs sont nécessaires.
En général, les failles de débordement de mémoire peuvent être atténuées par l'utilisation d'un langage à mémoire sécurisée comme Rust. Cependant, comme c'est le cas avec un projet tentaculaire comme curl, il n'est pas pratique de le porter à un autre langage ou de le réécrire sur un coup de tête. Comme le note Stenberg en évoquant la possibilité d'utiliser et de prendre en charge davantage de dépendances écrites dans des langages à mémoire sécurisée - ou l'alternative consistant à remplacer progressivement certaines parties de curl - "... le développement se fait... actuellement à une vitesse presque glaciale et montre avec une clarté douloureuse les défis à relever. curl restera écrit en C dans un avenir prévisible". Ce n'est pas une mince affaire, et les implications en matière de sécurité sont immenses.
Des erreurs de sécurité peuvent se produire et se produiront, et il n'est pas toujours possible de compter sur les scanners et les tests pour détecter tous les vecteurs d'attaque possibles. C'est pourquoi notre meilleure arme dans la lutte contre ces bogues est un engagement à une sensibilisation permanente à la sécurité et au renforcement des compétences.
Vous souhaitez en savoir plus sur la manière d'écrire du code sécurisé et de réduire les risques ?
Essayez notre Heap Overflow gratuitement.
Si vous souhaitez obtenir plus de conseils gratuits en matière de codage, consultez les sites suivants Secure Code Coach pour vous aider à rester au fait des meilleures pratiques en matière de codage sécurisé.
Il y a peu, les communautés de la sécurité et du développement ont été averties par un avis du développeur principal du projet curl, Daniel Stenberg, qui a publié une malheureuse missive indiquant qu'une nouvelle version de curl - distribuée le 11 octobre - avait été publiée pour corriger deux vulnérabilités de sécurité à fort impact, dont l'une qu'il décrit comme "probablement la pire faille de sécurité de curl depuis longtemps".
Un postmortem sur le blog de Stenberg indique que les versions concernées de la bibliothèque curl sont susceptibles de présenter une vulnérabilité de débordement de mémoire tampon basée sur un tas, liée à un problème hérité du protocole proxy SOCKS5 utilisé depuis 2002.
Avec son utilisation en tant qu'outil de ligne de commande remontant à 1998, curl est largement considéré comme un pilier fondamental de l'internet. Avec une histoire aussi riche et une utilisation aussi répandue, il s'agit d'une dépendance qui, si elle s'avère vulnérable, pourrait avoir des conséquences permanentes sur la cybersécurité en général.
Cet incident présente des similitudes avec l'attaque dévastatrice Log4Shell dans Log4j, une autre dépendance vulnérable qui est toujours exploitée près de deux ans plus tard.
>>> Testez vos connaissances dès maintenant avec notre mission curl!
La vulnérabilité : Débordement de mémoire tampon
L'exploitation est détaillée sous CVE-2023-38545, et concerne les versions curl 7.69.0 à 8.3.0 incluse. Le bogue principal est une vulnérabilité de débordement de tampon basée sur le tas, les rapports initiaux notant qu'une exploitation réussie pourrait conduire à une attaque d'exécution de code à distance (RCE) plus dévastatrice. Bien qu'il s'agisse d'un flux de travail possible pour un acteur de la menace, il s'agit d'un cas d'utilisation rare plutôt que d'une évidence.
Le seul point positif permettant d'atténuer certains risques est que la communication malveillante doit passer par un proxy SOCKS5, ce qui est un déploiement relativement rare.
Comparable à l'exploit curl, jetons un coup d'œil à cette explication sur le débordement de tampon :
Lorsque l'on demande à curl d'utiliser un proxy SOCKS5, il transmet le nom d'hôte et le proxy le résout. Cependant, si le nom d'hôte dépasse la limite de 255 octets, curl résoudra le nom d'hôte localement (comme le montre l'extrait de code ci-dessous : source).
En cas de lenteur de l'échange entre le client et le mandataire, il est possible que le nom d'hôte long soit copié dans la mémoire tampon au lieu de l'adresse résolue (plus courte). La portion de mémoire allouée ne permet qu'une valeur de 255 octets, donc si elle reçoit une valeur qui dépasse cette limite, les données déborderont des limites de la mémoire tampon.
>>> Essayez-le par vous-même dans cette mission jouable!
Le débordement de mémoire tampon est un vecteur d'attaque puissant, qui peut être présent dans de nombreux langages de programmation anciens. Dans ce cas particulier, l'exploitation a ouvert la voie à une attaque plus sérieuse et plus dommageable sous la forme d'un RCE dans certains contextes, bien que cette voie reste peu courante et peu probable.
Comment pouvez-vous atténuer le risque de dépassement de tampon ?
À ce stade, la priorité absolue est d'appliquer les correctifs à toutes les instances vulnérables, en rappelant que l'utilisation de curl est tellement répandue qu'il n'est pas nécessairement évident ou annoncé que les composants de votre système incluent la dépendance en cours d'utilisation. Dans ce cas, un audit et des correctifs ultérieurs sont nécessaires.
En général, les failles de débordement de mémoire peuvent être atténuées par l'utilisation d'un langage à mémoire sécurisée comme Rust. Cependant, comme c'est le cas avec un projet tentaculaire comme curl, il n'est pas pratique de le porter à un autre langage ou de le réécrire sur un coup de tête. Comme le note Stenberg en évoquant la possibilité d'utiliser et de prendre en charge davantage de dépendances écrites dans des langages à mémoire sécurisée - ou l'alternative consistant à remplacer progressivement certaines parties de curl - "... le développement se fait... actuellement à une vitesse presque glaciale et montre avec une clarté douloureuse les défis à relever. curl restera écrit en C dans un avenir prévisible". Ce n'est pas une mince affaire, et les implications en matière de sécurité sont immenses.
Des erreurs de sécurité peuvent se produire et se produiront, et il n'est pas toujours possible de compter sur les scanners et les tests pour détecter tous les vecteurs d'attaque possibles. C'est pourquoi notre meilleure arme dans la lutte contre ces bogues est un engagement à une sensibilisation permanente à la sécurité et au renforcement des compétences.
Vous souhaitez en savoir plus sur la manière d'écrire du code sécurisé et de réduire les risques ?
Essayez notre Heap Overflow gratuitement.
Si vous souhaitez obtenir plus de conseils gratuits en matière de codage, consultez les sites suivants Secure Code Coach pour vous aider à rester au fait des meilleures pratiques en matière de codage sécurisé.
Cliquez sur le lien ci-dessous et téléchargez le PDF de cette ressource.
Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Voir le rapportRéservez une démonstration
Laura Verheyde est développeuse de logiciels à l'adresse Secure Code Warrior . Elle se consacre à la recherche de vulnérabilités et à la création de contenu pour Missions et Coding labs.
Il y a peu, les communautés de la sécurité et du développement ont été averties par un avis du développeur principal du projet curl, Daniel Stenberg, qui a publié une malheureuse missive indiquant qu'une nouvelle version de curl - distribuée le 11 octobre - avait été publiée pour corriger deux vulnérabilités de sécurité à fort impact, dont l'une qu'il décrit comme "probablement la pire faille de sécurité de curl depuis longtemps".
Un postmortem sur le blog de Stenberg indique que les versions concernées de la bibliothèque curl sont susceptibles de présenter une vulnérabilité de débordement de mémoire tampon basée sur un tas, liée à un problème hérité du protocole proxy SOCKS5 utilisé depuis 2002.
Avec son utilisation en tant qu'outil de ligne de commande remontant à 1998, curl est largement considéré comme un pilier fondamental de l'internet. Avec une histoire aussi riche et une utilisation aussi répandue, il s'agit d'une dépendance qui, si elle s'avère vulnérable, pourrait avoir des conséquences permanentes sur la cybersécurité en général.
Cet incident présente des similitudes avec l'attaque dévastatrice Log4Shell dans Log4j, une autre dépendance vulnérable qui est toujours exploitée près de deux ans plus tard.
>>> Testez vos connaissances dès maintenant avec notre mission curl!
La vulnérabilité : Débordement de mémoire tampon
L'exploitation est détaillée sous CVE-2023-38545, et concerne les versions curl 7.69.0 à 8.3.0 incluse. Le bogue principal est une vulnérabilité de débordement de tampon basée sur le tas, les rapports initiaux notant qu'une exploitation réussie pourrait conduire à une attaque d'exécution de code à distance (RCE) plus dévastatrice. Bien qu'il s'agisse d'un flux de travail possible pour un acteur de la menace, il s'agit d'un cas d'utilisation rare plutôt que d'une évidence.
Le seul point positif permettant d'atténuer certains risques est que la communication malveillante doit passer par un proxy SOCKS5, ce qui est un déploiement relativement rare.
Comparable à l'exploit curl, jetons un coup d'œil à cette explication sur le débordement de tampon :
Lorsque l'on demande à curl d'utiliser un proxy SOCKS5, il transmet le nom d'hôte et le proxy le résout. Cependant, si le nom d'hôte dépasse la limite de 255 octets, curl résoudra le nom d'hôte localement (comme le montre l'extrait de code ci-dessous : source).
En cas de lenteur de l'échange entre le client et le mandataire, il est possible que le nom d'hôte long soit copié dans la mémoire tampon au lieu de l'adresse résolue (plus courte). La portion de mémoire allouée ne permet qu'une valeur de 255 octets, donc si elle reçoit une valeur qui dépasse cette limite, les données déborderont des limites de la mémoire tampon.
>>> Essayez-le par vous-même dans cette mission jouable!
Le débordement de mémoire tampon est un vecteur d'attaque puissant, qui peut être présent dans de nombreux langages de programmation anciens. Dans ce cas particulier, l'exploitation a ouvert la voie à une attaque plus sérieuse et plus dommageable sous la forme d'un RCE dans certains contextes, bien que cette voie reste peu courante et peu probable.
Comment pouvez-vous atténuer le risque de dépassement de tampon ?
À ce stade, la priorité absolue est d'appliquer les correctifs à toutes les instances vulnérables, en rappelant que l'utilisation de curl est tellement répandue qu'il n'est pas nécessairement évident ou annoncé que les composants de votre système incluent la dépendance en cours d'utilisation. Dans ce cas, un audit et des correctifs ultérieurs sont nécessaires.
En général, les failles de débordement de mémoire peuvent être atténuées par l'utilisation d'un langage à mémoire sécurisée comme Rust. Cependant, comme c'est le cas avec un projet tentaculaire comme curl, il n'est pas pratique de le porter à un autre langage ou de le réécrire sur un coup de tête. Comme le note Stenberg en évoquant la possibilité d'utiliser et de prendre en charge davantage de dépendances écrites dans des langages à mémoire sécurisée - ou l'alternative consistant à remplacer progressivement certaines parties de curl - "... le développement se fait... actuellement à une vitesse presque glaciale et montre avec une clarté douloureuse les défis à relever. curl restera écrit en C dans un avenir prévisible". Ce n'est pas une mince affaire, et les implications en matière de sécurité sont immenses.
Des erreurs de sécurité peuvent se produire et se produiront, et il n'est pas toujours possible de compter sur les scanners et les tests pour détecter tous les vecteurs d'attaque possibles. C'est pourquoi notre meilleure arme dans la lutte contre ces bogues est un engagement à une sensibilisation permanente à la sécurité et au renforcement des compétences.
Vous souhaitez en savoir plus sur la manière d'écrire du code sécurisé et de réduire les risques ?
Essayez notre Heap Overflow gratuitement.
Si vous souhaitez obtenir plus de conseils gratuits en matière de codage, consultez les sites suivants Secure Code Coach pour vous aider à rester au fait des meilleures pratiques en matière de codage sécurisé.
Table des matières
Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Réservez une démonstrationTéléchargerRessources pour vous aider à démarrer
Sécurité dès la conception : Définir les meilleures pratiques, permettre aux développeurs et évaluer les résultats de la sécurité préventive
Dans ce document de recherche, les cofondateurs de Secure Code Warrior , Pieter Danhieux et Matias Madou, Ph.D., ainsi que des contributeurs experts, Chris Inglis, ancien directeur national américain de la cybernétique (aujourd'hui conseiller stratégique du Paladin Capital Group), et Devin Lynch, directeur principal du Paladin Global Institute, révèleront les principales conclusions de plus de vingt entretiens approfondis avec des responsables de la sécurité des entreprises, y compris des RSSI, un vice-président de la sécurité des applications et des professionnels de la sécurité des logiciels.
Évaluation comparative des compétences en matière de sécurité : Rationalisation de la conception sécurisée dans l'entreprise
Il est notoirement difficile de trouver des données significatives sur le succès des initiatives Secure-by-Design. Les RSSI sont souvent confrontés à des difficultés lorsqu'ils tentent de prouver le retour sur investissement (ROI) et la valeur commerciale des activités du programme de sécurité, tant au niveau des personnes que de l'entreprise. De plus, il est particulièrement difficile pour les entreprises d'obtenir des informations sur la façon dont leurs organisations sont comparées aux normes actuelles du secteur. La stratégie nationale de cybersécurité du président a mis les parties prenantes au défi d'"adopter la sécurité et la résilience dès la conception". Pour que les initiatives de conception sécurisée fonctionnent, il faut non seulement donner aux développeurs les compétences nécessaires pour assurer la sécurité du code, mais aussi garantir aux régulateurs que ces compétences sont en place. Dans cette présentation, nous partageons une myriade de données qualitatives et quantitatives, dérivées de sources primaires multiples, y compris des points de données internes collectés auprès de plus de 250 000 développeurs, des informations sur les clients basées sur des données, et des études publiques. En nous appuyant sur cette agrégation de points de données, nous visons à communiquer une vision de l'état actuel des initiatives Secure-by-Design dans de multiples secteurs verticaux. Le rapport explique en détail pourquoi cet espace est actuellement sous-utilisé, l'impact significatif qu'un programme de perfectionnement réussi peut avoir sur l'atténuation des risques de cybersécurité, et le potentiel d'élimination des catégories de vulnérabilités d'une base de code.
Ressources pour vous aider à démarrer
Définir la norme : SCW publie des règles de sécurité gratuites pour le codage de l'IA sur GitHub
Le développement assisté par IA n'est plus un horizon : il est bel et bien là, et il transforme rapidement la manière dont les logiciels sont écrits. Des outils comme GitHub Copilot, Cline, Roo, Cursor, Aider et Windsurf transforment les développeurs en copilotes, permettant des itérations plus rapides et accélérant tout, du prototypage aux projets de refactorisation majeurs.
Bouclez la boucle des vulnérabilités avec Secure Code Warrior + HackerOne
Secure Code Warrior est heureux d'annoncer sa nouvelle intégration avec HackerOne, un leader dans les solutions de sécurité offensive. Ensemble, nous construisons un écosystème puissant et intégré. HackerOne met le doigt sur les vulnérabilités dans les environnements réels, en exposant le "quoi" et le "où" des problèmes de sécurité.
Révélation : Comment l'industrie du cyberespace définit la notion de "Secure by Design" (sécurité dès la conception)
Dans notre dernier livre blanc, nos cofondateurs, Pieter Danhieux et Matias Madou, Ph.D., ont rencontré plus de vingt responsables de la sécurité d'entreprise, notamment des RSSI, des responsables AppSec et des professionnels de la sécurité, afin d'identifier les principales pièces de ce puzzle et de découvrir la réalité qui se cache derrière le mouvement Secure by Design. Il s'agit d'une ambition partagée par les équipes de sécurité, mais il n'y a pas de manuel de jeu commun.
Vibe Coding va-t-il transformer votre base de code en une fête de fraternité ?
Le codage vibratoire est comme une fête de fraternité universitaire, et l'IA est la pièce maîtresse de toutes les festivités, le tonneau. C'est très amusant de se laisser aller, d'être créatif et de voir où votre imagination peut vous mener, mais après quelques barils, boire (ou utiliser l'IA) avec modération est sans aucun doute la solution la plus sûre à long terme.
Codage axé sur le développeur.
En toute sécurité.
Contactez-nous dès aujourd'hui et faites de la sécurité des logiciels une partie intrinsèque de votre processus de développement.
