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
É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.
Services professionnels - Accélérer grâce à l'expertise
L'équipe des services de stratégie de programme (PSS) de Secure Code Warriorvous aide à construire, améliorer et optimiser votre programme de codage sécurisé. Que vous partiez de zéro ou que vous affiniez votre approche, nos experts vous fournissent des conseils sur mesure.
Thèmes et contenu de la formation sur le code sécurisé
Notre contenu, à la pointe de l'industrie, évolue constamment pour s'adapter au paysage du développement logiciel en constante évolution, tout en gardant votre rôle à l'esprit. Les sujets abordés vont de l'IA à l'injection XQuery, et sont proposés pour une variété de rôles, des architectes et ingénieurs aux gestionnaires de produits et à l'assurance qualité. Découvrez en avant-première ce que notre catalogue de contenu a à offrir par sujet et par rôle.
Quêtes : Apprentissage de pointe pour permettre aux développeurs de garder une longueur d'avance et d'atténuer les risques.
Quests est une learning platform qui aide les développeurs à atténuer les risques liés à la sécurité des logiciels en améliorant leurs compétences en matière de codage sécurisé. Grâce à des parcours d'apprentissage, des défis pratiques et des activités interactives, elle permet aux développeurs d'identifier et de prévenir les vulnérabilités.
Ressources pour vous aider à démarrer
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.
La décennie des défenseurs : Secure Code Warrior Dixième anniversaire
Secure Code WarriorL'équipe fondatrice de SCW est restée soudée, dirigeant le navire à travers chaque leçon, chaque triomphe et chaque revers pendant une décennie entière. Nous nous développons et sommes prêts à affronter notre prochain chapitre, SCW 2.0, en tant que leaders de la gestion des risques pour les développeurs.
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.
