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 le ayuda a proteger el código a lo largo de todo el ciclo de vida del desarrollo de software y a crear una cultura que dé prioridad a la ciberseguridad. Tanto si es gestor de seguridad de aplicaciones, desarrollador, CISO o responsable de seguridad, le ayudamos a reducir los riesgos asociados al código inseguro.
Reservar una demostración
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 は、これらのコンポーネントのいずれかに公開されている脆弱性があるかどうかも教えてくれます。
パッチ管理方法論も不可欠です。脆弱性が発見された場合、パッチのダウンロード、テスト、本番環境へのリリースが円滑に行えるようにシステムを整えてください。ソフトウェアにパッチを適用したままにしておくと、数か月前の脆弱性が攻撃者に利用されるのを防ぐことができます。
最後に、オープンソースとサードパーティのコンポーネントの使用を管理するポリシーを定めてください。開発者は官僚的形式主義を好まないが、それは理解できる。ただし、組織で作成されていないコードについては、審査プロセスが必要です。重いコードである必要はありませんが、未知のコンポーネントが使用されないようにするためには必須です。少なくとも、使用するコンポーネントのインベントリは最新の状態に保つ必要があります。
サードパーティのバグに悩まされないでください
コンポーネントには脆弱性があります。ビジネスアプリケーションは、ベンダーのものであれ、オープンソースライブラリのものであれ、コンポーネントを使用します。だからといって、組織が攻撃に対して脆弱である必要があるわけではありません。
攻撃者はどのような脆弱性が存在するかを知るのと同時に知っていても、通常、パッチは公開発表と同時に公開されます。そのため、アプリケーションに何が使用されているかを把握しておく必要があります。何が脆弱なのかを把握しておきましょう。コンポーネントには常にパッチを適用してください。
脆弱なコンポーネントを発見 (および撃破) する準備はできていますか?アリーナに向かい、戦闘に参加しよう: [ここから始める]
Haga clic en el siguiente enlace para descargar el PDF de este recurso.
Secure Code Warrior le ayuda a proteger el código a lo largo de todo el ciclo de vida del desarrollo de software y a crear una cultura que dé prioridad a la ciberseguridad. Tanto si es gestor de seguridad de aplicaciones, desarrollador, CISO o responsable de seguridad, le ayudamos a reducir los riesgos asociados al código inseguro.
Mostrar informeReservar una demostración
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 は、これらのコンポーネントのいずれかに公開されている脆弱性があるかどうかも教えてくれます。
パッチ管理方法論も不可欠です。脆弱性が発見された場合、パッチのダウンロード、テスト、本番環境へのリリースが円滑に行えるようにシステムを整えてください。ソフトウェアにパッチを適用したままにしておくと、数か月前の脆弱性が攻撃者に利用されるのを防ぐことができます。
最後に、オープンソースとサードパーティのコンポーネントの使用を管理するポリシーを定めてください。開発者は官僚的形式主義を好まないが、それは理解できる。ただし、組織で作成されていないコードについては、審査プロセスが必要です。重いコードである必要はありませんが、未知のコンポーネントが使用されないようにするためには必須です。少なくとも、使用するコンポーネントのインベントリは最新の状態に保つ必要があります。
サードパーティのバグに悩まされないでください
コンポーネントには脆弱性があります。ビジネスアプリケーションは、ベンダーのものであれ、オープンソースライブラリのものであれ、コンポーネントを使用します。だからといって、組織が攻撃に対して脆弱である必要があるわけではありません。
攻撃者はどのような脆弱性が存在するかを知るのと同時に知っていても、通常、パッチは公開発表と同時に公開されます。そのため、アプリケーションに何が使用されているかを把握しておく必要があります。何が脆弱なのかを把握しておきましょう。コンポーネントには常にパッチを適用してください。
脆弱なコンポーネントを発見 (および撃破) する準備はできていますか?アリーナに向かい、戦闘に参加しよう: [ここから始める]
Índice
Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。
Secure Code Warrior le ayuda a proteger el código a lo largo de todo el ciclo de vida del desarrollo de software y a crear una cultura que dé prioridad a la ciberseguridad. Tanto si es gestor de seguridad de aplicaciones, desarrollador, CISO o responsable de seguridad, le ayudamos a reducir los riesgos asociados al código inseguro.
Reservar una demostración[Descargar]Recursos para empezar
Temas y contenidos de la formación en código seguro
Nuestro contenido, líder en el sector, evoluciona constantemente para adaptarse al entorno de desarrollo de software en constante cambio, teniendo siempre en cuenta las funciones de nuestros clientes. Abarca todo tipo de temas, desde la inteligencia artificial hasta la inyección de XQuery, y está diseñado para satisfacer las necesidades de diversos perfiles, desde arquitectos e ingenieros hasta gestores de productos y responsables de control de calidad. Echemos un vistazo al contenido que ofrece nuestro catálogo, clasificado por temas y funciones.
La Cámara de Comercio establece el estándar para la seguridad impulsada por desarrolladores a gran escala
Kamer van Koophandel comparte cómo ha integrado la codificación segura en el desarrollo diario mediante certificaciones basadas en roles, evaluaciones comparativas de Trust Score y una cultura de responsabilidad compartida en materia de seguridad.
%20(1).avif)
.avif)
Modelado de amenazas con IA: convertir a cada desarrollador en un modelador de amenazas
Saldrá mejor equipado para ayudar a los desarrolladores a combinar ideas y técnicas de modelado de amenazas con las herramientas de IA que ya utilizan para reforzar la seguridad, mejorar la colaboración y crear software más resistente desde el principio.
Recursos para empezar
Cybermon ha vuelto: la misión de IA para derrotar al jefe ya está disponible bajo demanda.
Ahora se puede jugar a «Cybermon 2025 Beat the Boss» en SCW durante todo el año. Introduzca retos de seguridad avanzados de IA/LLM y refuerce a gran escala el desarrollo seguro de la IA.
Explicación de la Ley de Resiliencia Cibernética: su significado para el desarrollo de software seguro desde el diseño
Descubra qué exige la Ley de Resiliencia Cibernética (CRA) de la UE, a quién se aplica y cómo puede prepararse el equipo de ingeniería para las prácticas de seguridad desde el diseño, la prevención de vulnerabilidades y el desarrollo de las capacidades de los desarrolladores.
Enable 1: Criterios de éxito predefinidos y medibles
Enabler 1 es la primera parte de la serie Enablers of Success, compuesta por diez partes, y presenta cómo madurar un programa a largo plazo vinculando la codificación segura con resultados empresariales como la reducción de riesgos y la velocidad.
