Coders Conquer Security: Share & Learn シリーズ-既知の脆弱性を持つコンポーネントの使用
すべてのアプリケーションにはどのようなものがありますか?コンポーネント。依存関係またはライブラリとも呼ばれます。ある時点で他のコードに依存しないコードは世界にほとんどありません。アプリケーションを作成したときから、依存関係の山のような状態から始めることさえあります。
すべてのアプリケーションはコンポーネントを使用しますが、そのほとんどはまだ作成していないため、使用するコンポーネント内の脆弱性が負債になる可能性があります。既知の脆弱性を持つコンポーネントを使用する意味、その危険性、解決方法について説明しましょう。
既知の脆弱性を持つコンポーネントの使用方法を理解する
複雑なソフトウェアにはすべて脆弱性があります。それが野獣の性質です。そのため、コンポーネントが 100% 安全になることは決してありません。しかし、コンポーネントに脆弱性が見つかった場合、それを知っていますか？そのための準備はできていますか？
問題が発生するのは、コンポーネントが耐用年数を過ぎて使用された場合や、脆弱性が発見されてから使用された場合です。ほとんどのコンポーネントとライブラリは、脆弱性が発表されるのと同時に、またはそれ以前にセキュリティ脆弱性に対するパッチをリリースします。そのため、コンポーネント内の脆弱性が発見され公表されたら、できるだけ早くコンポーネントを更新することが最も重要です。脆弱なソフトウェアを本番環境に置いたままにしないでください。
コンポーネントは複数のソースから取得できます。カスタムコードと直接統合されるサードパーティベンダーの製品を購入することもあります。これらのコンポーネントはコードの一部となり、同じレベルの権限で動作します。もう 1 つのソースは、GitHub などのサイトでホストされているオープンソースプロジェクトです。すべてのオープンソースライブラリが脆弱性について入念に精査または監査されているわけではないため、オープンソースは危険な場合があります。
攻撃者はコンポーネントの脆弱性情報を利用して利益を得ます。脆弱性は公開されるため、攻撃者はあなたと同じタイミングで脆弱性を知ることになります。攻撃者は、使用しているコンポーネントを突き止めるために使用できる手法も持っています。この情報を知れば、パッチが適用されていない場合にアプリケーションを攻撃する方法がわかります。
脆弱なコンポーネントが危険な理由を知る
既知の脆弱性を持つコンポーネントの使用がいかに危険であるかの証拠を探しているなら、2017年のEquifax違反以外に探す必要はありません。
2017 年 7 月には、 Equifax米国の信用調査機関は、1億4700万人以上の個人を特定できる情報が漏洩する大規模なデータ侵害を発見しました。このデータ漏えいの範囲と影響は前例のないものです。最近、次のようなニュースが出ています。 Equifaxの緩いセキュリティ慣行。
その緩い慣習の1つがパッチ管理でした。Equifaxには適切なパッチ管理手法がなかったため、コンポーネントにパッチが適用されないままかなりの時間が経過していました。 これが違反の直接の原因でした。
Equifaxのウェブサイトが使用していたのは Apache Struts ウェブフレームワーク。攻撃者がネットワークに侵入する数か月前に、Struts フレームワークである Apache Struts CVE-2017-5638 に脆弱性が発見されました。しかし、Equifax はこの脆弱性にパッチを適用しませんでした。攻撃者はこの脆弱性を利用して Equifax のネットワークにアクセスしました。そこから、彼らは個人情報の宝庫にアクセスしました。
多くの Web サイトは、会社が作成していない Web フレームワークをベースにしています。必要な機能をすべてゼロから構築するのは大変な作業なので、これは標準的な手法です。ただし、フレームワークに強く依存していると、脆弱性に陥る可能性があります。次のEquifaxにならないでください。
脆弱なコンポーネントから保護する方法
脆弱なコンポーネントの使用を防ぐための特効薬はありません。ただし、脆弱なコンポーネントがシステムの侵害に利用されるリスクを軽減するために使用できるポリシーや統制があります。
アプリケーションの構築に使用しているコンポーネントと各コンポーネントのバージョンを知っておく必要があります。次のような依存関係管理ツール OWASP の依存関係チェック 使用している依存関係を把握するのに役立ちます。また、Dependency Check は、これらのコンポーネントのいずれかに公開されている脆弱性があるかどうかも教えてくれます。
パッチ管理方法論も不可欠です。脆弱性が発見された場合、パッチのダウンロード、テスト、本番環境へのリリースが円滑に行えるようにシステムを整えてください。ソフトウェアにパッチを適用したままにしておくと、数か月前の脆弱性が攻撃者に利用されるのを防ぐことができます。
最後に、オープンソースとサードパーティのコンポーネントの使用を管理するポリシーを定めてください。開発者は官僚的形式主義を好まないが、それは理解できる。ただし、組織で作成されていないコードについては、審査プロセスが必要です。重いコードである必要はありませんが、未知のコンポーネントが使用されないようにするためには必須です。少なくとも、使用するコンポーネントのインベントリは最新の状態に保つ必要があります。
サードパーティのバグに悩まされないでください
コンポーネントには脆弱性があります。ビジネスアプリケーションは、ベンダーのものであれ、オープンソースライブラリのものであれ、コンポーネントを使用します。だからといって、組織が攻撃に対して脆弱である必要があるわけではありません。
攻撃者はどのような脆弱性が存在するかを知るのと同時に知っていても、通常、パッチは公開発表と同時に公開されます。そのため、アプリケーションに何が使用されているかを把握しておく必要があります。何が脆弱なのかを把握しておきましょう。コンポーネントには常にパッチを適用してください。
脆弱なコンポーネントを発見 (および撃破) する準備はできていますか?アリーナに向かい、戦闘に参加しよう: [ここから始める]
すべてのアプリケーションはコンポーネントを使用しますが、そのほとんどはまだ作成していないため、使用するコンポーネント内の脆弱性が負債になる可能性があります。既知の脆弱性を持つコンポーネントを使用する意味、その危険性、解決方法について説明しましょう。
Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。
Secure Code Warrior vous assiste dans la protection de votre code tout au long du cycle de vie du développement logiciel et dans la création d'une culture qui accorde la priorité à la cybersécurité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité des systèmes d'information ou professionnel de la sécurité, nous vous aidons à réduire les risques liés au code non sécurisé.
Veuillez réserver une démonstration.
Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。
すべてのアプリケーションにはどのようなものがありますか?コンポーネント。依存関係またはライブラリとも呼ばれます。ある時点で他のコードに依存しないコードは世界にほとんどありません。アプリケーションを作成したときから、依存関係の山のような状態から始めることさえあります。
すべてのアプリケーションはコンポーネントを使用しますが、そのほとんどはまだ作成していないため、使用するコンポーネント内の脆弱性が負債になる可能性があります。既知の脆弱性を持つコンポーネントを使用する意味、その危険性、解決方法について説明しましょう。
既知の脆弱性を持つコンポーネントの使用方法を理解する
複雑なソフトウェアにはすべて脆弱性があります。それが野獣の性質です。そのため、コンポーネントが 100% 安全になることは決してありません。しかし、コンポーネントに脆弱性が見つかった場合、それを知っていますか？そのための準備はできていますか？
問題が発生するのは、コンポーネントが耐用年数を過ぎて使用された場合や、脆弱性が発見されてから使用された場合です。ほとんどのコンポーネントとライブラリは、脆弱性が発表されるのと同時に、またはそれ以前にセキュリティ脆弱性に対するパッチをリリースします。そのため、コンポーネント内の脆弱性が発見され公表されたら、できるだけ早くコンポーネントを更新することが最も重要です。脆弱なソフトウェアを本番環境に置いたままにしないでください。
コンポーネントは複数のソースから取得できます。カスタムコードと直接統合されるサードパーティベンダーの製品を購入することもあります。これらのコンポーネントはコードの一部となり、同じレベルの権限で動作します。もう 1 つのソースは、GitHub などのサイトでホストされているオープンソースプロジェクトです。すべてのオープンソースライブラリが脆弱性について入念に精査または監査されているわけではないため、オープンソースは危険な場合があります。
攻撃者はコンポーネントの脆弱性情報を利用して利益を得ます。脆弱性は公開されるため、攻撃者はあなたと同じタイミングで脆弱性を知ることになります。攻撃者は、使用しているコンポーネントを突き止めるために使用できる手法も持っています。この情報を知れば、パッチが適用されていない場合にアプリケーションを攻撃する方法がわかります。
脆弱なコンポーネントが危険な理由を知る
既知の脆弱性を持つコンポーネントの使用がいかに危険であるかの証拠を探しているなら、2017年のEquifax違反以外に探す必要はありません。
2017 年 7 月には、 Equifax米国の信用調査機関は、1億4700万人以上の個人を特定できる情報が漏洩する大規模なデータ侵害を発見しました。このデータ漏えいの範囲と影響は前例のないものです。最近、次のようなニュースが出ています。 Equifaxの緩いセキュリティ慣行。
その緩い慣習の1つがパッチ管理でした。Equifaxには適切なパッチ管理手法がなかったため、コンポーネントにパッチが適用されないままかなりの時間が経過していました。 これが違反の直接の原因でした。
Equifaxのウェブサイトが使用していたのは Apache Struts ウェブフレームワーク。攻撃者がネットワークに侵入する数か月前に、Struts フレームワークである Apache Struts CVE-2017-5638 に脆弱性が発見されました。しかし、Equifax はこの脆弱性にパッチを適用しませんでした。攻撃者はこの脆弱性を利用して Equifax のネットワークにアクセスしました。そこから、彼らは個人情報の宝庫にアクセスしました。
多くの Web サイトは、会社が作成していない Web フレームワークをベースにしています。必要な機能をすべてゼロから構築するのは大変な作業なので、これは標準的な手法です。ただし、フレームワークに強く依存していると、脆弱性に陥る可能性があります。次のEquifaxにならないでください。
脆弱なコンポーネントから保護する方法
脆弱なコンポーネントの使用を防ぐための特効薬はありません。ただし、脆弱なコンポーネントがシステムの侵害に利用されるリスクを軽減するために使用できるポリシーや統制があります。
アプリケーションの構築に使用しているコンポーネントと各コンポーネントのバージョンを知っておく必要があります。次のような依存関係管理ツール OWASP の依存関係チェック 使用している依存関係を把握するのに役立ちます。また、Dependency Check は、これらのコンポーネントのいずれかに公開されている脆弱性があるかどうかも教えてくれます。
パッチ管理方法論も不可欠です。脆弱性が発見された場合、パッチのダウンロード、テスト、本番環境へのリリースが円滑に行えるようにシステムを整えてください。ソフトウェアにパッチを適用したままにしておくと、数か月前の脆弱性が攻撃者に利用されるのを防ぐことができます。
最後に、オープンソースとサードパーティのコンポーネントの使用を管理するポリシーを定めてください。開発者は官僚的形式主義を好まないが、それは理解できる。ただし、組織で作成されていないコードについては、審査プロセスが必要です。重いコードである必要はありませんが、未知のコンポーネントが使用されないようにするためには必須です。少なくとも、使用するコンポーネントのインベントリは最新の状態に保つ必要があります。
サードパーティのバグに悩まされないでください
コンポーネントには脆弱性があります。ビジネスアプリケーションは、ベンダーのものであれ、オープンソースライブラリのものであれ、コンポーネントを使用します。だからといって、組織が攻撃に対して脆弱である必要があるわけではありません。
攻撃者はどのような脆弱性が存在するかを知るのと同時に知っていても、通常、パッチは公開発表と同時に公開されます。そのため、アプリケーションに何が使用されているかを把握しておく必要があります。何が脆弱なのかを把握しておきましょう。コンポーネントには常にパッチを適用してください。
脆弱なコンポーネントを発見 (および撃破) する準備はできていますか?アリーナに向かい、戦闘に参加しよう: [ここから始める]
すべてのアプリケーションにはどのようなものがありますか?コンポーネント。依存関係またはライブラリとも呼ばれます。ある時点で他のコードに依存しないコードは世界にほとんどありません。アプリケーションを作成したときから、依存関係の山のような状態から始めることさえあります。
すべてのアプリケーションはコンポーネントを使用しますが、そのほとんどはまだ作成していないため、使用するコンポーネント内の脆弱性が負債になる可能性があります。既知の脆弱性を持つコンポーネントを使用する意味、その危険性、解決方法について説明しましょう。
既知の脆弱性を持つコンポーネントの使用方法を理解する
複雑なソフトウェアにはすべて脆弱性があります。それが野獣の性質です。そのため、コンポーネントが 100% 安全になることは決してありません。しかし、コンポーネントに脆弱性が見つかった場合、それを知っていますか？そのための準備はできていますか？
問題が発生するのは、コンポーネントが耐用年数を過ぎて使用された場合や、脆弱性が発見されてから使用された場合です。ほとんどのコンポーネントとライブラリは、脆弱性が発表されるのと同時に、またはそれ以前にセキュリティ脆弱性に対するパッチをリリースします。そのため、コンポーネント内の脆弱性が発見され公表されたら、できるだけ早くコンポーネントを更新することが最も重要です。脆弱なソフトウェアを本番環境に置いたままにしないでください。
コンポーネントは複数のソースから取得できます。カスタムコードと直接統合されるサードパーティベンダーの製品を購入することもあります。これらのコンポーネントはコードの一部となり、同じレベルの権限で動作します。もう 1 つのソースは、GitHub などのサイトでホストされているオープンソースプロジェクトです。すべてのオープンソースライブラリが脆弱性について入念に精査または監査されているわけではないため、オープンソースは危険な場合があります。
攻撃者はコンポーネントの脆弱性情報を利用して利益を得ます。脆弱性は公開されるため、攻撃者はあなたと同じタイミングで脆弱性を知ることになります。攻撃者は、使用しているコンポーネントを突き止めるために使用できる手法も持っています。この情報を知れば、パッチが適用されていない場合にアプリケーションを攻撃する方法がわかります。
脆弱なコンポーネントが危険な理由を知る
既知の脆弱性を持つコンポーネントの使用がいかに危険であるかの証拠を探しているなら、2017年のEquifax違反以外に探す必要はありません。
2017 年 7 月には、 Equifax米国の信用調査機関は、1億4700万人以上の個人を特定できる情報が漏洩する大規模なデータ侵害を発見しました。このデータ漏えいの範囲と影響は前例のないものです。最近、次のようなニュースが出ています。 Equifaxの緩いセキュリティ慣行。
その緩い慣習の1つがパッチ管理でした。Equifaxには適切なパッチ管理手法がなかったため、コンポーネントにパッチが適用されないままかなりの時間が経過していました。 これが違反の直接の原因でした。
Equifaxのウェブサイトが使用していたのは Apache Struts ウェブフレームワーク。攻撃者がネットワークに侵入する数か月前に、Struts フレームワークである Apache Struts CVE-2017-5638 に脆弱性が発見されました。しかし、Equifax はこの脆弱性にパッチを適用しませんでした。攻撃者はこの脆弱性を利用して Equifax のネットワークにアクセスしました。そこから、彼らは個人情報の宝庫にアクセスしました。
多くの Web サイトは、会社が作成していない Web フレームワークをベースにしています。必要な機能をすべてゼロから構築するのは大変な作業なので、これは標準的な手法です。ただし、フレームワークに強く依存していると、脆弱性に陥る可能性があります。次のEquifaxにならないでください。
脆弱なコンポーネントから保護する方法
脆弱なコンポーネントの使用を防ぐための特効薬はありません。ただし、脆弱なコンポーネントがシステムの侵害に利用されるリスクを軽減するために使用できるポリシーや統制があります。
アプリケーションの構築に使用しているコンポーネントと各コンポーネントのバージョンを知っておく必要があります。次のような依存関係管理ツール OWASP の依存関係チェック 使用している依存関係を把握するのに役立ちます。また、Dependency Check は、これらのコンポーネントのいずれかに公開されている脆弱性があるかどうかも教えてくれます。
パッチ管理方法論も不可欠です。脆弱性が発見された場合、パッチのダウンロード、テスト、本番環境へのリリースが円滑に行えるようにシステムを整えてください。ソフトウェアにパッチを適用したままにしておくと、数か月前の脆弱性が攻撃者に利用されるのを防ぐことができます。
最後に、オープンソースとサードパーティのコンポーネントの使用を管理するポリシーを定めてください。開発者は官僚的形式主義を好まないが、それは理解できる。ただし、組織で作成されていないコードについては、審査プロセスが必要です。重いコードである必要はありませんが、未知のコンポーネントが使用されないようにするためには必須です。少なくとも、使用するコンポーネントのインベントリは最新の状態に保つ必要があります。
サードパーティのバグに悩まされないでください
コンポーネントには脆弱性があります。ビジネスアプリケーションは、ベンダーのものであれ、オープンソースライブラリのものであれ、コンポーネントを使用します。だからといって、組織が攻撃に対して脆弱である必要があるわけではありません。
攻撃者はどのような脆弱性が存在するかを知るのと同時に知っていても、通常、パッチは公開発表と同時に公開されます。そのため、アプリケーションに何が使用されているかを把握しておく必要があります。何が脆弱なのかを把握しておきましょう。コンポーネントには常にパッチを適用してください。
脆弱なコンポーネントを発見 (および撃破) する準備はできていますか?アリーナに向かい、戦闘に参加しよう: [ここから始める]
Veuillez cliquer sur le lien ci-dessous pour télécharger le PDF de cette ressource.
Secure Code Warrior vous assiste dans la protection de votre code tout au long du cycle de vie du développement logiciel et dans la création d'une culture qui accorde la priorité à la cybersécurité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité des systèmes d'information ou professionnel de la sécurité, nous vous aidons à réduire les risques liés au code non sécurisé.
Afficher le rapportVeuillez réserver une démonstration.
Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。
すべてのアプリケーションにはどのようなものがありますか?コンポーネント。依存関係またはライブラリとも呼ばれます。ある時点で他のコードに依存しないコードは世界にほとんどありません。アプリケーションを作成したときから、依存関係の山のような状態から始めることさえあります。
すべてのアプリケーションはコンポーネントを使用しますが、そのほとんどはまだ作成していないため、使用するコンポーネント内の脆弱性が負債になる可能性があります。既知の脆弱性を持つコンポーネントを使用する意味、その危険性、解決方法について説明しましょう。
既知の脆弱性を持つコンポーネントの使用方法を理解する
複雑なソフトウェアにはすべて脆弱性があります。それが野獣の性質です。そのため、コンポーネントが 100% 安全になることは決してありません。しかし、コンポーネントに脆弱性が見つかった場合、それを知っていますか？そのための準備はできていますか？
問題が発生するのは、コンポーネントが耐用年数を過ぎて使用された場合や、脆弱性が発見されてから使用された場合です。ほとんどのコンポーネントとライブラリは、脆弱性が発表されるのと同時に、またはそれ以前にセキュリティ脆弱性に対するパッチをリリースします。そのため、コンポーネント内の脆弱性が発見され公表されたら、できるだけ早くコンポーネントを更新することが最も重要です。脆弱なソフトウェアを本番環境に置いたままにしないでください。
コンポーネントは複数のソースから取得できます。カスタムコードと直接統合されるサードパーティベンダーの製品を購入することもあります。これらのコンポーネントはコードの一部となり、同じレベルの権限で動作します。もう 1 つのソースは、GitHub などのサイトでホストされているオープンソースプロジェクトです。すべてのオープンソースライブラリが脆弱性について入念に精査または監査されているわけではないため、オープンソースは危険な場合があります。
攻撃者はコンポーネントの脆弱性情報を利用して利益を得ます。脆弱性は公開されるため、攻撃者はあなたと同じタイミングで脆弱性を知ることになります。攻撃者は、使用しているコンポーネントを突き止めるために使用できる手法も持っています。この情報を知れば、パッチが適用されていない場合にアプリケーションを攻撃する方法がわかります。
脆弱なコンポーネントが危険な理由を知る
既知の脆弱性を持つコンポーネントの使用がいかに危険であるかの証拠を探しているなら、2017年のEquifax違反以外に探す必要はありません。
2017 年 7 月には、 Equifax米国の信用調査機関は、1億4700万人以上の個人を特定できる情報が漏洩する大規模なデータ侵害を発見しました。このデータ漏えいの範囲と影響は前例のないものです。最近、次のようなニュースが出ています。 Equifaxの緩いセキュリティ慣行。
その緩い慣習の1つがパッチ管理でした。Equifaxには適切なパッチ管理手法がなかったため、コンポーネントにパッチが適用されないままかなりの時間が経過していました。 これが違反の直接の原因でした。
Equifaxのウェブサイトが使用していたのは Apache Struts ウェブフレームワーク。攻撃者がネットワークに侵入する数か月前に、Struts フレームワークである Apache Struts CVE-2017-5638 に脆弱性が発見されました。しかし、Equifax はこの脆弱性にパッチを適用しませんでした。攻撃者はこの脆弱性を利用して Equifax のネットワークにアクセスしました。そこから、彼らは個人情報の宝庫にアクセスしました。
多くの Web サイトは、会社が作成していない Web フレームワークをベースにしています。必要な機能をすべてゼロから構築するのは大変な作業なので、これは標準的な手法です。ただし、フレームワークに強く依存していると、脆弱性に陥る可能性があります。次のEquifaxにならないでください。
脆弱なコンポーネントから保護する方法
脆弱なコンポーネントの使用を防ぐための特効薬はありません。ただし、脆弱なコンポーネントがシステムの侵害に利用されるリスクを軽減するために使用できるポリシーや統制があります。
アプリケーションの構築に使用しているコンポーネントと各コンポーネントのバージョンを知っておく必要があります。次のような依存関係管理ツール OWASP の依存関係チェック 使用している依存関係を把握するのに役立ちます。また、Dependency Check は、これらのコンポーネントのいずれかに公開されている脆弱性があるかどうかも教えてくれます。
パッチ管理方法論も不可欠です。脆弱性が発見された場合、パッチのダウンロード、テスト、本番環境へのリリースが円滑に行えるようにシステムを整えてください。ソフトウェアにパッチを適用したままにしておくと、数か月前の脆弱性が攻撃者に利用されるのを防ぐことができます。
最後に、オープンソースとサードパーティのコンポーネントの使用を管理するポリシーを定めてください。開発者は官僚的形式主義を好まないが、それは理解できる。ただし、組織で作成されていないコードについては、審査プロセスが必要です。重いコードである必要はありませんが、未知のコンポーネントが使用されないようにするためには必須です。少なくとも、使用するコンポーネントのインベントリは最新の状態に保つ必要があります。
サードパーティのバグに悩まされないでください
コンポーネントには脆弱性があります。ビジネスアプリケーションは、ベンダーのものであれ、オープンソースライブラリのものであれ、コンポーネントを使用します。だからといって、組織が攻撃に対して脆弱である必要があるわけではありません。
攻撃者はどのような脆弱性が存在するかを知るのと同時に知っていても、通常、パッチは公開発表と同時に公開されます。そのため、アプリケーションに何が使用されているかを把握しておく必要があります。何が脆弱なのかを把握しておきましょう。コンポーネントには常にパッチを適用してください。
脆弱なコンポーネントを発見 (および撃破) する準備はできていますか?アリーナに向かい、戦闘に参加しよう: [ここから始める]
Table des matières
Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。
Secure Code Warrior vous assiste dans la protection de votre code tout au long du cycle de vie du développement logiciel et dans la création d'une culture qui accorde la priorité à la cybersécurité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité des systèmes d'information ou professionnel de la sécurité, nous vous aidons à réduire les risques liés au code non sécurisé.
Veuillez réserver une démonstration.[Télécharger]Ressources pour débuter
Sujets et contenu de la formation sur le code sécurisé
Notre contenu, leader dans le secteur, évolue constamment en fonction de l'environnement de développement logiciel en constante mutation, tout en tenant compte du rôle de nos clients. Il couvre tous les sujets, de l'IA à l'injection XQuery, et s'adresse à divers rôles, des architectes et ingénieurs aux chefs de produit et responsables de l'assurance qualité. Nous vous invitons à consulter le catalogue de contenu pour découvrir son contenu par sujet et par rôle.
La Chambre de commerce établit la norme en matière de sécurité à grande échelle axée sur les développeurs
La Chambre de commerce néerlandaise explique comment elle a intégré le codage sécurisé dans le développement quotidien grâce à des certifications basées sur les rôles, à l'évaluation comparative du Trust Score et à une culture de responsabilité partagée en matière de sécurité.
%20(1).avif)
.avif)
Modélisation des menaces avec l'IA : transformer chaque développeur en modélisateur de menaces
Vous repartirez mieux équipé pour aider les développeurs à combiner les idées et les techniques de modélisation des menaces avec les outils d'IA qu'ils utilisent déjà pour renforcer la sécurité, améliorer la collaboration et créer des logiciels plus résilients dès le départ.
Ressources pour débuter
Cybermon est de retour : la mission IA consistant à vaincre le boss est désormais disponible à la demande.
Cybermon 2025 Beat the Boss est désormais disponible toute l'année sur SCW. Renforcez considérablement le développement sécurisé de l'IA en introduisant des défis de sécurité avancés en matière d'IA/LLM.
Explication de la loi sur la cyber-résilience : implications pour le développement de logiciels sécurisés dès la conception
Découvrez les exigences de la loi européenne sur la résilience cybernétique (CRA), à qui elle s'applique et comment les équipes d'ingénierie peuvent se préparer en matière de pratiques de sécurité dès la conception, de prévention des vulnérabilités et de développement des compétences des développeurs.
Facilitateur 1 : Critères de réussite prédéfinis et mesurables
Enabler 1 est le premier volet d'une série de dix intitulée « Enablers of Success » (Les catalyseurs de la réussite). Il présente comment associer le codage sécurisé à des résultats commerciaux tels que la réduction des risques et l'accélération des processus afin de faire évoluer le programme à long terme.
