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 schützt Ihren Code während des gesamten Softwareentwicklungszyklus und hilft Ihnen dabei, eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie Anwendungs-Sicherheitsmanager, Entwickler, CISO oder Sicherheitsbeauftragter sind – wir helfen Ihnen dabei, die mit unsicherem Code verbundenen Risiken zu minimieren.
デモを予約
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 は、これらのコンポーネントのいずれかに公開されている脆弱性があるかどうかも教えてくれます。
パッチ管理方法論も不可欠です。脆弱性が発見された場合、パッチのダウンロード、テスト、本番環境へのリリースが円滑に行えるようにシステムを整えてください。ソフトウェアにパッチを適用したままにしておくと、数か月前の脆弱性が攻撃者に利用されるのを防ぐことができます。
最後に、オープンソースとサードパーティのコンポーネントの使用を管理するポリシーを定めてください。開発者は官僚的形式主義を好まないが、それは理解できる。ただし、組織で作成されていないコードについては、審査プロセスが必要です。重いコードである必要はありませんが、未知のコンポーネントが使用されないようにするためには必須です。少なくとも、使用するコンポーネントのインベントリは最新の状態に保つ必要があります。
サードパーティのバグに悩まされないでください
コンポーネントには脆弱性があります。ビジネスアプリケーションは、ベンダーのものであれ、オープンソースライブラリのものであれ、コンポーネントを使用します。だからといって、組織が攻撃に対して脆弱である必要があるわけではありません。
攻撃者はどのような脆弱性が存在するかを知るのと同時に知っていても、通常、パッチは公開発表と同時に公開されます。そのため、アプリケーションに何が使用されているかを把握しておく必要があります。何が脆弱なのかを把握しておきましょう。コンポーネントには常にパッチを適用してください。
脆弱なコンポーネントを発見 (および撃破) する準備はできていますか?アリーナに向かい、戦闘に参加しよう: [ここから始める]
Klicken Sie auf den folgenden Link, um die PDF-Datei dieser Ressource herunterzuladen.
Secure Code Warrior schützt Ihren Code während des gesamten Softwareentwicklungszyklus und hilft Ihnen dabei, eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie Anwendungs-Sicherheitsmanager, Entwickler, CISO oder Sicherheitsbeauftragter sind – wir helfen Ihnen dabei, die mit unsicherem Code verbundenen Risiken zu minimieren.
Bericht anzeigenデモを予約
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 は、これらのコンポーネントのいずれかに公開されている脆弱性があるかどうかも教えてくれます。
パッチ管理方法論も不可欠です。脆弱性が発見された場合、パッチのダウンロード、テスト、本番環境へのリリースが円滑に行えるようにシステムを整えてください。ソフトウェアにパッチを適用したままにしておくと、数か月前の脆弱性が攻撃者に利用されるのを防ぐことができます。
最後に、オープンソースとサードパーティのコンポーネントの使用を管理するポリシーを定めてください。開発者は官僚的形式主義を好まないが、それは理解できる。ただし、組織で作成されていないコードについては、審査プロセスが必要です。重いコードである必要はありませんが、未知のコンポーネントが使用されないようにするためには必須です。少なくとも、使用するコンポーネントのインベントリは最新の状態に保つ必要があります。
サードパーティのバグに悩まされないでください
コンポーネントには脆弱性があります。ビジネスアプリケーションは、ベンダーのものであれ、オープンソースライブラリのものであれ、コンポーネントを使用します。だからといって、組織が攻撃に対して脆弱である必要があるわけではありません。
攻撃者はどのような脆弱性が存在するかを知るのと同時に知っていても、通常、パッチは公開発表と同時に公開されます。そのため、アプリケーションに何が使用されているかを把握しておく必要があります。何が脆弱なのかを把握しておきましょう。コンポーネントには常にパッチを適用してください。
脆弱なコンポーネントを発見 (および撃破) する準備はできていますか?アリーナに向かい、戦闘に参加しよう: [ここから始める]
目次
Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。
Secure Code Warrior schützt Ihren Code während des gesamten Softwareentwicklungszyklus und hilft Ihnen dabei, eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie Anwendungs-Sicherheitsmanager, Entwickler, CISO oder Sicherheitsbeauftragter sind – wir helfen Ihnen dabei, die mit unsicherem Code verbundenen Risiken zu minimieren.
デモを予約[ダウンロード]Ressourcen für den Einstieg
Themen und Inhalte der Secure-Code-Schulung
Unsere branchenführenden Inhalte werden unter Berücksichtigung der Aufgaben unserer Kunden ständig weiterentwickelt, um mit der sich ständig verändernden Softwareentwicklungsumgebung Schritt zu halten. Sie decken alle Themen von KI bis hin zu XQuery-Injection ab und sind für verschiedene Aufgabenbereiche konzipiert, von Architekten und Ingenieuren bis hin zu Produktmanagern und Qualitätssicherungsfachleuten. Werfen Sie einen Blick auf die Inhalte unseres Content-Katalogs, sortiert nach Themen und Aufgabenbereichen.
Die Kamer van Koophandel setzt Maßstäbe für entwicklergesteuerte Sicherheit in großem Maßstab
Die Kamer van Koophandel berichtet, wie sie sicheres Codieren durch rollenbasierte Zertifizierungen, Trust Score-Benchmarking und eine Kultur der gemeinsamen Verantwortung für Sicherheit in die tägliche Entwicklungsarbeit integriert hat.
%20(1).avif)
.avif)
Bedrohungsmodellierung mit KI: So wird jeder Entwickler zum Bedrohungsmodellierer
Sie werden besser gerüstet sein, um Entwicklern dabei zu helfen, Ideen und Techniken zur Bedrohungsmodellierung mit den KI-Tools zu kombinieren, die sie bereits verwenden, um die Sicherheit zu erhöhen, die Zusammenarbeit zu verbessern und von Anfang an widerstandsfähigere Software zu entwickeln.
Ressourcen für den Einstieg
Cybermon ist zurück: Die KI-Mission zum Besiegen des Bosses ist jetzt auf Abruf verfügbar.
「Cybermon 2025 Beat the Boss」 kann nun das ganze Jahr über bei SCW gespielt werden. Führen Sie anspruchsvolle AI/LLM-Sicherheitsherausforderungen ein, um die sichere AI-Entwicklung in großem Maßstab zu stärken.
Erläuterung des Cyber-Resilience-Gesetzes: Bedeutung für die Entwicklung sicherer Software
Erfahren Sie, was das EU-Gesetz zur Cyberresilienz (CRA) verlangt, für wen es gilt und wie sich Ingenieurteams auf Secure-by-Design-Praktiken, Schwachstellenprävention und die Kompetenzentwicklung von Entwicklern vorbereiten können.
Enabler 1: Definierte und messbare Erfolgskriterien
Enabler 1 ist der erste Teil der zehnteiligen Reihe „Enablers of Success“ und zeigt, wie sichere Programmierung mit geschäftlichen Ergebnissen wie Risikominderung und Geschwindigkeit verknüpft werden kann, um Programme langfristig zu optimieren.
