Coders Conquer Security:シェア＆ラーンシリーズ - 情報公開
"Loose lips sink ships"という言葉は、第二次世界大戦中のアメリカで流行した言葉です。イギリスでは、"Careless talk costs lives "という言葉があった。この言葉の要点は、機密情報を不用意に話すとスパイに聞かれて大変なことになるということである。
ウェブアプリケーションを構築する際にも、同じ原理が当てはまります。ウェブアプリケーションがあまりにも多くの情報を公開してしまうと、攻撃者が侵入しやすくなってしまいます。
この記事では、情報漏洩とは何か、なぜ危険なのか、どうすれば防げるのかを説明します。
情報露出の把握
情報漏洩とは、ウェブアプリケーションが内部情報を見るべきではない人に公開することを指します。また、ログファイルやユーザーインターフェイスを通じて、顧客の機密情報を公開することもあります。いずれにしても、攻撃者は見つけた情報を使って、システムやユーザーを攻撃することができます。
多くの場合、攻撃者の最初のステップは、アプリケーション内でエラーを発生させようとすることです。エラー処理やウェブアプリケーションの設定が不十分だと、エラーメッセージによる情報漏洩につながります。攻撃者がアプリケーション内でエラーを作成した場合、何が起こるでしょうか？スタックトレースのような技術的な詳細を含む技術的なエラーメッセージが表示された場合、あなたはあまりにも多くの情報を公開しています。これらの詳細には、使用しているデータベースや、実行しているアプリケーションサーバのバージョンなどが含まれます。
機密情報の漏洩は、他の方法でも起こりえます。フォームの隠しフィールドに機密情報が入っていませんか？攻撃者は、ページのソースを見るだけで、値を見ることができます。
一言で言えば、情報漏洩とは、ユーザーが知る必要のある情報が簡単にアクセスできてしまうことです。
情報漏洩の危険性を理解する
アプリケーションで公開された情報を使って、攻撃者は何ができるか？その情報が機密性の高いものであれば、攻撃者はIDやユーザー認証情報を盗むことができます。これにより、金銭的損害、プライバシー侵害、規制当局からの罰金につながる可能性があります。
攻撃者がエラーメッセージを使用してアプリケーションに関する情報を得た場合、その情報は将来の攻撃に使用される可能性があります。実際、OWASP テストガイドには、情報収集に関するセクションがあります。
OWASP テスティングガイドでは、あなたが意図していないようなあなたのウェブサイトに関する情報を見つけるために、 検索エンジンを使うことを推奨しています。例えば、あなたの管理ページは、検索エンジンにさらされていませんか？robots.txt ファイルを使用して、特定のページをインデックスしないように検索エンジンに指示してください。一方で、robots.txtファイルは情報を漏らすこともあります。機密性の高いURLがrobots.txtファイルに存在していることがあります。攻撃者は、このファイルを引き下げて、サイトのディレクトリ構造の一部を学び始めます。
Google has advanced search engine options which allow deep inspection of websites. For example, you can search on a specific site using the "site: <domain>" syntax. You can view cached pages which may have been deleted but still reside in a cache from a previous indexing job. Using different search engines, such as Bing and DuckDuckGo may yield different results, so test on each search engine what is revealed about your web application.</domain>
HTTPヘッダ、ウェブサイトのバナー、さらにはHTMLやJavaScriptコード内のコメントには、攻撃者が見るべきでない情報が含まれている可能性があります。HTTPヘッダには、アプリケーションサーバやバージョン番号が含まれています。攻撃者はこの情報を利用して、特定のバージョンに対して使用するエクスプロイトを見つけることができます。攻撃者が情報を見つける可能性のあるさまざまな場所を理解し、それを適切に隠す方法を確認してください。
情報露出をなくす
情報漏洩は、ウェブアプリケーションの設定でしばしば問題になります。多くのアプリケーション・サーバは、デフォルトでエラーメッセージにスタック・トレースを返します。トラブルシューティングのためにエラーを記録しながら、一般的なエラーページにリダイレクトするよう、本番アプリケーションでは必ずこの設定を変更してください。詳細なエラーメッセージをユーザのブラウザに返してはいけません。
アプリケーションに必要なファイルの中に機密情報が含まれている場合は、適切なアクセスコントロールにより、アプリケーション自身しか読めないようにしてください。サーバのディレクトリ・リスティングを無効にして、これらのファイルをウェブ・ルート・ディレクトリの外に移動します。これにより、攻撃者がブラウザを使ってディレクトリトラバーサル攻撃でファイルに移動することを防ぐことができます。
ログは、正しく設定されていない場合、情報収集に使用されることがあります。エラーが発生した場合、パスワード、セッショントークン、個人識別情報（PII）などの機密情報をログに記録しないようにしてください。攻撃者がログファイルにアクセスできるようになれば、機密情報を盗むための宝の山を見つけることになります。通常は、アカウント識別子、詳細なエラーメッセージ、エラーが発生した方法や実行された操作など、必要以上の情報を記録しないようにしましょう。ログファイルは秘密のものではないと考え、その中に機密情報を入れようとは思わないようにしましょう。
ウェブアプリを沈めないために
第二次世界大戦で戦艦の損失に直結するような情報を、友人との会話中に漏らしてしまったことがあるだろうか。そうではないかもしれない。しかし、なぜそのようなリスクを冒すのでしょうか？それが、"Loose lips sink ships "ということわざの教訓です。
同様に、ウェブアプリケーションの内部構造を外部に公開する理由はありません。クレジットカードの番号やパスワードを丸ごと閲覧する理由はありません。PIIデータをログファイルに保存する理由もありません。ですから、やめておきましょう。情報公開についての詳細は、ラーニングリソースをご覧ください。
アプリケーションの内部構造を、本来あるべき場所に保持します。Webアプリケーションを沈めないでください。
今すぐにでも、情報漏洩に歯止めをかけることができると思いませんか？挑戦してみよう、戦士よ。[ここからスタート]
Jaap Karan Singhは、Secure Coding Evangelistであり、Chief Singhであり、Secure Code Warrior の共同設立者です。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
デモを予約する
Jaap Karan Singhは、Secure Coding Evangelistであり、Chief Singhであり、Secure Code Warrior の共同設立者です。
"Loose lips sink ships"という言葉は、第二次世界大戦中のアメリカで流行した言葉です。イギリスでは、"Careless talk costs lives "という言葉があった。この言葉の要点は、機密情報を不用意に話すとスパイに聞かれて大変なことになるということである。
ウェブアプリケーションを構築する際にも、同じ原理が当てはまります。ウェブアプリケーションがあまりにも多くの情報を公開してしまうと、攻撃者が侵入しやすくなってしまいます。
この記事では、情報漏洩とは何か、なぜ危険なのか、どうすれば防げるのかを説明します。
情報露出の把握
情報漏洩とは、ウェブアプリケーションが内部情報を見るべきではない人に公開することを指します。また、ログファイルやユーザーインターフェイスを通じて、顧客の機密情報を公開することもあります。いずれにしても、攻撃者は見つけた情報を使って、システムやユーザーを攻撃することができます。
多くの場合、攻撃者の最初のステップは、アプリケーション内でエラーを発生させようとすることです。エラー処理やウェブアプリケーションの設定が不十分だと、エラーメッセージによる情報漏洩につながります。攻撃者がアプリケーション内でエラーを作成した場合、何が起こるでしょうか？スタックトレースのような技術的な詳細を含む技術的なエラーメッセージが表示された場合、あなたはあまりにも多くの情報を公開しています。これらの詳細には、使用しているデータベースや、実行しているアプリケーションサーバのバージョンなどが含まれます。
機密情報の漏洩は、他の方法でも起こりえます。フォームの隠しフィールドに機密情報が入っていませんか？攻撃者は、ページのソースを見るだけで、値を見ることができます。
一言で言えば、情報漏洩とは、ユーザーが知る必要のある情報が簡単にアクセスできてしまうことです。
情報漏洩の危険性を理解する
アプリケーションで公開された情報を使って、攻撃者は何ができるか？その情報が機密性の高いものであれば、攻撃者はIDやユーザー認証情報を盗むことができます。これにより、金銭的損害、プライバシー侵害、規制当局からの罰金につながる可能性があります。
攻撃者がエラーメッセージを使用してアプリケーションに関する情報を得た場合、その情報は将来の攻撃に使用される可能性があります。実際、OWASP テストガイドには、情報収集に関するセクションがあります。
OWASP テスティングガイドでは、あなたが意図していないようなあなたのウェブサイトに関する情報を見つけるために、 検索エンジンを使うことを推奨しています。例えば、あなたの管理ページは、検索エンジンにさらされていませんか？robots.txt ファイルを使用して、特定のページをインデックスしないように検索エンジンに指示してください。一方で、robots.txtファイルは情報を漏らすこともあります。機密性の高いURLがrobots.txtファイルに存在していることがあります。攻撃者は、このファイルを引き下げて、サイトのディレクトリ構造の一部を学び始めます。
Google has advanced search engine options which allow deep inspection of websites. For example, you can search on a specific site using the "site: <domain>" syntax. You can view cached pages which may have been deleted but still reside in a cache from a previous indexing job. Using different search engines, such as Bing and DuckDuckGo may yield different results, so test on each search engine what is revealed about your web application.</domain>
HTTPヘッダ、ウェブサイトのバナー、さらにはHTMLやJavaScriptコード内のコメントには、攻撃者が見るべきでない情報が含まれている可能性があります。HTTPヘッダには、アプリケーションサーバやバージョン番号が含まれています。攻撃者はこの情報を利用して、特定のバージョンに対して使用するエクスプロイトを見つけることができます。攻撃者が情報を見つける可能性のあるさまざまな場所を理解し、それを適切に隠す方法を確認してください。
情報露出をなくす
情報漏洩は、ウェブアプリケーションの設定でしばしば問題になります。多くのアプリケーション・サーバは、デフォルトでエラーメッセージにスタック・トレースを返します。トラブルシューティングのためにエラーを記録しながら、一般的なエラーページにリダイレクトするよう、本番アプリケーションでは必ずこの設定を変更してください。詳細なエラーメッセージをユーザのブラウザに返してはいけません。
アプリケーションに必要なファイルの中に機密情報が含まれている場合は、適切なアクセスコントロールにより、アプリケーション自身しか読めないようにしてください。サーバのディレクトリ・リスティングを無効にして、これらのファイルをウェブ・ルート・ディレクトリの外に移動します。これにより、攻撃者がブラウザを使ってディレクトリトラバーサル攻撃でファイルに移動することを防ぐことができます。
ログは、正しく設定されていない場合、情報収集に使用されることがあります。エラーが発生した場合、パスワード、セッショントークン、個人識別情報（PII）などの機密情報をログに記録しないようにしてください。攻撃者がログファイルにアクセスできるようになれば、機密情報を盗むための宝の山を見つけることになります。通常は、アカウント識別子、詳細なエラーメッセージ、エラーが発生した方法や実行された操作など、必要以上の情報を記録しないようにしましょう。ログファイルは秘密のものではないと考え、その中に機密情報を入れようとは思わないようにしましょう。
ウェブアプリを沈めないために
第二次世界大戦で戦艦の損失に直結するような情報を、友人との会話中に漏らしてしまったことがあるだろうか。そうではないかもしれない。しかし、なぜそのようなリスクを冒すのでしょうか？それが、"Loose lips sink ships "ということわざの教訓です。
同様に、ウェブアプリケーションの内部構造を外部に公開する理由はありません。クレジットカードの番号やパスワードを丸ごと閲覧する理由はありません。PIIデータをログファイルに保存する理由もありません。ですから、やめておきましょう。情報公開についての詳細は、ラーニングリソースをご覧ください。
アプリケーションの内部構造を、本来あるべき場所に保持します。Webアプリケーションを沈めないでください。
今すぐにでも、情報漏洩に歯止めをかけることができると思いませんか？挑戦してみよう、戦士よ。[ここからスタート]
"Loose lips sink ships"という言葉は、第二次世界大戦中のアメリカで流行した言葉です。イギリスでは、"Careless talk costs lives "という言葉があった。この言葉の要点は、機密情報を不用意に話すとスパイに聞かれて大変なことになるということである。
ウェブアプリケーションを構築する際にも、同じ原理が当てはまります。ウェブアプリケーションがあまりにも多くの情報を公開してしまうと、攻撃者が侵入しやすくなってしまいます。
この記事では、情報漏洩とは何か、なぜ危険なのか、どうすれば防げるのかを説明します。
情報露出の把握
情報漏洩とは、ウェブアプリケーションが内部情報を見るべきではない人に公開することを指します。また、ログファイルやユーザーインターフェイスを通じて、顧客の機密情報を公開することもあります。いずれにしても、攻撃者は見つけた情報を使って、システムやユーザーを攻撃することができます。
多くの場合、攻撃者の最初のステップは、アプリケーション内でエラーを発生させようとすることです。エラー処理やウェブアプリケーションの設定が不十分だと、エラーメッセージによる情報漏洩につながります。攻撃者がアプリケーション内でエラーを作成した場合、何が起こるでしょうか？スタックトレースのような技術的な詳細を含む技術的なエラーメッセージが表示された場合、あなたはあまりにも多くの情報を公開しています。これらの詳細には、使用しているデータベースや、実行しているアプリケーションサーバのバージョンなどが含まれます。
機密情報の漏洩は、他の方法でも起こりえます。フォームの隠しフィールドに機密情報が入っていませんか？攻撃者は、ページのソースを見るだけで、値を見ることができます。
一言で言えば、情報漏洩とは、ユーザーが知る必要のある情報が簡単にアクセスできてしまうことです。
情報漏洩の危険性を理解する
アプリケーションで公開された情報を使って、攻撃者は何ができるか？その情報が機密性の高いものであれば、攻撃者はIDやユーザー認証情報を盗むことができます。これにより、金銭的損害、プライバシー侵害、規制当局からの罰金につながる可能性があります。
攻撃者がエラーメッセージを使用してアプリケーションに関する情報を得た場合、その情報は将来の攻撃に使用される可能性があります。実際、OWASP テストガイドには、情報収集に関するセクションがあります。
OWASP テスティングガイドでは、あなたが意図していないようなあなたのウェブサイトに関する情報を見つけるために、 検索エンジンを使うことを推奨しています。例えば、あなたの管理ページは、検索エンジンにさらされていませんか？robots.txt ファイルを使用して、特定のページをインデックスしないように検索エンジンに指示してください。一方で、robots.txtファイルは情報を漏らすこともあります。機密性の高いURLがrobots.txtファイルに存在していることがあります。攻撃者は、このファイルを引き下げて、サイトのディレクトリ構造の一部を学び始めます。
Google has advanced search engine options which allow deep inspection of websites. For example, you can search on a specific site using the "site: <domain>" syntax. You can view cached pages which may have been deleted but still reside in a cache from a previous indexing job. Using different search engines, such as Bing and DuckDuckGo may yield different results, so test on each search engine what is revealed about your web application.</domain>
HTTPヘッダ、ウェブサイトのバナー、さらにはHTMLやJavaScriptコード内のコメントには、攻撃者が見るべきでない情報が含まれている可能性があります。HTTPヘッダには、アプリケーションサーバやバージョン番号が含まれています。攻撃者はこの情報を利用して、特定のバージョンに対して使用するエクスプロイトを見つけることができます。攻撃者が情報を見つける可能性のあるさまざまな場所を理解し、それを適切に隠す方法を確認してください。
情報露出をなくす
情報漏洩は、ウェブアプリケーションの設定でしばしば問題になります。多くのアプリケーション・サーバは、デフォルトでエラーメッセージにスタック・トレースを返します。トラブルシューティングのためにエラーを記録しながら、一般的なエラーページにリダイレクトするよう、本番アプリケーションでは必ずこの設定を変更してください。詳細なエラーメッセージをユーザのブラウザに返してはいけません。
アプリケーションに必要なファイルの中に機密情報が含まれている場合は、適切なアクセスコントロールにより、アプリケーション自身しか読めないようにしてください。サーバのディレクトリ・リスティングを無効にして、これらのファイルをウェブ・ルート・ディレクトリの外に移動します。これにより、攻撃者がブラウザを使ってディレクトリトラバーサル攻撃でファイルに移動することを防ぐことができます。
ログは、正しく設定されていない場合、情報収集に使用されることがあります。エラーが発生した場合、パスワード、セッショントークン、個人識別情報（PII）などの機密情報をログに記録しないようにしてください。攻撃者がログファイルにアクセスできるようになれば、機密情報を盗むための宝の山を見つけることになります。通常は、アカウント識別子、詳細なエラーメッセージ、エラーが発生した方法や実行された操作など、必要以上の情報を記録しないようにしましょう。ログファイルは秘密のものではないと考え、その中に機密情報を入れようとは思わないようにしましょう。
ウェブアプリを沈めないために
第二次世界大戦で戦艦の損失に直結するような情報を、友人との会話中に漏らしてしまったことがあるだろうか。そうではないかもしれない。しかし、なぜそのようなリスクを冒すのでしょうか？それが、"Loose lips sink ships "ということわざの教訓です。
同様に、ウェブアプリケーションの内部構造を外部に公開する理由はありません。クレジットカードの番号やパスワードを丸ごと閲覧する理由はありません。PIIデータをログファイルに保存する理由もありません。ですから、やめておきましょう。情報公開についての詳細は、ラーニングリソースをご覧ください。
アプリケーションの内部構造を、本来あるべき場所に保持します。Webアプリケーションを沈めないでください。
今すぐにでも、情報漏洩に歯止めをかけることができると思いませんか？挑戦してみよう、戦士よ。[ここからスタート]
以下のリンクをクリックし、この資料のPDFをダウンロードしてください。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
レポートを見るデモを予約する
Jaap Karan Singhは、Secure Coding Evangelistであり、Chief Singhであり、Secure Code Warrior の共同設立者です。
"Loose lips sink ships"という言葉は、第二次世界大戦中のアメリカで流行した言葉です。イギリスでは、"Careless talk costs lives "という言葉があった。この言葉の要点は、機密情報を不用意に話すとスパイに聞かれて大変なことになるということである。
ウェブアプリケーションを構築する際にも、同じ原理が当てはまります。ウェブアプリケーションがあまりにも多くの情報を公開してしまうと、攻撃者が侵入しやすくなってしまいます。
この記事では、情報漏洩とは何か、なぜ危険なのか、どうすれば防げるのかを説明します。
情報露出の把握
情報漏洩とは、ウェブアプリケーションが内部情報を見るべきではない人に公開することを指します。また、ログファイルやユーザーインターフェイスを通じて、顧客の機密情報を公開することもあります。いずれにしても、攻撃者は見つけた情報を使って、システムやユーザーを攻撃することができます。
多くの場合、攻撃者の最初のステップは、アプリケーション内でエラーを発生させようとすることです。エラー処理やウェブアプリケーションの設定が不十分だと、エラーメッセージによる情報漏洩につながります。攻撃者がアプリケーション内でエラーを作成した場合、何が起こるでしょうか？スタックトレースのような技術的な詳細を含む技術的なエラーメッセージが表示された場合、あなたはあまりにも多くの情報を公開しています。これらの詳細には、使用しているデータベースや、実行しているアプリケーションサーバのバージョンなどが含まれます。
機密情報の漏洩は、他の方法でも起こりえます。フォームの隠しフィールドに機密情報が入っていませんか？攻撃者は、ページのソースを見るだけで、値を見ることができます。
一言で言えば、情報漏洩とは、ユーザーが知る必要のある情報が簡単にアクセスできてしまうことです。
情報漏洩の危険性を理解する
アプリケーションで公開された情報を使って、攻撃者は何ができるか？その情報が機密性の高いものであれば、攻撃者はIDやユーザー認証情報を盗むことができます。これにより、金銭的損害、プライバシー侵害、規制当局からの罰金につながる可能性があります。
攻撃者がエラーメッセージを使用してアプリケーションに関する情報を得た場合、その情報は将来の攻撃に使用される可能性があります。実際、OWASP テストガイドには、情報収集に関するセクションがあります。
OWASP テスティングガイドでは、あなたが意図していないようなあなたのウェブサイトに関する情報を見つけるために、 検索エンジンを使うことを推奨しています。例えば、あなたの管理ページは、検索エンジンにさらされていませんか？robots.txt ファイルを使用して、特定のページをインデックスしないように検索エンジンに指示してください。一方で、robots.txtファイルは情報を漏らすこともあります。機密性の高いURLがrobots.txtファイルに存在していることがあります。攻撃者は、このファイルを引き下げて、サイトのディレクトリ構造の一部を学び始めます。
Google has advanced search engine options which allow deep inspection of websites. For example, you can search on a specific site using the "site: <domain>" syntax. You can view cached pages which may have been deleted but still reside in a cache from a previous indexing job. Using different search engines, such as Bing and DuckDuckGo may yield different results, so test on each search engine what is revealed about your web application.</domain>
HTTPヘッダ、ウェブサイトのバナー、さらにはHTMLやJavaScriptコード内のコメントには、攻撃者が見るべきでない情報が含まれている可能性があります。HTTPヘッダには、アプリケーションサーバやバージョン番号が含まれています。攻撃者はこの情報を利用して、特定のバージョンに対して使用するエクスプロイトを見つけることができます。攻撃者が情報を見つける可能性のあるさまざまな場所を理解し、それを適切に隠す方法を確認してください。
情報露出をなくす
情報漏洩は、ウェブアプリケーションの設定でしばしば問題になります。多くのアプリケーション・サーバは、デフォルトでエラーメッセージにスタック・トレースを返します。トラブルシューティングのためにエラーを記録しながら、一般的なエラーページにリダイレクトするよう、本番アプリケーションでは必ずこの設定を変更してください。詳細なエラーメッセージをユーザのブラウザに返してはいけません。
アプリケーションに必要なファイルの中に機密情報が含まれている場合は、適切なアクセスコントロールにより、アプリケーション自身しか読めないようにしてください。サーバのディレクトリ・リスティングを無効にして、これらのファイルをウェブ・ルート・ディレクトリの外に移動します。これにより、攻撃者がブラウザを使ってディレクトリトラバーサル攻撃でファイルに移動することを防ぐことができます。
ログは、正しく設定されていない場合、情報収集に使用されることがあります。エラーが発生した場合、パスワード、セッショントークン、個人識別情報（PII）などの機密情報をログに記録しないようにしてください。攻撃者がログファイルにアクセスできるようになれば、機密情報を盗むための宝の山を見つけることになります。通常は、アカウント識別子、詳細なエラーメッセージ、エラーが発生した方法や実行された操作など、必要以上の情報を記録しないようにしましょう。ログファイルは秘密のものではないと考え、その中に機密情報を入れようとは思わないようにしましょう。
ウェブアプリを沈めないために
第二次世界大戦で戦艦の損失に直結するような情報を、友人との会話中に漏らしてしまったことがあるだろうか。そうではないかもしれない。しかし、なぜそのようなリスクを冒すのでしょうか？それが、"Loose lips sink ships "ということわざの教訓です。
同様に、ウェブアプリケーションの内部構造を外部に公開する理由はありません。クレジットカードの番号やパスワードを丸ごと閲覧する理由はありません。PIIデータをログファイルに保存する理由もありません。ですから、やめておきましょう。情報公開についての詳細は、ラーニングリソースをご覧ください。
アプリケーションの内部構造を、本来あるべき場所に保持します。Webアプリケーションを沈めないでください。
今すぐにでも、情報漏洩に歯止めをかけることができると思いませんか？挑戦してみよう、戦士よ。[ここからスタート]
始めるためのリソース
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.