コーダーズ・コンカー・コンカー・セキュリティ：シェア＆ラーニング・シリーズ-アクセス制御の破損
ビジネスアプリケーションを構築する場合、内部使用か顧客による外部使用かにかかわらず、すべてのユーザーにすべての機能を実行させることはおそらくありません。そうすると、アクセス制御が破られやすくなる可能性があります。
壊れたアクセス制御とは何か、なぜそれほど危険なのか、そしてそれを修正する方法を見てみましょう。
壊れたアクセス制御を理解する
アクセス制御が機能しなくなるのは、アプリケーションコードに適切なセキュリティチェックやアクセスチェックが行われていない場合です。また、アプリケーションが何らかの形で誤って設定され、ユーザーがアクセスしてはいけない機能やページにアクセスできるようになった場合にも発生します。
会社の財務を管理している場合は、特定の口座への入金や会社の口座間での送金にアクセスできる場合があります。ただし、それらの口座から現金を引き出したり、他の口座に送金したりすることはできないはずです。適切なアクセスチェックが行われていないと、従業員が必要以上に多くの職務を遂行できなくなる可能性があります。
これらのチェックは、コード内または構成ファイル内で実行できます。たとえば、どのユーザーがどのページにアクセスできるかをウェブアプリケーションフレームワークに指示する XML 設定ファイルがあるかもしれません。これにより、ユーザーは使用を許可された機能にのみアクセスできるようになります。
アクセス制御の破れが危険な理由
次の例を考えてみましょう。攻撃者は、ユーザーアカウント作成コードが操作される可能性があることに気付きました。これにより、攻撃者は単純な POST リクエストで管理者ユーザーを作成できます。攻撃者はユーザー名とパスワードを使用してリクエストを送信し、途中で変更して、URL にパラメーターとして admin の役割を含めるか、リクエストの本文に admin の役割を含めることができます。攻撃者はアプリケーションにログインすると、即座に管理者権限が付与されます。
システムへの侵入は、必ずしも悪意のある攻撃者である必要はありません。適切なアクセス制御を行わないと、部署間で共有すべきではない機密情報が漏洩する可能性があります。社内の従業員が HR の給与データや財務データを見ることができたと想像してみてください。会社の財政状況が悪いためにレイオフが起きていることに従業員が気づいたらどうなるでしょうか。これはあなたの士気や会社の評判を傷つける可能性があります。
顧客の機密情報も失われる可能性があります。企業は、自社のサービスを利用する顧客の個人情報を保存することがよくあります。アクセス制御が欠如しているからといって、誤って個人情報を漏らさないように注意してください。たとえば、システムがユーザーに自分の健康記録を要求できるようにしている場合、そのユーザーは他のユーザーの健康情報を要求して確認することもできますか？URL に顧客 ID 番号が含まれている場合、攻撃者は別の顧客と一致する番号を見つけるまでその顧客 ID 番号を何度も増やし、個人データを漏洩させる可能性があります。
壊れたアクセス制御を倒す
役割ベースのアクセス制御 (RBAC) は、適切なアクセス制御を実装するための非常に効果的なツールです。Active Directory を使っている方なら、次のような考え方に馴染みがあるかもしれません。 グループの作成 個人ではなく、グループ全体の特定のアイテムへのアクセスを許可します。アプリケーションも同じように機能し、ロールを使って誰が何を見ることができるかを定義します。
これには 2 つの利点があります。1 つ目は、誰かが管理者ロールを離れても機能を変更する必要がないことです。誰かが以前は管理者でしたが、今はそうすべきではない場合は、新しい人を管理者ロールに配置し、前のユーザーをロールから削除するだけです。このコードは、個々のユーザーが特定のページや機能にアクセスできるかどうかを調べるのではなく、そのユーザーが管理者ロールを持っているかどうかをチェックします。
2 つ目のメリットは、メンテナンスの手間を省くことです。アクセス制御がきめ細かすぎて、すべてのユーザーがすべての機能やページに関連付けられるようになっていると、時間が経つと管理できなくなります。1 つのロールに複数のユーザーを追加できるため、ロールを使用すると作業がはるかに簡単になります。1 つのロールには会社全体が含まれ、別のロールには 5 人しか含まれない場合もあります。これにより、管理する役割が少なくなるため、役割の管理がより効率的になります。従業員数が 10,000 人の企業では、アプリケーションの機能数の 10,000 倍ではなく、100 の役割しか割り当てることができません。選択したアプリケーションフレームワークを調べて、堅牢なアクセス制御にはどのような選択肢があるかを調べてください。
また、機能レベルのアクセス制御を使用することも重要です。特定のアクセス制御チェックに合格するようユーザーに要求することで、すべての機能へのアクセスを保護します。最小権限の原則に従い、デフォルトではアクセスを拒否し、必要な場合にのみアクセスを許可します。機能ごとにアクセス制御を実装することを覚えておくのは難しいかもしれません。アクセス制御の管理と実施には、中央コンポーネントを使用してください。
デリケートな機能を保護
アクセス制御が壊れていると、データやアプリケーションが攻撃や悪用の危険にさらされる可能性があります。顧客データが適切に保護されていないと、大規模なデータ侵害が発生し、評判や収益が損なわれる可能性があります。
攻撃者がアクセスしてはいけない機能にアクセスできれば、アクセス制御が破られると、アカウントの乗っ取りにつながる可能性もあります。適切な機能レベルのアクセス制御を行うことで、悪意のある攻撃者や偶発的な内部関係者からアプリケーションを安全に保つことができます。
機能レベルのアクセス権限を使い果たしているとお考えですか？壊れたアクセス制御の修復に今すぐ挑戦してみましょう。 [ここから始める]
ビジネスアプリケーションを構築する場合、内部使用か顧客による外部使用かにかかわらず、すべてのユーザーにすべての機能を実行させることはおそらくありません。そうすると、アクセス制御が破られやすくなる可能性があります。
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は、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。
ビジネスアプリケーションを構築する場合、内部使用か顧客による外部使用かにかかわらず、すべてのユーザーにすべての機能を実行させることはおそらくありません。そうすると、アクセス制御が破られやすくなる可能性があります。
壊れたアクセス制御とは何か、なぜそれほど危険なのか、そしてそれを修正する方法を見てみましょう。
壊れたアクセス制御を理解する
アクセス制御が機能しなくなるのは、アプリケーションコードに適切なセキュリティチェックやアクセスチェックが行われていない場合です。また、アプリケーションが何らかの形で誤って設定され、ユーザーがアクセスしてはいけない機能やページにアクセスできるようになった場合にも発生します。
会社の財務を管理している場合は、特定の口座への入金や会社の口座間での送金にアクセスできる場合があります。ただし、それらの口座から現金を引き出したり、他の口座に送金したりすることはできないはずです。適切なアクセスチェックが行われていないと、従業員が必要以上に多くの職務を遂行できなくなる可能性があります。
これらのチェックは、コード内または構成ファイル内で実行できます。たとえば、どのユーザーがどのページにアクセスできるかをウェブアプリケーションフレームワークに指示する XML 設定ファイルがあるかもしれません。これにより、ユーザーは使用を許可された機能にのみアクセスできるようになります。
アクセス制御の破れが危険な理由
次の例を考えてみましょう。攻撃者は、ユーザーアカウント作成コードが操作される可能性があることに気付きました。これにより、攻撃者は単純な POST リクエストで管理者ユーザーを作成できます。攻撃者はユーザー名とパスワードを使用してリクエストを送信し、途中で変更して、URL にパラメーターとして admin の役割を含めるか、リクエストの本文に admin の役割を含めることができます。攻撃者はアプリケーションにログインすると、即座に管理者権限が付与されます。
システムへの侵入は、必ずしも悪意のある攻撃者である必要はありません。適切なアクセス制御を行わないと、部署間で共有すべきではない機密情報が漏洩する可能性があります。社内の従業員が HR の給与データや財務データを見ることができたと想像してみてください。会社の財政状況が悪いためにレイオフが起きていることに従業員が気づいたらどうなるでしょうか。これはあなたの士気や会社の評判を傷つける可能性があります。
顧客の機密情報も失われる可能性があります。企業は、自社のサービスを利用する顧客の個人情報を保存することがよくあります。アクセス制御が欠如しているからといって、誤って個人情報を漏らさないように注意してください。たとえば、システムがユーザーに自分の健康記録を要求できるようにしている場合、そのユーザーは他のユーザーの健康情報を要求して確認することもできますか？URL に顧客 ID 番号が含まれている場合、攻撃者は別の顧客と一致する番号を見つけるまでその顧客 ID 番号を何度も増やし、個人データを漏洩させる可能性があります。
壊れたアクセス制御を倒す
役割ベースのアクセス制御 (RBAC) は、適切なアクセス制御を実装するための非常に効果的なツールです。Active Directory を使っている方なら、次のような考え方に馴染みがあるかもしれません。 グループの作成 個人ではなく、グループ全体の特定のアイテムへのアクセスを許可します。アプリケーションも同じように機能し、ロールを使って誰が何を見ることができるかを定義します。
これには 2 つの利点があります。1 つ目は、誰かが管理者ロールを離れても機能を変更する必要がないことです。誰かが以前は管理者でしたが、今はそうすべきではない場合は、新しい人を管理者ロールに配置し、前のユーザーをロールから削除するだけです。このコードは、個々のユーザーが特定のページや機能にアクセスできるかどうかを調べるのではなく、そのユーザーが管理者ロールを持っているかどうかをチェックします。
2 つ目のメリットは、メンテナンスの手間を省くことです。アクセス制御がきめ細かすぎて、すべてのユーザーがすべての機能やページに関連付けられるようになっていると、時間が経つと管理できなくなります。1 つのロールに複数のユーザーを追加できるため、ロールを使用すると作業がはるかに簡単になります。1 つのロールには会社全体が含まれ、別のロールには 5 人しか含まれない場合もあります。これにより、管理する役割が少なくなるため、役割の管理がより効率的になります。従業員数が 10,000 人の企業では、アプリケーションの機能数の 10,000 倍ではなく、100 の役割しか割り当てることができません。選択したアプリケーションフレームワークを調べて、堅牢なアクセス制御にはどのような選択肢があるかを調べてください。
また、機能レベルのアクセス制御を使用することも重要です。特定のアクセス制御チェックに合格するようユーザーに要求することで、すべての機能へのアクセスを保護します。最小権限の原則に従い、デフォルトではアクセスを拒否し、必要な場合にのみアクセスを許可します。機能ごとにアクセス制御を実装することを覚えておくのは難しいかもしれません。アクセス制御の管理と実施には、中央コンポーネントを使用してください。
デリケートな機能を保護
アクセス制御が壊れていると、データやアプリケーションが攻撃や悪用の危険にさらされる可能性があります。顧客データが適切に保護されていないと、大規模なデータ侵害が発生し、評判や収益が損なわれる可能性があります。
攻撃者がアクセスしてはいけない機能にアクセスできれば、アクセス制御が破られると、アカウントの乗っ取りにつながる可能性もあります。適切な機能レベルのアクセス制御を行うことで、悪意のある攻撃者や偶発的な内部関係者からアプリケーションを安全に保つことができます。
機能レベルのアクセス権限を使い果たしているとお考えですか？壊れたアクセス制御の修復に今すぐ挑戦してみましょう。 [ここから始める]
ビジネスアプリケーションを構築する場合、内部使用か顧客による外部使用かにかかわらず、すべてのユーザーにすべての機能を実行させることはおそらくありません。そうすると、アクセス制御が破られやすくなる可能性があります。
壊れたアクセス制御とは何か、なぜそれほど危険なのか、そしてそれを修正する方法を見てみましょう。
壊れたアクセス制御を理解する
アクセス制御が機能しなくなるのは、アプリケーションコードに適切なセキュリティチェックやアクセスチェックが行われていない場合です。また、アプリケーションが何らかの形で誤って設定され、ユーザーがアクセスしてはいけない機能やページにアクセスできるようになった場合にも発生します。
会社の財務を管理している場合は、特定の口座への入金や会社の口座間での送金にアクセスできる場合があります。ただし、それらの口座から現金を引き出したり、他の口座に送金したりすることはできないはずです。適切なアクセスチェックが行われていないと、従業員が必要以上に多くの職務を遂行できなくなる可能性があります。
これらのチェックは、コード内または構成ファイル内で実行できます。たとえば、どのユーザーがどのページにアクセスできるかをウェブアプリケーションフレームワークに指示する XML 設定ファイルがあるかもしれません。これにより、ユーザーは使用を許可された機能にのみアクセスできるようになります。
アクセス制御の破れが危険な理由
次の例を考えてみましょう。攻撃者は、ユーザーアカウント作成コードが操作される可能性があることに気付きました。これにより、攻撃者は単純な POST リクエストで管理者ユーザーを作成できます。攻撃者はユーザー名とパスワードを使用してリクエストを送信し、途中で変更して、URL にパラメーターとして admin の役割を含めるか、リクエストの本文に admin の役割を含めることができます。攻撃者はアプリケーションにログインすると、即座に管理者権限が付与されます。
システムへの侵入は、必ずしも悪意のある攻撃者である必要はありません。適切なアクセス制御を行わないと、部署間で共有すべきではない機密情報が漏洩する可能性があります。社内の従業員が HR の給与データや財務データを見ることができたと想像してみてください。会社の財政状況が悪いためにレイオフが起きていることに従業員が気づいたらどうなるでしょうか。これはあなたの士気や会社の評判を傷つける可能性があります。
顧客の機密情報も失われる可能性があります。企業は、自社のサービスを利用する顧客の個人情報を保存することがよくあります。アクセス制御が欠如しているからといって、誤って個人情報を漏らさないように注意してください。たとえば、システムがユーザーに自分の健康記録を要求できるようにしている場合、そのユーザーは他のユーザーの健康情報を要求して確認することもできますか？URL に顧客 ID 番号が含まれている場合、攻撃者は別の顧客と一致する番号を見つけるまでその顧客 ID 番号を何度も増やし、個人データを漏洩させる可能性があります。
壊れたアクセス制御を倒す
役割ベースのアクセス制御 (RBAC) は、適切なアクセス制御を実装するための非常に効果的なツールです。Active Directory を使っている方なら、次のような考え方に馴染みがあるかもしれません。 グループの作成 個人ではなく、グループ全体の特定のアイテムへのアクセスを許可します。アプリケーションも同じように機能し、ロールを使って誰が何を見ることができるかを定義します。
これには 2 つの利点があります。1 つ目は、誰かが管理者ロールを離れても機能を変更する必要がないことです。誰かが以前は管理者でしたが、今はそうすべきではない場合は、新しい人を管理者ロールに配置し、前のユーザーをロールから削除するだけです。このコードは、個々のユーザーが特定のページや機能にアクセスできるかどうかを調べるのではなく、そのユーザーが管理者ロールを持っているかどうかをチェックします。
2 つ目のメリットは、メンテナンスの手間を省くことです。アクセス制御がきめ細かすぎて、すべてのユーザーがすべての機能やページに関連付けられるようになっていると、時間が経つと管理できなくなります。1 つのロールに複数のユーザーを追加できるため、ロールを使用すると作業がはるかに簡単になります。1 つのロールには会社全体が含まれ、別のロールには 5 人しか含まれない場合もあります。これにより、管理する役割が少なくなるため、役割の管理がより効率的になります。従業員数が 10,000 人の企業では、アプリケーションの機能数の 10,000 倍ではなく、100 の役割しか割り当てることができません。選択したアプリケーションフレームワークを調べて、堅牢なアクセス制御にはどのような選択肢があるかを調べてください。
また、機能レベルのアクセス制御を使用することも重要です。特定のアクセス制御チェックに合格するようユーザーに要求することで、すべての機能へのアクセスを保護します。最小権限の原則に従い、デフォルトではアクセスを拒否し、必要な場合にのみアクセスを許可します。機能ごとにアクセス制御を実装することを覚えておくのは難しいかもしれません。アクセス制御の管理と実施には、中央コンポーネントを使用してください。
デリケートな機能を保護
アクセス制御が壊れていると、データやアプリケーションが攻撃や悪用の危険にさらされる可能性があります。顧客データが適切に保護されていないと、大規模なデータ侵害が発生し、評判や収益が損なわれる可能性があります。
攻撃者がアクセスしてはいけない機能にアクセスできれば、アクセス制御が破られると、アカウントの乗っ取りにつながる可能性もあります。適切な機能レベルのアクセス制御を行うことで、悪意のある攻撃者や偶発的な内部関係者からアプリケーションを安全に保つことができます。
機能レベルのアクセス権限を使い果たしているとお考えですか？壊れたアクセス制御の修復に今すぐ挑戦してみましょう。 [ここから始める]
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は、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。
ビジネスアプリケーションを構築する場合、内部使用か顧客による外部使用かにかかわらず、すべてのユーザーにすべての機能を実行させることはおそらくありません。そうすると、アクセス制御が破られやすくなる可能性があります。
壊れたアクセス制御とは何か、なぜそれほど危険なのか、そしてそれを修正する方法を見てみましょう。
壊れたアクセス制御を理解する
アクセス制御が機能しなくなるのは、アプリケーションコードに適切なセキュリティチェックやアクセスチェックが行われていない場合です。また、アプリケーションが何らかの形で誤って設定され、ユーザーがアクセスしてはいけない機能やページにアクセスできるようになった場合にも発生します。
会社の財務を管理している場合は、特定の口座への入金や会社の口座間での送金にアクセスできる場合があります。ただし、それらの口座から現金を引き出したり、他の口座に送金したりすることはできないはずです。適切なアクセスチェックが行われていないと、従業員が必要以上に多くの職務を遂行できなくなる可能性があります。
これらのチェックは、コード内または構成ファイル内で実行できます。たとえば、どのユーザーがどのページにアクセスできるかをウェブアプリケーションフレームワークに指示する XML 設定ファイルがあるかもしれません。これにより、ユーザーは使用を許可された機能にのみアクセスできるようになります。
アクセス制御の破れが危険な理由
次の例を考えてみましょう。攻撃者は、ユーザーアカウント作成コードが操作される可能性があることに気付きました。これにより、攻撃者は単純な POST リクエストで管理者ユーザーを作成できます。攻撃者はユーザー名とパスワードを使用してリクエストを送信し、途中で変更して、URL にパラメーターとして admin の役割を含めるか、リクエストの本文に admin の役割を含めることができます。攻撃者はアプリケーションにログインすると、即座に管理者権限が付与されます。
システムへの侵入は、必ずしも悪意のある攻撃者である必要はありません。適切なアクセス制御を行わないと、部署間で共有すべきではない機密情報が漏洩する可能性があります。社内の従業員が HR の給与データや財務データを見ることができたと想像してみてください。会社の財政状況が悪いためにレイオフが起きていることに従業員が気づいたらどうなるでしょうか。これはあなたの士気や会社の評判を傷つける可能性があります。
顧客の機密情報も失われる可能性があります。企業は、自社のサービスを利用する顧客の個人情報を保存することがよくあります。アクセス制御が欠如しているからといって、誤って個人情報を漏らさないように注意してください。たとえば、システムがユーザーに自分の健康記録を要求できるようにしている場合、そのユーザーは他のユーザーの健康情報を要求して確認することもできますか？URL に顧客 ID 番号が含まれている場合、攻撃者は別の顧客と一致する番号を見つけるまでその顧客 ID 番号を何度も増やし、個人データを漏洩させる可能性があります。
壊れたアクセス制御を倒す
役割ベースのアクセス制御 (RBAC) は、適切なアクセス制御を実装するための非常に効果的なツールです。Active Directory を使っている方なら、次のような考え方に馴染みがあるかもしれません。 グループの作成 個人ではなく、グループ全体の特定のアイテムへのアクセスを許可します。アプリケーションも同じように機能し、ロールを使って誰が何を見ることができるかを定義します。
これには 2 つの利点があります。1 つ目は、誰かが管理者ロールを離れても機能を変更する必要がないことです。誰かが以前は管理者でしたが、今はそうすべきではない場合は、新しい人を管理者ロールに配置し、前のユーザーをロールから削除するだけです。このコードは、個々のユーザーが特定のページや機能にアクセスできるかどうかを調べるのではなく、そのユーザーが管理者ロールを持っているかどうかをチェックします。
2 つ目のメリットは、メンテナンスの手間を省くことです。アクセス制御がきめ細かすぎて、すべてのユーザーがすべての機能やページに関連付けられるようになっていると、時間が経つと管理できなくなります。1 つのロールに複数のユーザーを追加できるため、ロールを使用すると作業がはるかに簡単になります。1 つのロールには会社全体が含まれ、別のロールには 5 人しか含まれない場合もあります。これにより、管理する役割が少なくなるため、役割の管理がより効率的になります。従業員数が 10,000 人の企業では、アプリケーションの機能数の 10,000 倍ではなく、100 の役割しか割り当てることができません。選択したアプリケーションフレームワークを調べて、堅牢なアクセス制御にはどのような選択肢があるかを調べてください。
また、機能レベルのアクセス制御を使用することも重要です。特定のアクセス制御チェックに合格するようユーザーに要求することで、すべての機能へのアクセスを保護します。最小権限の原則に従い、デフォルトではアクセスを拒否し、必要な場合にのみアクセスを許可します。機能ごとにアクセス制御を実装することを覚えておくのは難しいかもしれません。アクセス制御の管理と実施には、中央コンポーネントを使用してください。
デリケートな機能を保護
アクセス制御が壊れていると、データやアプリケーションが攻撃や悪用の危険にさらされる可能性があります。顧客データが適切に保護されていないと、大規模なデータ侵害が発生し、評判や収益が損なわれる可能性があります。
攻撃者がアクセスしてはいけない機能にアクセスできれば、アクセス制御が破られると、アカウントの乗っ取りにつながる可能性もあります。適切な機能レベルのアクセス制御を行うことで、悪意のある攻撃者や偶発的な内部関係者からアプリケーションを安全に保つことができます。
機能レベルのアクセス権限を使い果たしているとお考えですか？壊れたアクセス制御の修復に今すぐ挑戦してみましょう。 [ここから始める]
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.
