Les codeurs conquièrent la sécurité : Share & Learn Series - Utiliser des composants dont les vulnérabilités sont connues
Quel est l'élément commun à toutes les applications ? Des composants, également connus sous le nom de dépendances ou de bibliothèques. Il existe très peu de code dans le monde qui ne dépende pas d'un autre code à un moment ou à un autre. Vous commencez même avec une montagne de dépendances dès la création de l'application !
Étant donné que toutes les applications utilisent des composants, dont la plupart n'ont pas été écrits par vous, les vulnérabilités des composants que vous utilisez peuvent devenir des responsabilités. Voyons ce que signifie l'utilisation de composants présentant des vulnérabilités connues, en quoi elle est dangereuse et comment y remédier.
Comprendre l'utilisation de composants dont les vulnérabilités sont connues
Tous les logiciels complexes présentent des vulnérabilités. C'est la nature même de la bête. Vos composants ne seront donc jamais sûrs à 100 %. Cependant, lorsque des vulnérabilités sont découvertes dans des composants, le savez-vous ? Êtes-vous prêt à y faire face ?
Les problèmes surviennent le plus souvent lorsque les composants sont utilisés au-delà de leur durée de vie utile ou lorsque des vulnérabilités sont découvertes. La plupart des composants et des bibliothèques publient des correctifs pour les failles de sécurité au plus tard au moment où la faille est annoncée. Par conséquent, lorsque des vulnérabilités dans les composants sont découvertes et annoncées, il est extrêmement important de les mettre à jour dès que possible. Ne laissez pas de logiciels vulnérables en production.
Les composants peuvent provenir de plusieurs sources. Parfois, vous achetez des produits de fournisseurs tiers qui s'intègrent directement à votre code personnalisé. Ces composants deviennent une partie de votre code et fonctionnent au même niveau de privilège. Les projets open source hébergés sur des sites tels que GitHub constituent une autre source. L'open source peut être dangereux car toutes les bibliothèques open source n'ont pas fait l'objet d'un examen minutieux ou d'un audit pour détecter les vulnérabilités.
Les attaquants utilisent les informations sur les vulnérabilités des composants à leur avantage. Comme les vulnérabilités sont annoncées publiquement, les attaquants les connaissent en même temps que vous. Les attaquants disposent également de techniques leur permettant de découvrir les composants que vous utilisez. Une fois qu'ils connaissent ces informations, ils savent comment attaquer votre application si elle n'est pas corrigée.
Sachez pourquoi les composants vulnérables sont dangereux
Si vous cherchez une preuve du danger que représente l'utilisation de composants dont les vulnérabilités sont connues, ne cherchez pas plus loin que la violation d'Equifax en 2017.
En juillet 2017, Equifax, un bureau de crédit américain, a découvert une violation massive de données qui a divulgué les informations personnelles identifiables de plus de 147 millions de personnes. L'ampleur et l'impact de cette violation de données sont sans précédent. Récemment, des informations ont été publiées sur les pratiques de sécurité laxistes d'Equifax.
L'une de ces pratiques laxistes était la gestion des correctifs. Equifax n'avait pas de bonnes pratiques de gestion des correctifs, ce qui signifiait que ses composants pouvaient rester longtemps sans être corrigés. C'est la cause directe de la violation.
Le site web d'Equifax utilisait le framework web Apache Struts. Plusieurs mois avant que les attaquants ne s'introduisent dans le réseau, une vulnérabilité a été découverte dans le framework Struts, Apache Struts CVE-2017-5638. Cependant, Equifax n'a pas corrigé la vulnérabilité. Les attaquants ont utilisé cette vulnérabilité pour accéder au réseau d'Equifax. De là, ils ont eu accès à un trésor d'informations personnelles.
De nombreux sites web sont basés sur des cadres web qui n'ont pas été conçus par l'entreprise. Il s'agit d'une pratique courante, car la mise en place de toutes les fonctionnalités nécessaires à partir de zéro serait une entreprise trop importante. Cependant, le fait de dépendre fortement d'un cadre peut vous exposer à des vulnérabilités. Ne devenez pas le prochain Equifax.
Comment se protéger contre les composants vulnérables
Il n'existe pas de solution miracle pour se protéger contre l'utilisation de composants vulnérables. Cependant, il existe des politiques et des contrôles que vous pouvez utiliser pour atténuer le risque que des composants vulnérables soient utilisés pour compromettre vos systèmes.
Vous devez savoir quels composants et quelle version de chaque composant vous utilisez pour construire vos applications. Les outils de gestion des dépendances tels que Dependency Check de l'OWASP vous permettent de savoir quelles dépendances vous utilisez. Dependency Check vous indiquera également si l'un de ces composants présente une vulnérabilité divulguée publiquement.
Une méthodologie de gestion des correctifs est également essentielle. Lorsque des vulnérabilités sont découvertes, mettez en place un système pour que les correctifs soient téléchargés, testés et mis en production sans heurts. En veillant à ce que vos logiciels soient toujours corrigés, vous éviterez que des vulnérabilités vieilles de plusieurs mois ne soient utilisées par des pirates.
Enfin, mettez en place des politiques régissant l'utilisation des logiciels libres et des composants tiers. Les développeurs n'aiment pas la paperasserie, et c'est compréhensible. Cependant, il doit y avoir un processus d'approbation pour le code qui n'a pas été écrit par votre organisation. Ce processus n'a pas besoin d'être lourd, mais il est indispensable pour empêcher l'utilisation de composants inconnus. Au minimum, un inventaire des composants utilisés doit être tenu à jour.
Ne vous laissez pas piéger par le virus des tiers
Les composants présentent des vulnérabilités. Vos applications commerciales utiliseront des composants, qu'ils proviennent d'un fournisseur ou d'une bibliothèque open source. Cela ne signifie pas que votre organisation doit être vulnérable aux attaques.
Même si les attaquants connaissent les vulnérabilités en même temps que vous, les correctifs sont généralement disponibles en même temps que les annonces publiques. Veillez donc à vous informer sur ce que votre application utilise. Sachez ce qui est vulnérable. Veillez à ce que vos composants soient protégés par des correctifs !
Prêt à découvrir (et à vaincre) des éléments vulnérables ? Rendez-vous dans l'arène pour engager le combat : [Commencer ici]


