Coders Conquer Security:シェアして学ぶシリーズ - パディング・オラクル
パディング・オラクルは、オルタナティブ・ロック・バンドの悪い名前のように聞こえますが、実際には、攻撃者が暗号化キーを知らずに情報を解読するために使用できる脆弱性です。
攻撃者にとっての全体的な難易度という意味では、この問題は最上位に近いものです。魔法のような復号化ボタンではなく、ハッカーは、送られてきたセルのパディングに関するエラーメッセージを調べ、暗号化されたデータがどこで終わり、パディングが始まるのかを判断するために、手間のかかる作業を行います。そして、暗号化されたデータの中のさまざまなビットを見つけ出し、十分な時間と情報があれば解読できるかもしれません。
ありがたいことに、比較的簡単な手順で、攻撃者がパディング・オラクルを使って暗号化されたデータを解読する能力を取り除くことができます。このエピソードでは、次のことを学びます。
- その仕組み
- なぜこの脆弱性が危険なのか
- それを防ぐために、どのような防御策を講じることができるのか。
Padding Oracleの仕組みは？
CBC（Cipher Block Chaining）とは、データベースに保存されているセルなどの一連の情報全体を、その情報の連鎖全体に適用される暗号鍵を用いて暗号化するブロック暗号の作成方法です。CBCを使用した場合、1つの暗号文ブロックの暗号化は、それ以降のすべてのブロックに依存します。理論的には、ブロックの順序を変えただけでもデータが破壊されてしまうため、非常に強力な暗号化となります。
CBC暗号（およびその他のブロック暗号）の問題点は、正確なサイズのブロックを使ってしか暗号化できないことです。通常、暗号化は8バイトまたは16バイトのサイズで行われます。では、CBCが2バイトのデータを16バイトの暗号文単位に収める必要がある場合はどうなるでしょうか。CBCは、パディング（基本的には無意味な文字）を使って隙間を埋め、適切なサイズのユニットを作ります。
ほとんどのパディング方式はよく知られており、その中でもPKCS#7は最もよく知られている方式の一つです。そのため、攻撃者はどのようなパディングが使用されているかを知っているかもしれません。例えば、CBCがブロック内の5文字をパディングする必要がある場合、PKCS#7では、平文の後に0x05というバイト値を5回繰り返す。
攻撃者は、CBCとパディング方式に関する知識を利用して、ホストサーバ（オラクルとも呼ばれる）にクエリを送信します。適切なツールにアクセスできれば、クエリのパディングが間違っているかどうかをサーバに教えさせることができるかもしれません。そのためには、パディングが正しいとサーバーから言われるまで、暗号の各バイトを0から255まで循環させます。そして、次のユニットに移動してこのプロセスを繰り返し、すべてのケースでパディングがどこから始まるかを記録するのです。
この方法では、メッセージやセルを解読することはできませんが、平文がどこで終わり、パディングがどこで始まるのかという点で、チェーンのすべてのリンクをマッピングすることができます。また、XOR計算を使って、元の平文の最後のバイトの値を把握できる可能性もあります。
Padding Oracleはなぜ危険なのか？
ハッカーが暗号化の解除に多大な労力を費やす理由は、潜在的な報酬があるからです。価値のないものを暗号化する人はほとんどいません。ホスト組織にとっての危険度は、侵害されるデータによって異なります。例えば、パスワード、ユーザーアカウント、財務情報、クレジットカード番号、患者の記録、機密通信など、非常に求められている貴重な情報が含まれています。
パディング・オラクルを使うことは、その後の攻撃の入り口にもなります。例えば、攻撃者がパディング・オラクルを使ってパスワードを盗むことができれば、権限を昇格させてネットワークの奥深くに侵入することは簡単な二次的作業となります。
誰もが暗号化を、盗聴や漏洩に対する究極の防御と考えています。しかし、暗号化の科学と、それを破ろうとする者との間には、何世紀にもわたって一進一退の攻防が繰り広げられてきました。パディング・オラクルは、攻撃者に有利な方法の1つに過ぎません。
パディングオラクル攻撃のハードランディング化
ありがたいことに、パディング・オラクルを防ぐ方法はいくつかあります。その一つは、ガロア/カウンタモード（GCM）やオフセットコードブックモード（OCB）など、より強力な暗号化演算モードを使用することです。GCMは、CBCとは異なり、128ビットの暗号ブロックサイズを使用しています。CBCとの違いは、暗号ブロックサイズが128ビットであることと、データブロックごとにカウンターを使用し、その数字を使って暗号文を作成することです。つまり、パディング・オラクル攻撃の影響を受けないというわけだ。
優れたエラー処理制御を実装することで、攻撃者が成功する可能性を大きく減らすことができます。パディング・オラクル攻撃は情報漏洩に依存しているため、暗号化/復号化の失敗時には特定のパディングエラーではなく、一般的なエラーメッセージを返すようにしてください。
また、メッセージ認証コード（MAC）を実装することもできます。MAC値は、検証者が秘密鍵を使ってメッセージ内容の変更を検出することで、データの完全性と真正性を保護します。
最後に、すべてのパディング・オラクル攻撃は、繰り返しクエリを必要とします。1つのセルのパディング方式を知るためには、チェーンで保護されている情報のユニット数を掛け合わせた200以上のリクエストが必要になります。同一ソースからのリクエスト数を制限することで、攻撃者が実際に攻撃を開始する前にアクセスを拒否することで、パディング・オラクル攻撃をシャットアウトすることができます。
パディングオラクルのさらなる研究
攻撃者が機密情報を解読する方法は、本当に悪夢のようなものです。しかし、そのような事態を未然に防ぐための良い方法がいくつかわかったのではないでしょうか。
さらに読みたい方は、パディング・オラクルのOWASP定義とチェックリストをご覧ください。また、サイバーセキュリティチームを究極のサイバー戦士へと育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御知識を試すこともできます。この脆弱性やその他の脅威の対策についての詳細は、Secure Code Warrior ブログをご覧ください。
今すぐ、パディング・オラクルの攻撃を阻止することができると思いますか？Secure Code Warrior のプラットフォームで試してみてください。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
デモを予約する
パディング・オラクルは、オルタナティブ・ロック・バンドの悪い名前のように聞こえますが、実際には、攻撃者が暗号化キーを知らずに情報を解読するために使用できる脆弱性です。
攻撃者にとっての全体的な難易度という意味では、この問題は最上位に近いものです。魔法のような復号化ボタンではなく、ハッカーは、送られてきたセルのパディングに関するエラーメッセージを調べ、暗号化されたデータがどこで終わり、パディングが始まるのかを判断するために、手間のかかる作業を行います。そして、暗号化されたデータの中のさまざまなビットを見つけ出し、十分な時間と情報があれば解読できるかもしれません。
ありがたいことに、比較的簡単な手順で、攻撃者がパディング・オラクルを使って暗号化されたデータを解読する能力を取り除くことができます。このエピソードでは、次のことを学びます。
- その仕組み
- なぜこの脆弱性が危険なのか
- それを防ぐために、どのような防御策を講じることができるのか。
Padding Oracleの仕組みは？
CBC（Cipher Block Chaining）とは、データベースに保存されているセルなどの一連の情報全体を、その情報の連鎖全体に適用される暗号鍵を用いて暗号化するブロック暗号の作成方法です。CBCを使用した場合、1つの暗号文ブロックの暗号化は、それ以降のすべてのブロックに依存します。理論的には、ブロックの順序を変えただけでもデータが破壊されてしまうため、非常に強力な暗号化となります。
CBC暗号（およびその他のブロック暗号）の問題点は、正確なサイズのブロックを使ってしか暗号化できないことです。通常、暗号化は8バイトまたは16バイトのサイズで行われます。では、CBCが2バイトのデータを16バイトの暗号文単位に収める必要がある場合はどうなるでしょうか。CBCは、パディング（基本的には無意味な文字）を使って隙間を埋め、適切なサイズのユニットを作ります。
ほとんどのパディング方式はよく知られており、その中でもPKCS#7は最もよく知られている方式の一つです。そのため、攻撃者はどのようなパディングが使用されているかを知っているかもしれません。例えば、CBCがブロック内の5文字をパディングする必要がある場合、PKCS#7では、平文の後に0x05というバイト値を5回繰り返す。
攻撃者は、CBCとパディング方式に関する知識を利用して、ホストサーバ（オラクルとも呼ばれる）にクエリを送信します。適切なツールにアクセスできれば、クエリのパディングが間違っているかどうかをサーバに教えさせることができるかもしれません。そのためには、パディングが正しいとサーバーから言われるまで、暗号の各バイトを0から255まで循環させます。そして、次のユニットに移動してこのプロセスを繰り返し、すべてのケースでパディングがどこから始まるかを記録するのです。
この方法では、メッセージやセルを解読することはできませんが、平文がどこで終わり、パディングがどこで始まるのかという点で、チェーンのすべてのリンクをマッピングすることができます。また、XOR計算を使って、元の平文の最後のバイトの値を把握できる可能性もあります。
Padding Oracleはなぜ危険なのか？
ハッカーが暗号化の解除に多大な労力を費やす理由は、潜在的な報酬があるからです。価値のないものを暗号化する人はほとんどいません。ホスト組織にとっての危険度は、侵害されるデータによって異なります。例えば、パスワード、ユーザーアカウント、財務情報、クレジットカード番号、患者の記録、機密通信など、非常に求められている貴重な情報が含まれています。
パディング・オラクルを使うことは、その後の攻撃の入り口にもなります。例えば、攻撃者がパディング・オラクルを使ってパスワードを盗むことができれば、権限を昇格させてネットワークの奥深くに侵入することは簡単な二次的作業となります。
誰もが暗号化を、盗聴や漏洩に対する究極の防御と考えています。しかし、暗号化の科学と、それを破ろうとする者との間には、何世紀にもわたって一進一退の攻防が繰り広げられてきました。パディング・オラクルは、攻撃者に有利な方法の1つに過ぎません。
パディングオラクル攻撃のハードランディング化
ありがたいことに、パディング・オラクルを防ぐ方法はいくつかあります。その一つは、ガロア/カウンタモード（GCM）やオフセットコードブックモード（OCB）など、より強力な暗号化演算モードを使用することです。GCMは、CBCとは異なり、128ビットの暗号ブロックサイズを使用しています。CBCとの違いは、暗号ブロックサイズが128ビットであることと、データブロックごとにカウンターを使用し、その数字を使って暗号文を作成することです。つまり、パディング・オラクル攻撃の影響を受けないというわけだ。
優れたエラー処理制御を実装することで、攻撃者が成功する可能性を大きく減らすことができます。パディング・オラクル攻撃は情報漏洩に依存しているため、暗号化/復号化の失敗時には特定のパディングエラーではなく、一般的なエラーメッセージを返すようにしてください。
また、メッセージ認証コード（MAC）を実装することもできます。MAC値は、検証者が秘密鍵を使ってメッセージ内容の変更を検出することで、データの完全性と真正性を保護します。
最後に、すべてのパディング・オラクル攻撃は、繰り返しクエリを必要とします。1つのセルのパディング方式を知るためには、チェーンで保護されている情報のユニット数を掛け合わせた200以上のリクエストが必要になります。同一ソースからのリクエスト数を制限することで、攻撃者が実際に攻撃を開始する前にアクセスを拒否することで、パディング・オラクル攻撃をシャットアウトすることができます。
パディングオラクルのさらなる研究
攻撃者が機密情報を解読する方法は、本当に悪夢のようなものです。しかし、そのような事態を未然に防ぐための良い方法がいくつかわかったのではないでしょうか。
さらに読みたい方は、パディング・オラクルのOWASP定義とチェックリストをご覧ください。また、サイバーセキュリティチームを究極のサイバー戦士へと育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御知識を試すこともできます。この脆弱性やその他の脅威の対策についての詳細は、Secure Code Warrior ブログをご覧ください。
今すぐ、パディング・オラクルの攻撃を阻止することができると思いますか？Secure Code Warrior のプラットフォームで試してみてください。
パディング・オラクルは、オルタナティブ・ロック・バンドの悪い名前のように聞こえますが、実際には、攻撃者が暗号化キーを知らずに情報を解読するために使用できる脆弱性です。
攻撃者にとっての全体的な難易度という意味では、この問題は最上位に近いものです。魔法のような復号化ボタンではなく、ハッカーは、送られてきたセルのパディングに関するエラーメッセージを調べ、暗号化されたデータがどこで終わり、パディングが始まるのかを判断するために、手間のかかる作業を行います。そして、暗号化されたデータの中のさまざまなビットを見つけ出し、十分な時間と情報があれば解読できるかもしれません。
ありがたいことに、比較的簡単な手順で、攻撃者がパディング・オラクルを使って暗号化されたデータを解読する能力を取り除くことができます。このエピソードでは、次のことを学びます。
- その仕組み
- なぜこの脆弱性が危険なのか
- それを防ぐために、どのような防御策を講じることができるのか。
Padding Oracleの仕組みは？
CBC（Cipher Block Chaining）とは、データベースに保存されているセルなどの一連の情報全体を、その情報の連鎖全体に適用される暗号鍵を用いて暗号化するブロック暗号の作成方法です。CBCを使用した場合、1つの暗号文ブロックの暗号化は、それ以降のすべてのブロックに依存します。理論的には、ブロックの順序を変えただけでもデータが破壊されてしまうため、非常に強力な暗号化となります。
CBC暗号（およびその他のブロック暗号）の問題点は、正確なサイズのブロックを使ってしか暗号化できないことです。通常、暗号化は8バイトまたは16バイトのサイズで行われます。では、CBCが2バイトのデータを16バイトの暗号文単位に収める必要がある場合はどうなるでしょうか。CBCは、パディング（基本的には無意味な文字）を使って隙間を埋め、適切なサイズのユニットを作ります。
ほとんどのパディング方式はよく知られており、その中でもPKCS#7は最もよく知られている方式の一つです。そのため、攻撃者はどのようなパディングが使用されているかを知っているかもしれません。例えば、CBCがブロック内の5文字をパディングする必要がある場合、PKCS#7では、平文の後に0x05というバイト値を5回繰り返す。
攻撃者は、CBCとパディング方式に関する知識を利用して、ホストサーバ（オラクルとも呼ばれる）にクエリを送信します。適切なツールにアクセスできれば、クエリのパディングが間違っているかどうかをサーバに教えさせることができるかもしれません。そのためには、パディングが正しいとサーバーから言われるまで、暗号の各バイトを0から255まで循環させます。そして、次のユニットに移動してこのプロセスを繰り返し、すべてのケースでパディングがどこから始まるかを記録するのです。
この方法では、メッセージやセルを解読することはできませんが、平文がどこで終わり、パディングがどこで始まるのかという点で、チェーンのすべてのリンクをマッピングすることができます。また、XOR計算を使って、元の平文の最後のバイトの値を把握できる可能性もあります。
Padding Oracleはなぜ危険なのか？
ハッカーが暗号化の解除に多大な労力を費やす理由は、潜在的な報酬があるからです。価値のないものを暗号化する人はほとんどいません。ホスト組織にとっての危険度は、侵害されるデータによって異なります。例えば、パスワード、ユーザーアカウント、財務情報、クレジットカード番号、患者の記録、機密通信など、非常に求められている貴重な情報が含まれています。
パディング・オラクルを使うことは、その後の攻撃の入り口にもなります。例えば、攻撃者がパディング・オラクルを使ってパスワードを盗むことができれば、権限を昇格させてネットワークの奥深くに侵入することは簡単な二次的作業となります。
誰もが暗号化を、盗聴や漏洩に対する究極の防御と考えています。しかし、暗号化の科学と、それを破ろうとする者との間には、何世紀にもわたって一進一退の攻防が繰り広げられてきました。パディング・オラクルは、攻撃者に有利な方法の1つに過ぎません。
パディングオラクル攻撃のハードランディング化
ありがたいことに、パディング・オラクルを防ぐ方法はいくつかあります。その一つは、ガロア/カウンタモード（GCM）やオフセットコードブックモード（OCB）など、より強力な暗号化演算モードを使用することです。GCMは、CBCとは異なり、128ビットの暗号ブロックサイズを使用しています。CBCとの違いは、暗号ブロックサイズが128ビットであることと、データブロックごとにカウンターを使用し、その数字を使って暗号文を作成することです。つまり、パディング・オラクル攻撃の影響を受けないというわけだ。
優れたエラー処理制御を実装することで、攻撃者が成功する可能性を大きく減らすことができます。パディング・オラクル攻撃は情報漏洩に依存しているため、暗号化/復号化の失敗時には特定のパディングエラーではなく、一般的なエラーメッセージを返すようにしてください。
また、メッセージ認証コード（MAC）を実装することもできます。MAC値は、検証者が秘密鍵を使ってメッセージ内容の変更を検出することで、データの完全性と真正性を保護します。
最後に、すべてのパディング・オラクル攻撃は、繰り返しクエリを必要とします。1つのセルのパディング方式を知るためには、チェーンで保護されている情報のユニット数を掛け合わせた200以上のリクエストが必要になります。同一ソースからのリクエスト数を制限することで、攻撃者が実際に攻撃を開始する前にアクセスを拒否することで、パディング・オラクル攻撃をシャットアウトすることができます。
パディングオラクルのさらなる研究
攻撃者が機密情報を解読する方法は、本当に悪夢のようなものです。しかし、そのような事態を未然に防ぐための良い方法がいくつかわかったのではないでしょうか。
さらに読みたい方は、パディング・オラクルのOWASP定義とチェックリストをご覧ください。また、サイバーセキュリティチームを究極のサイバー戦士へと育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御知識を試すこともできます。この脆弱性やその他の脅威の対策についての詳細は、Secure Code Warrior ブログをご覧ください。
今すぐ、パディング・オラクルの攻撃を阻止することができると思いますか？Secure Code Warrior のプラットフォームで試してみてください。
パディング・オラクルは、オルタナティブ・ロック・バンドの悪い名前のように聞こえますが、実際には、攻撃者が暗号化キーを知らずに情報を解読するために使用できる脆弱性です。
攻撃者にとっての全体的な難易度という意味では、この問題は最上位に近いものです。魔法のような復号化ボタンではなく、ハッカーは、送られてきたセルのパディングに関するエラーメッセージを調べ、暗号化されたデータがどこで終わり、パディングが始まるのかを判断するために、手間のかかる作業を行います。そして、暗号化されたデータの中のさまざまなビットを見つけ出し、十分な時間と情報があれば解読できるかもしれません。
ありがたいことに、比較的簡単な手順で、攻撃者がパディング・オラクルを使って暗号化されたデータを解読する能力を取り除くことができます。このエピソードでは、次のことを学びます。
- その仕組み
- なぜこの脆弱性が危険なのか
- それを防ぐために、どのような防御策を講じることができるのか。
Padding Oracleの仕組みは？
CBC（Cipher Block Chaining）とは、データベースに保存されているセルなどの一連の情報全体を、その情報の連鎖全体に適用される暗号鍵を用いて暗号化するブロック暗号の作成方法です。CBCを使用した場合、1つの暗号文ブロックの暗号化は、それ以降のすべてのブロックに依存します。理論的には、ブロックの順序を変えただけでもデータが破壊されてしまうため、非常に強力な暗号化となります。
CBC暗号（およびその他のブロック暗号）の問題点は、正確なサイズのブロックを使ってしか暗号化できないことです。通常、暗号化は8バイトまたは16バイトのサイズで行われます。では、CBCが2バイトのデータを16バイトの暗号文単位に収める必要がある場合はどうなるでしょうか。CBCは、パディング（基本的には無意味な文字）を使って隙間を埋め、適切なサイズのユニットを作ります。
ほとんどのパディング方式はよく知られており、その中でもPKCS#7は最もよく知られている方式の一つです。そのため、攻撃者はどのようなパディングが使用されているかを知っているかもしれません。例えば、CBCがブロック内の5文字をパディングする必要がある場合、PKCS#7では、平文の後に0x05というバイト値を5回繰り返す。
攻撃者は、CBCとパディング方式に関する知識を利用して、ホストサーバ（オラクルとも呼ばれる）にクエリを送信します。適切なツールにアクセスできれば、クエリのパディングが間違っているかどうかをサーバに教えさせることができるかもしれません。そのためには、パディングが正しいとサーバーから言われるまで、暗号の各バイトを0から255まで循環させます。そして、次のユニットに移動してこのプロセスを繰り返し、すべてのケースでパディングがどこから始まるかを記録するのです。
この方法では、メッセージやセルを解読することはできませんが、平文がどこで終わり、パディングがどこで始まるのかという点で、チェーンのすべてのリンクをマッピングすることができます。また、XOR計算を使って、元の平文の最後のバイトの値を把握できる可能性もあります。
Padding Oracleはなぜ危険なのか？
ハッカーが暗号化の解除に多大な労力を費やす理由は、潜在的な報酬があるからです。価値のないものを暗号化する人はほとんどいません。ホスト組織にとっての危険度は、侵害されるデータによって異なります。例えば、パスワード、ユーザーアカウント、財務情報、クレジットカード番号、患者の記録、機密通信など、非常に求められている貴重な情報が含まれています。
パディング・オラクルを使うことは、その後の攻撃の入り口にもなります。例えば、攻撃者がパディング・オラクルを使ってパスワードを盗むことができれば、権限を昇格させてネットワークの奥深くに侵入することは簡単な二次的作業となります。
誰もが暗号化を、盗聴や漏洩に対する究極の防御と考えています。しかし、暗号化の科学と、それを破ろうとする者との間には、何世紀にもわたって一進一退の攻防が繰り広げられてきました。パディング・オラクルは、攻撃者に有利な方法の1つに過ぎません。
パディングオラクル攻撃のハードランディング化
ありがたいことに、パディング・オラクルを防ぐ方法はいくつかあります。その一つは、ガロア/カウンタモード（GCM）やオフセットコードブックモード（OCB）など、より強力な暗号化演算モードを使用することです。GCMは、CBCとは異なり、128ビットの暗号ブロックサイズを使用しています。CBCとの違いは、暗号ブロックサイズが128ビットであることと、データブロックごとにカウンターを使用し、その数字を使って暗号文を作成することです。つまり、パディング・オラクル攻撃の影響を受けないというわけだ。
優れたエラー処理制御を実装することで、攻撃者が成功する可能性を大きく減らすことができます。パディング・オラクル攻撃は情報漏洩に依存しているため、暗号化/復号化の失敗時には特定のパディングエラーではなく、一般的なエラーメッセージを返すようにしてください。
また、メッセージ認証コード（MAC）を実装することもできます。MAC値は、検証者が秘密鍵を使ってメッセージ内容の変更を検出することで、データの完全性と真正性を保護します。
最後に、すべてのパディング・オラクル攻撃は、繰り返しクエリを必要とします。1つのセルのパディング方式を知るためには、チェーンで保護されている情報のユニット数を掛け合わせた200以上のリクエストが必要になります。同一ソースからのリクエスト数を制限することで、攻撃者が実際に攻撃を開始する前にアクセスを拒否することで、パディング・オラクル攻撃をシャットアウトすることができます。
パディングオラクルのさらなる研究
攻撃者が機密情報を解読する方法は、本当に悪夢のようなものです。しかし、そのような事態を未然に防ぐための良い方法がいくつかわかったのではないでしょうか。
さらに読みたい方は、パディング・オラクルのOWASP定義とチェックリストをご覧ください。また、サイバーセキュリティチームを究極のサイバー戦士へと育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御知識を試すこともできます。この脆弱性やその他の脅威の対策についての詳細は、Secure Code Warrior ブログをご覧ください。
今すぐ、パディング・オラクルの攻撃を阻止することができると思いますか？Secure Code Warrior のプラットフォームで試してみてください。
始めるためのリソース
Trust Agent:AI - Secure and scale AI-Drive development
AI is writing code. Who’s governing it? With up to 50% of AI-generated code containing security weaknesses, managing AI risk is critical. Discover how SCW's Trust Agent: AI provides the real-time visibility, proactive governance, and targeted upskilling needed to scale AI-driven development securely.
OpenText アプリケーションセキュリティのパワー + Secure Code Warrior
OpenText Application Security and Secure Code Warrior combine vulnerability detection with AI Software Governance and developer capability. Together, they help organizations reduce risk, strengthen secure coding practices, and confidently adopt AI-driven development.
Secure Code Warrior corporate overview
Secure Code Warrior is an AI Software Governance platform designed to enable organizations to safely adopt AI-driven development by bridging the gap between development velocity and enterprise security. The platform addresses the "Visibility Gap," where security teams often lack insights into shadow AI coding tools and the origins of production code.
セキュアコード・トレーニングのトピックと内容
Our industry-leading content is always evolving to fit the ever changing software development landscape with your role in mind. Topics covering everything from AI to XQuery Injection, offered for a variety of roles from Architects and Engineers to Product Managers and QA. Get a sneak peek of what our content catalog has to offer by topic and role.
始めるためのリソース
.png)
Observe and Secure the ADLC: A Four-Point Framework for CISOs and Development Teams Using AI
While development teams look to make the most of GenAI’s undeniable benefits, we’d like to propose a four-point foundational framework that will allow security leaders to deploy AI coding tools and agents with a higher, more relevant standard of security best practices. It details exactly what enterprises can do to ensure safe, secure code development right now, and as agentic AI becomes an even bigger factor in the future.