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
Vibe Coding : Guide pratique pour la mise à jour de votre stratégie AppSec pour l'IA
Regardez à la demande pour apprendre comment permettre aux responsables AppSec de devenir des facilitateurs de l'IA, plutôt que des bloqueurs, grâce à une approche pratique, axée sur la formation. Nous vous montrerons comment tirer parti de Secure Code Warrior (SCW) pour actualiser votre stratégie AppSec à l'ère des assistants de codage IA.
AI Coding Assistants : Un guide de navigation sécurisée pour la prochaine génération de développeurs
Les grands modèles linguistiques offrent des avantages irrésistibles en termes de rapidité et de productivité, mais ils présentent également des risques indéniables pour l'entreprise. Les garde-fous traditionnels ne suffisent pas à contrôler le déluge. Les développeurs ont besoin de compétences précises et vérifiées en matière de sécurité pour identifier et prévenir les failles de sécurité dès le début du cycle de développement du logiciel.
Ressources pour vous aider à démarrer
Série vidéo sur la sécurité AI/LLM : Tous les épisodes, mis à jour chaque semaine
Votre guide tout-en-un pour notre série vidéo de 12 semaines sur la sécurité de l'IA/LLM. Regardez chaque épisode, apprenez les concepts clés de la sécurité de l'IA et suivez la série chaque semaine.
SCW lance une série de vidéos gratuites sur la sécurité de l'IA/LLM à l'intention des développeurs
Voici notre série de vidéos gratuites sur la sécurité de l'IA/LLM en 12 semaines ! Découvrez les risques fondamentaux du codage assisté par l'IA et comment créer des applications plus sûres.
10 000+ activités d'apprentissage du code sécurisé : Une décennie de gestion des risques pour les développeurs
Célébration de plus de 10 000 activités d'apprentissage du code sécurisé et d'une décennie d'habilitation des développeurs à réduire les risques, à améliorer la qualité du code et à aborder en toute confiance le développement assisté par l'IA.