Étant donné que toutes les applications utilisent des composants, dont la plupart n'ont pas été écrits par vous, les vulnérabilités des composants que vous utilisez peuvent devenir des responsabilités. Voyons ce que signifie l'utilisation de composants présentant des vulnérabilités connues, en quoi elle est dangereuse et comment y remédier.
Jaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.

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émonstrationJaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.


Quel est l'élément commun à toutes les applications ? Des composants, également connus sous le nom de dépendances ou de bibliothèques. Il existe très peu de code dans le monde qui ne dépende pas d'un autre code à un moment ou à un autre. Vous commencez même avec une montagne de dépendances dès la création de l'application !
Étant donné que toutes les applications utilisent des composants, dont la plupart n'ont pas été écrits par vous, les vulnérabilités des composants que vous utilisez peuvent devenir des responsabilités. Voyons ce que signifie l'utilisation de composants présentant des vulnérabilités connues, en quoi elle est dangereuse et comment y remédier.
Comprendre l'utilisation de composants dont les vulnérabilités sont connues
Tous les logiciels complexes présentent des vulnérabilités. C'est la nature même de la bête. Vos composants ne seront donc jamais sûrs à 100 %. Cependant, lorsque des vulnérabilités sont découvertes dans des composants, le savez-vous ? Êtes-vous prêt à y faire face ?
Les problèmes surviennent le plus souvent lorsque les composants sont utilisés au-delà de leur durée de vie utile ou lorsque des vulnérabilités sont découvertes. La plupart des composants et des bibliothèques publient des correctifs pour les failles de sécurité au plus tard au moment où la faille est annoncée. Par conséquent, lorsque des vulnérabilités dans les composants sont découvertes et annoncées, il est extrêmement important de les mettre à jour dès que possible. Ne laissez pas de logiciels vulnérables en production.
Les composants peuvent provenir de plusieurs sources. Parfois, vous achetez des produits de fournisseurs tiers qui s'intègrent directement à votre code personnalisé. Ces composants deviennent une partie de votre code et fonctionnent au même niveau de privilège. Les projets open source hébergés sur des sites tels que GitHub constituent une autre source. L'open source peut être dangereux car toutes les bibliothèques open source n'ont pas fait l'objet d'un examen minutieux ou d'un audit pour détecter les vulnérabilités.
Les attaquants utilisent les informations sur les vulnérabilités des composants à leur avantage. Comme les vulnérabilités sont annoncées publiquement, les attaquants les connaissent en même temps que vous. Les attaquants disposent également de techniques leur permettant de découvrir les composants que vous utilisez. Une fois qu'ils connaissent ces informations, ils savent comment attaquer votre application si elle n'est pas corrigée.
Sachez pourquoi les composants vulnérables sont dangereux
Si vous cherchez une preuve du danger que représente l'utilisation de composants dont les vulnérabilités sont connues, ne cherchez pas plus loin que la violation d'Equifax en 2017.
En juillet 2017, Equifax, un bureau de crédit américain, a découvert une violation massive de données qui a divulgué les informations personnelles identifiables de plus de 147 millions de personnes. L'ampleur et l'impact de cette violation de données sont sans précédent. Récemment, des informations ont été publiées sur les pratiques de sécurité laxistes d'Equifax.
L'une de ces pratiques laxistes était la gestion des correctifs. Equifax n'avait pas de bonnes pratiques de gestion des correctifs, ce qui signifiait que ses composants pouvaient rester longtemps sans être corrigés. C'est la cause directe de la violation.
Le site web d'Equifax utilisait le framework web Apache Struts. Plusieurs mois avant que les attaquants ne s'introduisent dans le réseau, une vulnérabilité a été découverte dans le framework Struts, Apache Struts CVE-2017-5638. Cependant, Equifax n'a pas corrigé la vulnérabilité. Les attaquants ont utilisé cette vulnérabilité pour accéder au réseau d'Equifax. De là, ils ont eu accès à un trésor d'informations personnelles.
De nombreux sites web sont basés sur des cadres web qui n'ont pas été conçus par l'entreprise. Il s'agit d'une pratique courante, car la mise en place de toutes les fonctionnalités nécessaires à partir de zéro serait une entreprise trop importante. Cependant, le fait de dépendre fortement d'un cadre peut vous exposer à des vulnérabilités. Ne devenez pas le prochain Equifax.
Comment se protéger contre les composants vulnérables
Il n'existe pas de solution miracle pour se protéger contre l'utilisation de composants vulnérables. Cependant, il existe des politiques et des contrôles que vous pouvez utiliser pour atténuer le risque que des composants vulnérables soient utilisés pour compromettre vos systèmes.
Vous devez savoir quels composants et quelle version de chaque composant vous utilisez pour construire vos applications. Les outils de gestion des dépendances tels que Dependency Check de l'OWASP vous permettent de savoir quelles dépendances vous utilisez. Dependency Check vous indiquera également si l'un de ces composants présente une vulnérabilité divulguée publiquement.
Une méthodologie de gestion des correctifs est également essentielle. Lorsque des vulnérabilités sont découvertes, mettez en place un système pour que les correctifs soient téléchargés, testés et mis en production sans heurts. En veillant à ce que vos logiciels soient toujours corrigés, vous éviterez que des vulnérabilités vieilles de plusieurs mois ne soient utilisées par des pirates.
Enfin, mettez en place des politiques régissant l'utilisation des logiciels libres et des composants tiers. Les développeurs n'aiment pas la paperasserie, et c'est compréhensible. Cependant, il doit y avoir un processus d'approbation pour le code qui n'a pas été écrit par votre organisation. Ce processus n'a pas besoin d'être lourd, mais il est indispensable pour empêcher l'utilisation de composants inconnus. Au minimum, un inventaire des composants utilisés doit être tenu à jour.
Ne vous laissez pas piéger par le virus des tiers
Les composants présentent des vulnérabilités. Vos applications commerciales utiliseront des composants, qu'ils proviennent d'un fournisseur ou d'une bibliothèque open source. Cela ne signifie pas que votre organisation doit être vulnérable aux attaques.
Même si les attaquants connaissent les vulnérabilités en même temps que vous, les correctifs sont généralement disponibles en même temps que les annonces publiques. Veillez donc à vous informer sur ce que votre application utilise. Sachez ce qui est vulnérable. Veillez à ce que vos composants soient protégés par des correctifs !
Prêt à découvrir (et à vaincre) des éléments vulnérables ? Rendez-vous dans l'arène pour engager le combat : [Commencer ici]

