トロイの木馬とは何か、どうやってソースコードに忍び込むのか
11月初旬、ケンブリッジ大学は、「 Trojan-Source」と呼ばれる研究結果を発表しました。この研究では、ソースコードやコメントの中に、方向性のある書式文字を使ってバックドアを隠せることに着目しました。これを利用して、人間のコードレビュアーとコンパイラが異なるロジックを解釈するコードを作成することができます。
この脆弱性は新しいものですが、Unicodeは過去にもファイル名の最後の部分の向きを逆にすることでファイルの真の拡張子を隠すなど、悪用されたことがあります。今回の調査では、多くのコンパイラがソースコード中のUnicode文字を警告なしに無視するのに対し、コードエディタを含むテキストエディタでは、コメントやそれに基づくコードを含む行がリフローされてしまうことが判明しました。そのため、エディタはコードやコメントをコンパイラの解析方法とは異なる順序で表示し、コードとコメントが入れ替わることもある。
詳しくはこちらをご覧ください。また、腕まくりをしてトロイの木馬ソースのシミュレーションハッキングを試してみたい方は、無料のパブリックミッションに飛び込んでご自身で体験してみてはいかがでしょうか。
双方向性テキスト
これらのトロイの木馬ソースの攻撃の1つは、英語（左から右）とアラビア語（右から左）のように、表示順序が異なるテキストをどのようにまとめるかを扱うUnicode Bidi（双方向）アルゴリズムを利用しています。方向性のあるフォーマット文字を使用することで、グループ化を再編成し、文字の順序を表示することができます。
上の表には、攻撃に関連するBidiのオーバーライド文字の一部が含まれています。例を挙げてみましょう。
RLIE D O CP D I
RLIという略語は、Right-to-Left Isolateの略です。文脈（PDI、Pop-Directional-Isolateで区切られる）からテキストを分離し、右から左へと読むことになります。結果的には
C O D E
しかし、コンパイラやインタプリタは、ソースコードを解析する前に、Bidiオーバーライドを含むフォーマット制御文字を処理しないのが普通です。単純に方向性のある書式制御文字を無視すれば、解析されてしまうのです。
E D O C
古いワインを新しいボトルで？
もちろん、これは日の目を見ないことです。過去には、ファイル名に方向性のあるフォーマット文字を挿入して、悪意のある性質を偽装したこともあります。メールの添付ファイルが「myspecialexe.doc」と表示されていても、RLO（Right-to-Left override）文字がなければ、本当の名前は「myspecialcod.exe」であることがわかり、無害に見えるかもしれません。
トロイの木馬のソース攻撃では、構文エラーやコンパイルエラーが発生しないように、ソースコードに存在するコメントや文字列に方向性のある書式文字を挿入します。これらの制御文字は、コードのロジックの表示順序を変更し、人間が読むのとは全く異なるものをコンパイラに読ませます。
例えば、次のバイトをこの順番で並べたファイル。
は、方向性のあるフォーマット文字によって、以下のように並び替えられます。
のように表示されることがあります。
RLOは最後の行で、閉じ括弧を開き括弧に反転させ、その逆も行います。このコードを実行した結果は、次のようになります。"You are an admin" です。管理者チェックはコメントアウトされていますが、制御文字はまだ存在しているように見えます。
(Source: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
どのような影響があるのでしょうか？
多くの言語がこの攻撃に脆弱である。C、C++、C#、JavaScript、Java、Rust、Go、Pythonなどで、さらに多くの言語があると考えられます。平均的な開発者は、ソースコードに方向性のあるフォーマット文字を見て眉をひそめるかもしれませんが、初心者は肩をすくめて何も考えないかもしれません。さらに、これらの文字の表示方法はIDEに大きく依存しているため、絶対に見られるとは限りません。
しかし、そもそもこの脆弱性はどのようにしてソースコードに忍び込むことができるのでしょうか。まず第一に、信頼できないソースコードを使用した場合、悪意のあるコードが混入していても気づかないことがあります。第二に、インターネット上で見つけたコードを単純にコピー・ペーストした場合にも起こり得ます。ほとんどの組織は、複数のベンダーのソフトウェアコンポーネントに依存しています。そこで問題となるのが、これらのコードをどこまで完全に信頼できるのかということです。バックドアが隠されているソースコードをどのようにしてスクリーニングすればよいのでしょうか。
それは誰の問題なのか？
一方で、コンパイラやビルドパイプラインは、1つの方向が文字列やコメントに厳密に制限されている場合を除き、複数の方向を持つソースコード行を許可しないようにすべきです。文字列やコメントに含まれる方向性のあるフォーマット文字は、ポップされていなければ、方向性の変更を行の最後まで延長することができることに注意してください。一般に、コードエディターは、同音異義語や方向指示文字などの疑わしいUnicode文字を明示的にレンダリングし、ハイライトする必要があります。11月以降、GitHubでは双方向のユニコードテキストを含むすべてのコード行に警告記号とメッセージを追加するようになりましたが、これらの文字が行のどこにあるかは強調表示されません。これでは、悪意のある方向転換が良性の方向転換と一緒に潜り込んでしまう可能性があります。
開発者やコードレビュー担当者の間での認知度を高めることが重要であることから、この脆弱性を説明するウォークスルーを作成しました。現在、このウォークスルーは、Java、C#、Python、GO、およびPHPで利用可能です。
もっと詳しく知りたい方は、Trojan Sourceのシミュレーション（公開missions ）を試してみたり、Trojan Sourceの研究を読んでみてください。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
デモを予約する
Laura Verheyde はSecure Code Warrior のソフトウェア開発者で、脆弱性のリサーチとMissions および Coding labs のコンテンツ作成に注力している。
11月初旬、ケンブリッジ大学は、「 Trojan-Source」と呼ばれる研究結果を発表しました。この研究では、ソースコードやコメントの中に、方向性のある書式文字を使ってバックドアを隠せることに着目しました。これを利用して、人間のコードレビュアーとコンパイラが異なるロジックを解釈するコードを作成することができます。
この脆弱性は新しいものですが、Unicodeは過去にもファイル名の最後の部分の向きを逆にすることでファイルの真の拡張子を隠すなど、悪用されたことがあります。今回の調査では、多くのコンパイラがソースコード中のUnicode文字を警告なしに無視するのに対し、コードエディタを含むテキストエディタでは、コメントやそれに基づくコードを含む行がリフローされてしまうことが判明しました。そのため、エディタはコードやコメントをコンパイラの解析方法とは異なる順序で表示し、コードとコメントが入れ替わることもある。
詳しくはこちらをご覧ください。また、腕まくりをしてトロイの木馬ソースのシミュレーションハッキングを試してみたい方は、無料のパブリックミッションに飛び込んでご自身で体験してみてはいかがでしょうか。
双方向性テキスト
これらのトロイの木馬ソースの攻撃の1つは、英語（左から右）とアラビア語（右から左）のように、表示順序が異なるテキストをどのようにまとめるかを扱うUnicode Bidi（双方向）アルゴリズムを利用しています。方向性のあるフォーマット文字を使用することで、グループ化を再編成し、文字の順序を表示することができます。
上の表には、攻撃に関連するBidiのオーバーライド文字の一部が含まれています。例を挙げてみましょう。
RLIE D O CP D I
RLIという略語は、Right-to-Left Isolateの略です。文脈（PDI、Pop-Directional-Isolateで区切られる）からテキストを分離し、右から左へと読むことになります。結果的には
C O D E
しかし、コンパイラやインタプリタは、ソースコードを解析する前に、Bidiオーバーライドを含むフォーマット制御文字を処理しないのが普通です。単純に方向性のある書式制御文字を無視すれば、解析されてしまうのです。
E D O C
古いワインを新しいボトルで？
もちろん、これは日の目を見ないことです。過去には、ファイル名に方向性のあるフォーマット文字を挿入して、悪意のある性質を偽装したこともあります。メールの添付ファイルが「myspecialexe.doc」と表示されていても、RLO（Right-to-Left override）文字がなければ、本当の名前は「myspecialcod.exe」であることがわかり、無害に見えるかもしれません。
トロイの木馬のソース攻撃では、構文エラーやコンパイルエラーが発生しないように、ソースコードに存在するコメントや文字列に方向性のある書式文字を挿入します。これらの制御文字は、コードのロジックの表示順序を変更し、人間が読むのとは全く異なるものをコンパイラに読ませます。
例えば、次のバイトをこの順番で並べたファイル。
は、方向性のあるフォーマット文字によって、以下のように並び替えられます。
のように表示されることがあります。
RLOは最後の行で、閉じ括弧を開き括弧に反転させ、その逆も行います。このコードを実行した結果は、次のようになります。"You are an admin" です。管理者チェックはコメントアウトされていますが、制御文字はまだ存在しているように見えます。
(Source: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
どのような影響があるのでしょうか？
多くの言語がこの攻撃に脆弱である。C、C++、C#、JavaScript、Java、Rust、Go、Pythonなどで、さらに多くの言語があると考えられます。平均的な開発者は、ソースコードに方向性のあるフォーマット文字を見て眉をひそめるかもしれませんが、初心者は肩をすくめて何も考えないかもしれません。さらに、これらの文字の表示方法はIDEに大きく依存しているため、絶対に見られるとは限りません。
しかし、そもそもこの脆弱性はどのようにしてソースコードに忍び込むことができるのでしょうか。まず第一に、信頼できないソースコードを使用した場合、悪意のあるコードが混入していても気づかないことがあります。第二に、インターネット上で見つけたコードを単純にコピー・ペーストした場合にも起こり得ます。ほとんどの組織は、複数のベンダーのソフトウェアコンポーネントに依存しています。そこで問題となるのが、これらのコードをどこまで完全に信頼できるのかということです。バックドアが隠されているソースコードをどのようにしてスクリーニングすればよいのでしょうか。
それは誰の問題なのか？
一方で、コンパイラやビルドパイプラインは、1つの方向が文字列やコメントに厳密に制限されている場合を除き、複数の方向を持つソースコード行を許可しないようにすべきです。文字列やコメントに含まれる方向性のあるフォーマット文字は、ポップされていなければ、方向性の変更を行の最後まで延長することができることに注意してください。一般に、コードエディターは、同音異義語や方向指示文字などの疑わしいUnicode文字を明示的にレンダリングし、ハイライトする必要があります。11月以降、GitHubでは双方向のユニコードテキストを含むすべてのコード行に警告記号とメッセージを追加するようになりましたが、これらの文字が行のどこにあるかは強調表示されません。これでは、悪意のある方向転換が良性の方向転換と一緒に潜り込んでしまう可能性があります。
開発者やコードレビュー担当者の間での認知度を高めることが重要であることから、この脆弱性を説明するウォークスルーを作成しました。現在、このウォークスルーは、Java、C#、Python、GO、およびPHPで利用可能です。
もっと詳しく知りたい方は、Trojan Sourceのシミュレーション（公開missions ）を試してみたり、Trojan Sourceの研究を読んでみてください。
11月初旬、ケンブリッジ大学は、「 Trojan-Source」と呼ばれる研究結果を発表しました。この研究では、ソースコードやコメントの中に、方向性のある書式文字を使ってバックドアを隠せることに着目しました。これを利用して、人間のコードレビュアーとコンパイラが異なるロジックを解釈するコードを作成することができます。
この脆弱性は新しいものですが、Unicodeは過去にもファイル名の最後の部分の向きを逆にすることでファイルの真の拡張子を隠すなど、悪用されたことがあります。今回の調査では、多くのコンパイラがソースコード中のUnicode文字を警告なしに無視するのに対し、コードエディタを含むテキストエディタでは、コメントやそれに基づくコードを含む行がリフローされてしまうことが判明しました。そのため、エディタはコードやコメントをコンパイラの解析方法とは異なる順序で表示し、コードとコメントが入れ替わることもある。
詳しくはこちらをご覧ください。また、腕まくりをしてトロイの木馬ソースのシミュレーションハッキングを試してみたい方は、無料のパブリックミッションに飛び込んでご自身で体験してみてはいかがでしょうか。
双方向性テキスト
これらのトロイの木馬ソースの攻撃の1つは、英語（左から右）とアラビア語（右から左）のように、表示順序が異なるテキストをどのようにまとめるかを扱うUnicode Bidi（双方向）アルゴリズムを利用しています。方向性のあるフォーマット文字を使用することで、グループ化を再編成し、文字の順序を表示することができます。
上の表には、攻撃に関連するBidiのオーバーライド文字の一部が含まれています。例を挙げてみましょう。
RLIE D O CP D I
RLIという略語は、Right-to-Left Isolateの略です。文脈（PDI、Pop-Directional-Isolateで区切られる）からテキストを分離し、右から左へと読むことになります。結果的には
C O D E
しかし、コンパイラやインタプリタは、ソースコードを解析する前に、Bidiオーバーライドを含むフォーマット制御文字を処理しないのが普通です。単純に方向性のある書式制御文字を無視すれば、解析されてしまうのです。
E D O C
古いワインを新しいボトルで？
もちろん、これは日の目を見ないことです。過去には、ファイル名に方向性のあるフォーマット文字を挿入して、悪意のある性質を偽装したこともあります。メールの添付ファイルが「myspecialexe.doc」と表示されていても、RLO（Right-to-Left override）文字がなければ、本当の名前は「myspecialcod.exe」であることがわかり、無害に見えるかもしれません。
トロイの木馬のソース攻撃では、構文エラーやコンパイルエラーが発生しないように、ソースコードに存在するコメントや文字列に方向性のある書式文字を挿入します。これらの制御文字は、コードのロジックの表示順序を変更し、人間が読むのとは全く異なるものをコンパイラに読ませます。
例えば、次のバイトをこの順番で並べたファイル。
は、方向性のあるフォーマット文字によって、以下のように並び替えられます。
のように表示されることがあります。
RLOは最後の行で、閉じ括弧を開き括弧に反転させ、その逆も行います。このコードを実行した結果は、次のようになります。"You are an admin" です。管理者チェックはコメントアウトされていますが、制御文字はまだ存在しているように見えます。
(Source: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
どのような影響があるのでしょうか？
多くの言語がこの攻撃に脆弱である。C、C++、C#、JavaScript、Java、Rust、Go、Pythonなどで、さらに多くの言語があると考えられます。平均的な開発者は、ソースコードに方向性のあるフォーマット文字を見て眉をひそめるかもしれませんが、初心者は肩をすくめて何も考えないかもしれません。さらに、これらの文字の表示方法はIDEに大きく依存しているため、絶対に見られるとは限りません。
しかし、そもそもこの脆弱性はどのようにしてソースコードに忍び込むことができるのでしょうか。まず第一に、信頼できないソースコードを使用した場合、悪意のあるコードが混入していても気づかないことがあります。第二に、インターネット上で見つけたコードを単純にコピー・ペーストした場合にも起こり得ます。ほとんどの組織は、複数のベンダーのソフトウェアコンポーネントに依存しています。そこで問題となるのが、これらのコードをどこまで完全に信頼できるのかということです。バックドアが隠されているソースコードをどのようにしてスクリーニングすればよいのでしょうか。
それは誰の問題なのか？
一方で、コンパイラやビルドパイプラインは、1つの方向が文字列やコメントに厳密に制限されている場合を除き、複数の方向を持つソースコード行を許可しないようにすべきです。文字列やコメントに含まれる方向性のあるフォーマット文字は、ポップされていなければ、方向性の変更を行の最後まで延長することができることに注意してください。一般に、コードエディターは、同音異義語や方向指示文字などの疑わしいUnicode文字を明示的にレンダリングし、ハイライトする必要があります。11月以降、GitHubでは双方向のユニコードテキストを含むすべてのコード行に警告記号とメッセージを追加するようになりましたが、これらの文字が行のどこにあるかは強調表示されません。これでは、悪意のある方向転換が良性の方向転換と一緒に潜り込んでしまう可能性があります。
開発者やコードレビュー担当者の間での認知度を高めることが重要であることから、この脆弱性を説明するウォークスルーを作成しました。現在、このウォークスルーは、Java、C#、Python、GO、およびPHPで利用可能です。
もっと詳しく知りたい方は、Trojan Sourceのシミュレーション（公開missions ）を試してみたり、Trojan Sourceの研究を読んでみてください。
以下のリンクをクリックし、この資料のPDFをダウンロードしてください。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
レポートを見るデモを予約する
Laura Verheyde はSecure Code Warrior のソフトウェア開発者で、脆弱性のリサーチとMissions および Coding labs のコンテンツ作成に注力している。
11月初旬、ケンブリッジ大学は、「 Trojan-Source」と呼ばれる研究結果を発表しました。この研究では、ソースコードやコメントの中に、方向性のある書式文字を使ってバックドアを隠せることに着目しました。これを利用して、人間のコードレビュアーとコンパイラが異なるロジックを解釈するコードを作成することができます。
この脆弱性は新しいものですが、Unicodeは過去にもファイル名の最後の部分の向きを逆にすることでファイルの真の拡張子を隠すなど、悪用されたことがあります。今回の調査では、多くのコンパイラがソースコード中のUnicode文字を警告なしに無視するのに対し、コードエディタを含むテキストエディタでは、コメントやそれに基づくコードを含む行がリフローされてしまうことが判明しました。そのため、エディタはコードやコメントをコンパイラの解析方法とは異なる順序で表示し、コードとコメントが入れ替わることもある。
詳しくはこちらをご覧ください。また、腕まくりをしてトロイの木馬ソースのシミュレーションハッキングを試してみたい方は、無料のパブリックミッションに飛び込んでご自身で体験してみてはいかがでしょうか。
双方向性テキスト
これらのトロイの木馬ソースの攻撃の1つは、英語（左から右）とアラビア語（右から左）のように、表示順序が異なるテキストをどのようにまとめるかを扱うUnicode Bidi（双方向）アルゴリズムを利用しています。方向性のあるフォーマット文字を使用することで、グループ化を再編成し、文字の順序を表示することができます。
上の表には、攻撃に関連するBidiのオーバーライド文字の一部が含まれています。例を挙げてみましょう。
RLIE D O CP D I
RLIという略語は、Right-to-Left Isolateの略です。文脈（PDI、Pop-Directional-Isolateで区切られる）からテキストを分離し、右から左へと読むことになります。結果的には
C O D E
しかし、コンパイラやインタプリタは、ソースコードを解析する前に、Bidiオーバーライドを含むフォーマット制御文字を処理しないのが普通です。単純に方向性のある書式制御文字を無視すれば、解析されてしまうのです。
E D O C
古いワインを新しいボトルで？
もちろん、これは日の目を見ないことです。過去には、ファイル名に方向性のあるフォーマット文字を挿入して、悪意のある性質を偽装したこともあります。メールの添付ファイルが「myspecialexe.doc」と表示されていても、RLO（Right-to-Left override）文字がなければ、本当の名前は「myspecialcod.exe」であることがわかり、無害に見えるかもしれません。
トロイの木馬のソース攻撃では、構文エラーやコンパイルエラーが発生しないように、ソースコードに存在するコメントや文字列に方向性のある書式文字を挿入します。これらの制御文字は、コードのロジックの表示順序を変更し、人間が読むのとは全く異なるものをコンパイラに読ませます。
例えば、次のバイトをこの順番で並べたファイル。
は、方向性のあるフォーマット文字によって、以下のように並び替えられます。
のように表示されることがあります。
RLOは最後の行で、閉じ括弧を開き括弧に反転させ、その逆も行います。このコードを実行した結果は、次のようになります。"You are an admin" です。管理者チェックはコメントアウトされていますが、制御文字はまだ存在しているように見えます。
(Source: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
どのような影響があるのでしょうか？
多くの言語がこの攻撃に脆弱である。C、C++、C#、JavaScript、Java、Rust、Go、Pythonなどで、さらに多くの言語があると考えられます。平均的な開発者は、ソースコードに方向性のあるフォーマット文字を見て眉をひそめるかもしれませんが、初心者は肩をすくめて何も考えないかもしれません。さらに、これらの文字の表示方法はIDEに大きく依存しているため、絶対に見られるとは限りません。
しかし、そもそもこの脆弱性はどのようにしてソースコードに忍び込むことができるのでしょうか。まず第一に、信頼できないソースコードを使用した場合、悪意のあるコードが混入していても気づかないことがあります。第二に、インターネット上で見つけたコードを単純にコピー・ペーストした場合にも起こり得ます。ほとんどの組織は、複数のベンダーのソフトウェアコンポーネントに依存しています。そこで問題となるのが、これらのコードをどこまで完全に信頼できるのかということです。バックドアが隠されているソースコードをどのようにしてスクリーニングすればよいのでしょうか。
それは誰の問題なのか？
一方で、コンパイラやビルドパイプラインは、1つの方向が文字列やコメントに厳密に制限されている場合を除き、複数の方向を持つソースコード行を許可しないようにすべきです。文字列やコメントに含まれる方向性のあるフォーマット文字は、ポップされていなければ、方向性の変更を行の最後まで延長することができることに注意してください。一般に、コードエディターは、同音異義語や方向指示文字などの疑わしいUnicode文字を明示的にレンダリングし、ハイライトする必要があります。11月以降、GitHubでは双方向のユニコードテキストを含むすべてのコード行に警告記号とメッセージを追加するようになりましたが、これらの文字が行のどこにあるかは強調表示されません。これでは、悪意のある方向転換が良性の方向転換と一緒に潜り込んでしまう可能性があります。
開発者やコードレビュー担当者の間での認知度を高めることが重要であることから、この脆弱性を説明するウォークスルーを作成しました。現在、このウォークスルーは、Java、C#、Python、GO、およびPHPで利用可能です。
もっと詳しく知りたい方は、Trojan Sourceのシミュレーション（公開missions ）を試してみたり、Trojan Sourceの研究を読んでみてください。
始めるためのリソース
セキュア・バイ・デザインベストプラクティスの定義、開発者の能力向上、予防的セキュリティ成果のベンチマーク
このリサーチペーパーでは、Secure Code Warrior 共同設立者であるピーテル・ダニュー（Pieter Danhieux）氏とマティアス・マドゥ（Matias Madou）博士、そして専門家であるクリス・イングリス（Chris Inglis）氏（元米国サイバーディレクター、現パラディン・キャピタル・グループ戦略顧問）、デヴィン・リンチ（Devin Lynch）氏（パラディン・グローバル・インスティテュート・シニアディレクター）が、CISO、アプリケーション・セキュリティ担当副社長、ソフトウェア・セキュリティの専門家など、企業のセキュリティ・リーダー20人以上への詳細なインタビューから得られた主な知見を明らかにします。
セキュリティ スキルのベンチマーク: 企業におけるセキュアな設計の合理化
セキュアバイデザイン（SBD）構想の成功に関する有意義なデータを見つけることは、非常に困難である。CISO は、セキュリティプログラム活動の投資収益率（ROI）とビジネス価値を、従業員レベルと企業レベルの両方で証明しようとすると、しばしば困難に直面します。言うまでもなく、企業にとって、現在の業界標準に対して自社の組織がどのようにベンチマークされているかを把握することは特に困難です。大統領の国家サイバーセキュリティ戦略は、関係者に「デザインによるセキュリティとレジリエンスを受け入れる」ことを求めている。セキュアバイデザインの取り組みを成功させる鍵は、開発者にセキュアなコードを保証するスキルを与えるだけでなく、規制当局にそれらのスキルが整っていることを保証することである。本プレゼンテーションでは、25万人以上の開発者から収集した社内データ、データに基づく顧客の洞察、公的研究など、複数の一次ソースから得られた無数の定性的・定量的データを紹介します。こうしたデータ・ポイントの集積を活用することで、複数の業種におけるセキュア・バイ・デザイン・イニシアチブの現状をお伝えすることを目的としています。本レポートでは、この領域が現在十分に活用されていない理由、スキルアッププログラムの成功がサイバーセキュリティのリスク軽減に与える大きな影響、コードベースから脆弱性のカテゴリーを排除できる可能性について詳述しています。
始めるためのリソース
明らかになった：サイバー業界はセキュア・バイ・デザインをどのように定義しているか
最新のホワイトペーパーでは、当社の共同設立者であるピーテル・ダニュー（Pieter Danhieux）氏とマティアス・マドゥ（Matias Madou）博士が、CISO、AppSecリーダー、セキュリティ専門家を含む20人以上の企業セキュリティリーダーと対談し、このパズルの重要なピースを見つけ出し、Secure by Design運動の背後にある現実を明らかにしました。セキュア・バイ・デザインは、セキュリティ・チーム全体で共有された野心ですが、共有されたプレイブックはありません。