Quel est l'élément commun à toutes les applications ? Des composants, également connus sous le nom de dépendances ou de bibliothèques. Il existe très peu de code dans le monde qui ne dépende pas d'un autre code à un moment ou à un autre. Vous commencez même avec une montagne de dépendances dès la création de l'application !
Étant donné que toutes les applications utilisent des composants, dont la plupart n'ont pas été écrits par vous, les vulnérabilités des composants que vous utilisez peuvent devenir des responsabilités. Voyons ce que signifie l'utilisation de composants présentant des vulnérabilités connues, en quoi elle est dangereuse et comment y remédier.
Comprendre l'utilisation de composants dont les vulnérabilités sont connues
Tous les logiciels complexes présentent des vulnérabilités. C'est la nature même de la bête. Vos composants ne seront donc jamais sûrs à 100 %. Cependant, lorsque des vulnérabilités sont découvertes dans des composants, le savez-vous ? Êtes-vous prêt à y faire face ?
Les problèmes surviennent le plus souvent lorsque les composants sont utilisés au-delà de leur durée de vie utile ou lorsque des vulnérabilités sont découvertes. La plupart des composants et des bibliothèques publient des correctifs pour les failles de sécurité au plus tard au moment où la faille est annoncée. Par conséquent, lorsque des vulnérabilités dans les composants sont découvertes et annoncées, il est extrêmement important de les mettre à jour dès que possible. Ne laissez pas de logiciels vulnérables en production.
Les composants peuvent provenir de plusieurs sources. Parfois, vous achetez des produits de fournisseurs tiers qui s'intègrent directement à votre code personnalisé. Ces composants deviennent une partie de votre code et fonctionnent au même niveau de privilège. Les projets open source hébergés sur des sites tels que GitHub constituent une autre source. L'open source peut être dangereux car toutes les bibliothèques open source n'ont pas fait l'objet d'un examen minutieux ou d'un audit pour détecter les vulnérabilités.
Les attaquants utilisent les informations sur les vulnérabilités des composants à leur avantage. Comme les vulnérabilités sont annoncées publiquement, les attaquants les connaissent en même temps que vous. Les attaquants disposent également de techniques leur permettant de découvrir les composants que vous utilisez. Une fois qu'ils connaissent ces informations, ils savent comment attaquer votre application si elle n'est pas corrigée.
Sachez pourquoi les composants vulnérables sont dangereux
Si vous cherchez une preuve du danger que représente l'utilisation de composants dont les vulnérabilités sont connues, ne cherchez pas plus loin que la violation d'Equifax en 2017.
En juillet 2017, Equifax, un bureau de crédit américain, a découvert une violation massive de données qui a divulgué les informations personnelles identifiables de plus de 147 millions de personnes. L'ampleur et l'impact de cette violation de données sont sans précédent. Récemment, des informations ont été publiées sur les pratiques de sécurité laxistes d'Equifax.
L'une de ces pratiques laxistes était la gestion des correctifs. Equifax n'avait pas de bonnes pratiques de gestion des correctifs, ce qui signifiait que ses composants pouvaient rester longtemps sans être corrigés. C'est la cause directe de la violation.
Le site web d'Equifax utilisait le framework web Apache Struts. Plusieurs mois avant que les attaquants ne s'introduisent dans le réseau, une vulnérabilité a été découverte dans le framework Struts, Apache Struts CVE-2017-5638. Cependant, Equifax n'a pas corrigé la vulnérabilité. Les attaquants ont utilisé cette vulnérabilité pour accéder au réseau d'Equifax. De là, ils ont eu accès à un trésor d'informations personnelles.
De nombreux sites web sont basés sur des cadres web qui n'ont pas été conçus par l'entreprise. Il s'agit d'une pratique courante, car la mise en place de toutes les fonctionnalités nécessaires à partir de zéro serait une entreprise trop importante. Cependant, le fait de dépendre fortement d'un cadre peut vous exposer à des vulnérabilités. Ne devenez pas le prochain Equifax.
Comment se protéger contre les composants vulnérables
Il n'existe pas de solution miracle pour se protéger contre l'utilisation de composants vulnérables. Cependant, il existe des politiques et des contrôles que vous pouvez utiliser pour atténuer le risque que des composants vulnérables soient utilisés pour compromettre vos systèmes.
Vous devez savoir quels composants et quelle version de chaque composant vous utilisez pour construire vos applications. Les outils de gestion des dépendances tels que Dependency Check de l'OWASP vous permettent de savoir quelles dépendances vous utilisez. Dependency Check vous indiquera également si l'un de ces composants présente une vulnérabilité divulguée publiquement.
Une méthodologie de gestion des correctifs est également essentielle. Lorsque des vulnérabilités sont découvertes, mettez en place un système pour que les correctifs soient téléchargés, testés et mis en production sans heurts. En veillant à ce que vos logiciels soient toujours corrigés, vous éviterez que des vulnérabilités vieilles de plusieurs mois ne soient utilisées par des pirates.
Enfin, mettez en place des politiques régissant l'utilisation des logiciels libres et des composants tiers. Les développeurs n'aiment pas la paperasserie, et c'est compréhensible. Cependant, il doit y avoir un processus d'approbation pour le code qui n'a pas été écrit par votre organisation. Ce processus n'a pas besoin d'être lourd, mais il est indispensable pour empêcher l'utilisation de composants inconnus. Au minimum, un inventaire des composants utilisés doit être tenu à jour.
Ne vous laissez pas piéger par le virus des tiers
Les composants présentent des vulnérabilités. Vos applications commerciales utiliseront des composants, qu'ils proviennent d'un fournisseur ou d'une bibliothèque open source. Cela ne signifie pas que votre organisation doit être vulnérable aux attaques.
Même si les attaquants connaissent les vulnérabilités en même temps que vous, les correctifs sont généralement disponibles en même temps que les annonces publiques. Veillez donc à vous informer sur ce que votre application utilise. Sachez ce qui est vulnérable. Veillez à ce que vos composants soient protégés par des correctifs !
Prêt à découvrir (et à vaincre) des éléments vulnérables ? Rendez-vous dans l'arène pour engager le combat : [Commencer ici]

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émonstrationJaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.
Quel est l'élément commun à toutes les applications ? Des composants, également connus sous le nom de dépendances ou de bibliothèques. Il existe très peu de code dans le monde qui ne dépende pas d'un autre code à un moment ou à un autre. Vous commencez même avec une montagne de dépendances dès la création de l'application !
Étant donné que toutes les applications utilisent des composants, dont la plupart n'ont pas été écrits par vous, les vulnérabilités des composants que vous utilisez peuvent devenir des responsabilités. Voyons ce que signifie l'utilisation de composants présentant des vulnérabilités connues, en quoi elle est dangereuse et comment y remédier.
Comprendre l'utilisation de composants dont les vulnérabilités sont connues
Tous les logiciels complexes présentent des vulnérabilités. C'est la nature même de la bête. Vos composants ne seront donc jamais sûrs à 100 %. Cependant, lorsque des vulnérabilités sont découvertes dans des composants, le savez-vous ? Êtes-vous prêt à y faire face ?
Les problèmes surviennent le plus souvent lorsque les composants sont utilisés au-delà de leur durée de vie utile ou lorsque des vulnérabilités sont découvertes. La plupart des composants et des bibliothèques publient des correctifs pour les failles de sécurité au plus tard au moment où la faille est annoncée. Par conséquent, lorsque des vulnérabilités dans les composants sont découvertes et annoncées, il est extrêmement important de les mettre à jour dès que possible. Ne laissez pas de logiciels vulnérables en production.
Les composants peuvent provenir de plusieurs sources. Parfois, vous achetez des produits de fournisseurs tiers qui s'intègrent directement à votre code personnalisé. Ces composants deviennent une partie de votre code et fonctionnent au même niveau de privilège. Les projets open source hébergés sur des sites tels que GitHub constituent une autre source. L'open source peut être dangereux car toutes les bibliothèques open source n'ont pas fait l'objet d'un examen minutieux ou d'un audit pour détecter les vulnérabilités.
Les attaquants utilisent les informations sur les vulnérabilités des composants à leur avantage. Comme les vulnérabilités sont annoncées publiquement, les attaquants les connaissent en même temps que vous. Les attaquants disposent également de techniques leur permettant de découvrir les composants que vous utilisez. Une fois qu'ils connaissent ces informations, ils savent comment attaquer votre application si elle n'est pas corrigée.
Sachez pourquoi les composants vulnérables sont dangereux
Si vous cherchez une preuve du danger que représente l'utilisation de composants dont les vulnérabilités sont connues, ne cherchez pas plus loin que la violation d'Equifax en 2017.
En juillet 2017, Equifax, un bureau de crédit américain, a découvert une violation massive de données qui a divulgué les informations personnelles identifiables de plus de 147 millions de personnes. L'ampleur et l'impact de cette violation de données sont sans précédent. Récemment, des informations ont été publiées sur les pratiques de sécurité laxistes d'Equifax.
L'une de ces pratiques laxistes était la gestion des correctifs. Equifax n'avait pas de bonnes pratiques de gestion des correctifs, ce qui signifiait que ses composants pouvaient rester longtemps sans être corrigés. C'est la cause directe de la violation.
Le site web d'Equifax utilisait le framework web Apache Struts. Plusieurs mois avant que les attaquants ne s'introduisent dans le réseau, une vulnérabilité a été découverte dans le framework Struts, Apache Struts CVE-2017-5638. Cependant, Equifax n'a pas corrigé la vulnérabilité. Les attaquants ont utilisé cette vulnérabilité pour accéder au réseau d'Equifax. De là, ils ont eu accès à un trésor d'informations personnelles.
De nombreux sites web sont basés sur des cadres web qui n'ont pas été conçus par l'entreprise. Il s'agit d'une pratique courante, car la mise en place de toutes les fonctionnalités nécessaires à partir de zéro serait une entreprise trop importante. Cependant, le fait de dépendre fortement d'un cadre peut vous exposer à des vulnérabilités. Ne devenez pas le prochain Equifax.
Comment se protéger contre les composants vulnérables
Il n'existe pas de solution miracle pour se protéger contre l'utilisation de composants vulnérables. Cependant, il existe des politiques et des contrôles que vous pouvez utiliser pour atténuer le risque que des composants vulnérables soient utilisés pour compromettre vos systèmes.
Vous devez savoir quels composants et quelle version de chaque composant vous utilisez pour construire vos applications. Les outils de gestion des dépendances tels que Dependency Check de l'OWASP vous permettent de savoir quelles dépendances vous utilisez. Dependency Check vous indiquera également si l'un de ces composants présente une vulnérabilité divulguée publiquement.
Une méthodologie de gestion des correctifs est également essentielle. Lorsque des vulnérabilités sont découvertes, mettez en place un système pour que les correctifs soient téléchargés, testés et mis en production sans heurts. En veillant à ce que vos logiciels soient toujours corrigés, vous éviterez que des vulnérabilités vieilles de plusieurs mois ne soient utilisées par des pirates.
Enfin, mettez en place des politiques régissant l'utilisation des logiciels libres et des composants tiers. Les développeurs n'aiment pas la paperasserie, et c'est compréhensible. Cependant, il doit y avoir un processus d'approbation pour le code qui n'a pas été écrit par votre organisation. Ce processus n'a pas besoin d'être lourd, mais il est indispensable pour empêcher l'utilisation de composants inconnus. Au minimum, un inventaire des composants utilisés doit être tenu à jour.
Ne vous laissez pas piéger par le virus des tiers
Les composants présentent des vulnérabilités. Vos applications commerciales utiliseront des composants, qu'ils proviennent d'un fournisseur ou d'une bibliothèque open source. Cela ne signifie pas que votre organisation doit être vulnérable aux attaques.
Même si les attaquants connaissent les vulnérabilités en même temps que vous, les correctifs sont généralement disponibles en même temps que les annonces publiques. Veillez donc à vous informer sur ce que votre application utilise. Sachez ce qui est vulnérable. Veillez à ce que vos composants soient protégés par des correctifs !
Prêt à découvrir (et à vaincre) des éléments vulnérables ? Rendez-vous dans l'arène pour engager le combat : [Commencer ici]
Table des matières
Jaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.

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
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.
La puissance d'OpenText Fortify + Secure Code Warrior
OpenText Fortify et Secure Code Warrior unissent leurs forces pour aider les entreprises à réduire les risques, à transformer les développeurs en champions de la sécurité et à renforcer la confiance des clients. Pour en savoir plus, cliquez ici.
Ressources pour vous aider à démarrer
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.
10 prédictions clés : Secure Code Warrior sur l'influence de l'IA et de la conception sécurisée en 2025
Les organisations sont confrontées à des décisions difficiles sur l'utilisation de l'IA pour soutenir la productivité à long terme, la durabilité et le retour sur investissement de la sécurité. Au cours des dernières années, il nous est apparu clairement que l'IA ne remplacera jamais complètement le rôle du développeur. Des partenariats IA + développeurs aux pressions croissantes (et à la confusion) autour des attentes en matière de conception sécurisée, examinons de plus près ce à quoi nous pouvons nous attendre au cours de l'année prochaine.