コーダーがセキュリティを征服する OWASP トップ 10 API シリーズ-リソース不足とレート制限
リソースの不足とレートの制限により、APIの脆弱性は、タイトルで説明されていることとほぼ同じように振る舞います。すべてのAPIは、その環境に応じて利用可能なリソースとコンピューティングパワーが制限されています。また、多くのAPIは、ユーザーや他のプログラムからの要求に応じて、必要な機能を実行する必要があります。この脆弱性は、あまりにも多くのリクエストが同時に来て、APIがそれらのリクエストを処理するための十分なコンピューティングリソースを持っていない場合に発生します。その結果、APIは新たな要求に対応できなくなり、利用できなくなります。
APIは、レートやリソースの制限が正しく設定されていなかったり、コード内で制限が定義されていなかったりすると、この問題の影響を受けやすくなります。例えば、ビジネスが特に忙しい時期になると、APIが過負荷になる可能性があります。しかし、これはセキュリティ上の脆弱性でもあります。なぜなら、脅威となるアクターは、サービス拒否（DDoS）攻撃を行うために、保護されていないAPIに意図的にリクエストを過負荷にすることができるからです。
ところで、これまでのAPIゲーミフィケーションのチャレンジはいかがでしたか？もしあなたが、今すぐレート制限のある脆弱性を扱うスキルを試したいなら、アリーナに足を踏み入れてください。
さて、もう少し踏み込んでみましょう。
リソースの不足やレートの制限によるAPIの脆弱性の例を教えてください。
この脆弱性がAPIに潜り込む方法は2つあります。1つ目は、コーダーがAPIのスロットルレートを単純に定義していない場合です。インフラのどこかにスロットルレートのデフォルト設定があるかもしれませんが、それに頼るのは良いポリシーとは言えません。そうではなく、それぞれのAPIに個別にレートを設定する必要があります。特に、APIは機能や利用可能なリソースが大きく異なる場合があるからです。
例えば、数人のユーザーにしかサービスを提供しないように設計された内部APIであれば、非常に低いスロットルレートでも問題なく動作します。しかし、ライブの E コマースサイトの一部である一般向けの API では、同時ユーザー数の急増の可能性を補うために、特別に高いレートを定義する必要があるでしょう。いずれの場合も、予想されるニーズ、潜在的なユーザー数、利用可能なコンピューティングパワーに基づいて、スロットルレートを定義する必要がある。
特にトラフィックの多い API では、パフォーマンスを最大化するために、レートを無制限に設定したくなるかもしれません。これは、簡単なコードで実現できます（例として、Python Django REST フレームワークを使用します）。
"DEFAULT_THROTTLE_RATES: {
"anon: None,
"user: None
この例では、匿名のユーザーも、システムに知られているユーザーも、時間経過によるリクエスト数を気にすることなく、無制限にAPIにアクセスすることができます。なぜなら、APIがどれだけ多くのコンピューティングリソースを持っていても、攻撃者はボットネットなどを配備して、最終的にはAPIの動作を遅くしたり、場合によっては完全にオフラインにしたりすることができるからである。そうなると、有効なユーザーはアクセスを拒否され、攻撃が成功することになります。
リソース不足やレート制限の問題を解消するために
組織がデプロイするすべてのAPIは、そのコードの中でスロットルレートを定義する必要があります。これには、実行タイムアウト、最大許容メモリ、ユーザーに返すことのできる1ページあたりのレコード数、定義された時間枠内で許可されるプロセス数などが含まれます。
上記の例では、スロットリング率を大きく開放するのではなく、匿名ユーザーと既知のユーザーで異なる率を設定するなど、厳密に定義することができます。
"DEFAULT_THROTTLE_RATES: {
"anon: config("THROTTLE_ANON, default=200/hour),
"user: config("THROTTLE_USER, default=5000/hour)
今回の例では、匿名のユーザーが1時間にリクエストできる回数を200回に制限しています。すでにシステムで審査されている既知のユーザーは、1時間あたり5,000リクエストと、より大きな余裕が与えられます。しかし、これらの制限は、ピーク時の偶発的な過負荷を防ぐためや、ユーザーアカウントが漏洩してサービス妨害攻撃に使用された場合の補償のためのものである。
最後に考慮すべきグッドプラクティスとして、ユーザーがスロットリングの限界に達したときには、その限界がいつリセットされるかについての説明とともに、ユーザーに通知を表示することをお勧めします。これにより、有効なユーザーは、アプリケーションがリクエストを拒否する理由を知ることができます。また、承認されたタスクを実行している有効なユーザーがAPIへのアクセスを拒否された場合にも、スロットリングを増加させる必要があることをオペレーション担当者に知らせることができるため、この方法は役に立つ。
をご覧ください。 Secure Code Warriorブログページでは、この脆弱性に関するより詳しい情報や、他のセキュリティ上の欠陥の被害から組織や顧客を守るための方法を紹介しています。また、Secure Code Warrior トレーニングプラットフォームのデモをお試しいただくことで、サイバーセキュリティに関するすべてのスキルを磨き、最新の状態に保つことができます。
この脆弱性は、同時に受信するリクエストが多すぎて、それらのリクエストを処理するための十分なコンピューティングリソースが API にない場合に発生します。そうすると、API が使用できなくなったり、新しいリクエストに応答しなくなったりする可能性があります。
マティアス・マドゥ博士は、セキュリティ専門家、研究者、CTO、セキュア・コード・ウォリアーの共同創設者です。マティアスはゲント大学で静的解析ソリューションを中心としたアプリケーションセキュリティの博士号を取得しました。その後、米国のFortifyに入社し、開発者が安全なコードを書くのを手助けせずに、コードの問題を検出するだけでは不十分であることに気づきました。これがきっかけで、開発者を支援し、セキュリティの負担を軽減し、顧客の期待を超える製品を開発するようになりました。Team Awesomeの一員としてデスクにいない時は、RSAカンファレンス、BlackHat、DefConなどのカンファレンスでプレゼンテーションを行うステージでのプレゼンテーションを楽しんでいます。
Secure Code Warriorは、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする文化を築くお手伝いをします。アプリケーションセキュリティマネージャー、開発者、CISO、またはセキュリティ関係者であるかに関わらず、安全でないコードに関連するリスクを軽減するお手伝いをします。
デモを予約
マティアス・マドゥ博士は、セキュリティ専門家、研究者、CTO、セキュア・コード・ウォリアーの共同創設者です。マティアスはゲント大学で静的解析ソリューションを中心としたアプリケーションセキュリティの博士号を取得しました。その後、米国のFortifyに入社し、開発者が安全なコードを書くのを手助けせずに、コードの問題を検出するだけでは不十分であることに気づきました。これがきっかけで、開発者を支援し、セキュリティの負担を軽減し、顧客の期待を超える製品を開発するようになりました。Team Awesomeの一員としてデスクにいない時は、RSAカンファレンス、BlackHat、DefConなどのカンファレンスでプレゼンテーションを行うステージでのプレゼンテーションを楽しんでいます。
マティアスは、15年以上のソフトウェアセキュリティの実務経験を持つ研究者および開発者です。フォーティファイ・ソフトウェアや自身の会社であるセンセイ・セキュリティなどの企業向けにソリューションを開発してきました。マティアスはキャリアを通じて、複数のアプリケーションセキュリティ研究プロジェクトを主導し、それが商用製品につながり、10件以上の特許を取得しています。デスクから離れている時には、上級アプリケーション・セキュリティ・トレーニング・コースの講師を務め、RSA Conference、Black Hat、DefCon、BSIMM、OWASP AppSec、BruConなどのグローバルカンファレンスで定期的に講演を行っています。
マティアスはゲント大学でコンピューター工学の博士号を取得し、そこでアプリケーションの内部動作を隠すためのプログラムの難読化によるアプリケーションセキュリティを学びました。
リソースの不足とレートの制限により、APIの脆弱性は、タイトルで説明されていることとほぼ同じように振る舞います。すべてのAPIは、その環境に応じて利用可能なリソースとコンピューティングパワーが制限されています。また、多くのAPIは、ユーザーや他のプログラムからの要求に応じて、必要な機能を実行する必要があります。この脆弱性は、あまりにも多くのリクエストが同時に来て、APIがそれらのリクエストを処理するための十分なコンピューティングリソースを持っていない場合に発生します。その結果、APIは新たな要求に対応できなくなり、利用できなくなります。
APIは、レートやリソースの制限が正しく設定されていなかったり、コード内で制限が定義されていなかったりすると、この問題の影響を受けやすくなります。例えば、ビジネスが特に忙しい時期になると、APIが過負荷になる可能性があります。しかし、これはセキュリティ上の脆弱性でもあります。なぜなら、脅威となるアクターは、サービス拒否（DDoS）攻撃を行うために、保護されていないAPIに意図的にリクエストを過負荷にすることができるからです。
ところで、これまでのAPIゲーミフィケーションのチャレンジはいかがでしたか？もしあなたが、今すぐレート制限のある脆弱性を扱うスキルを試したいなら、アリーナに足を踏み入れてください。
さて、もう少し踏み込んでみましょう。
リソースの不足やレートの制限によるAPIの脆弱性の例を教えてください。
この脆弱性がAPIに潜り込む方法は2つあります。1つ目は、コーダーがAPIのスロットルレートを単純に定義していない場合です。インフラのどこかにスロットルレートのデフォルト設定があるかもしれませんが、それに頼るのは良いポリシーとは言えません。そうではなく、それぞれのAPIに個別にレートを設定する必要があります。特に、APIは機能や利用可能なリソースが大きく異なる場合があるからです。
例えば、数人のユーザーにしかサービスを提供しないように設計された内部APIであれば、非常に低いスロットルレートでも問題なく動作します。しかし、ライブの E コマースサイトの一部である一般向けの API では、同時ユーザー数の急増の可能性を補うために、特別に高いレートを定義する必要があるでしょう。いずれの場合も、予想されるニーズ、潜在的なユーザー数、利用可能なコンピューティングパワーに基づいて、スロットルレートを定義する必要がある。
特にトラフィックの多い API では、パフォーマンスを最大化するために、レートを無制限に設定したくなるかもしれません。これは、簡単なコードで実現できます（例として、Python Django REST フレームワークを使用します）。
"DEFAULT_THROTTLE_RATES: {
"anon: None,
"user: None
この例では、匿名のユーザーも、システムに知られているユーザーも、時間経過によるリクエスト数を気にすることなく、無制限にAPIにアクセスすることができます。なぜなら、APIがどれだけ多くのコンピューティングリソースを持っていても、攻撃者はボットネットなどを配備して、最終的にはAPIの動作を遅くしたり、場合によっては完全にオフラインにしたりすることができるからである。そうなると、有効なユーザーはアクセスを拒否され、攻撃が成功することになります。
リソース不足やレート制限の問題を解消するために
組織がデプロイするすべてのAPIは、そのコードの中でスロットルレートを定義する必要があります。これには、実行タイムアウト、最大許容メモリ、ユーザーに返すことのできる1ページあたりのレコード数、定義された時間枠内で許可されるプロセス数などが含まれます。
上記の例では、スロットリング率を大きく開放するのではなく、匿名ユーザーと既知のユーザーで異なる率を設定するなど、厳密に定義することができます。
"DEFAULT_THROTTLE_RATES: {
"anon: config("THROTTLE_ANON, default=200/hour),
"user: config("THROTTLE_USER, default=5000/hour)
今回の例では、匿名のユーザーが1時間にリクエストできる回数を200回に制限しています。すでにシステムで審査されている既知のユーザーは、1時間あたり5,000リクエストと、より大きな余裕が与えられます。しかし、これらの制限は、ピーク時の偶発的な過負荷を防ぐためや、ユーザーアカウントが漏洩してサービス妨害攻撃に使用された場合の補償のためのものである。
最後に考慮すべきグッドプラクティスとして、ユーザーがスロットリングの限界に達したときには、その限界がいつリセットされるかについての説明とともに、ユーザーに通知を表示することをお勧めします。これにより、有効なユーザーは、アプリケーションがリクエストを拒否する理由を知ることができます。また、承認されたタスクを実行している有効なユーザーがAPIへのアクセスを拒否された場合にも、スロットリングを増加させる必要があることをオペレーション担当者に知らせることができるため、この方法は役に立つ。
をご覧ください。 Secure Code Warriorブログページでは、この脆弱性に関するより詳しい情報や、他のセキュリティ上の欠陥の被害から組織や顧客を守るための方法を紹介しています。また、Secure Code Warrior トレーニングプラットフォームのデモをお試しいただくことで、サイバーセキュリティに関するすべてのスキルを磨き、最新の状態に保つことができます。
リソースの不足とレートの制限により、APIの脆弱性は、タイトルで説明されていることとほぼ同じように振る舞います。すべてのAPIは、その環境に応じて利用可能なリソースとコンピューティングパワーが制限されています。また、多くのAPIは、ユーザーや他のプログラムからの要求に応じて、必要な機能を実行する必要があります。この脆弱性は、あまりにも多くのリクエストが同時に来て、APIがそれらのリクエストを処理するための十分なコンピューティングリソースを持っていない場合に発生します。その結果、APIは新たな要求に対応できなくなり、利用できなくなります。
APIは、レートやリソースの制限が正しく設定されていなかったり、コード内で制限が定義されていなかったりすると、この問題の影響を受けやすくなります。例えば、ビジネスが特に忙しい時期になると、APIが過負荷になる可能性があります。しかし、これはセキュリティ上の脆弱性でもあります。なぜなら、脅威となるアクターは、サービス拒否（DDoS）攻撃を行うために、保護されていないAPIに意図的にリクエストを過負荷にすることができるからです。
ところで、これまでのAPIゲーミフィケーションのチャレンジはいかがでしたか？もしあなたが、今すぐレート制限のある脆弱性を扱うスキルを試したいなら、アリーナに足を踏み入れてください。
さて、もう少し踏み込んでみましょう。
リソースの不足やレートの制限によるAPIの脆弱性の例を教えてください。
この脆弱性がAPIに潜り込む方法は2つあります。1つ目は、コーダーがAPIのスロットルレートを単純に定義していない場合です。インフラのどこかにスロットルレートのデフォルト設定があるかもしれませんが、それに頼るのは良いポリシーとは言えません。そうではなく、それぞれのAPIに個別にレートを設定する必要があります。特に、APIは機能や利用可能なリソースが大きく異なる場合があるからです。
例えば、数人のユーザーにしかサービスを提供しないように設計された内部APIであれば、非常に低いスロットルレートでも問題なく動作します。しかし、ライブの E コマースサイトの一部である一般向けの API では、同時ユーザー数の急増の可能性を補うために、特別に高いレートを定義する必要があるでしょう。いずれの場合も、予想されるニーズ、潜在的なユーザー数、利用可能なコンピューティングパワーに基づいて、スロットルレートを定義する必要がある。
特にトラフィックの多い API では、パフォーマンスを最大化するために、レートを無制限に設定したくなるかもしれません。これは、簡単なコードで実現できます（例として、Python Django REST フレームワークを使用します）。
"DEFAULT_THROTTLE_RATES: {
"anon: None,
"user: None
この例では、匿名のユーザーも、システムに知られているユーザーも、時間経過によるリクエスト数を気にすることなく、無制限にAPIにアクセスすることができます。なぜなら、APIがどれだけ多くのコンピューティングリソースを持っていても、攻撃者はボットネットなどを配備して、最終的にはAPIの動作を遅くしたり、場合によっては完全にオフラインにしたりすることができるからである。そうなると、有効なユーザーはアクセスを拒否され、攻撃が成功することになります。
リソース不足やレート制限の問題を解消するために
組織がデプロイするすべてのAPIは、そのコードの中でスロットルレートを定義する必要があります。これには、実行タイムアウト、最大許容メモリ、ユーザーに返すことのできる1ページあたりのレコード数、定義された時間枠内で許可されるプロセス数などが含まれます。
上記の例では、スロットリング率を大きく開放するのではなく、匿名ユーザーと既知のユーザーで異なる率を設定するなど、厳密に定義することができます。
"DEFAULT_THROTTLE_RATES: {
"anon: config("THROTTLE_ANON, default=200/hour),
"user: config("THROTTLE_USER, default=5000/hour)
今回の例では、匿名のユーザーが1時間にリクエストできる回数を200回に制限しています。すでにシステムで審査されている既知のユーザーは、1時間あたり5,000リクエストと、より大きな余裕が与えられます。しかし、これらの制限は、ピーク時の偶発的な過負荷を防ぐためや、ユーザーアカウントが漏洩してサービス妨害攻撃に使用された場合の補償のためのものである。
最後に考慮すべきグッドプラクティスとして、ユーザーがスロットリングの限界に達したときには、その限界がいつリセットされるかについての説明とともに、ユーザーに通知を表示することをお勧めします。これにより、有効なユーザーは、アプリケーションがリクエストを拒否する理由を知ることができます。また、承認されたタスクを実行している有効なユーザーがAPIへのアクセスを拒否された場合にも、スロットリングを増加させる必要があることをオペレーション担当者に知らせることができるため、この方法は役に立つ。
をご覧ください。 Secure Code Warriorブログページでは、この脆弱性に関するより詳しい情報や、他のセキュリティ上の欠陥の被害から組織や顧客を守るための方法を紹介しています。また、Secure Code Warrior トレーニングプラットフォームのデモをお試しいただくことで、サイバーセキュリティに関するすべてのスキルを磨き、最新の状態に保つことができます。
以下のリンクをクリックして、このリソースのPDFをダウンロードしてください。
Secure Code Warriorは、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする文化を築くお手伝いをします。アプリケーションセキュリティマネージャー、開発者、CISO、またはセキュリティ関係者であるかに関わらず、安全でないコードに関連するリスクを軽減するお手伝いをします。
レポートを表示デモを予約
マティアス・マドゥ博士は、セキュリティ専門家、研究者、CTO、セキュア・コード・ウォリアーの共同創設者です。マティアスはゲント大学で静的解析ソリューションを中心としたアプリケーションセキュリティの博士号を取得しました。その後、米国のFortifyに入社し、開発者が安全なコードを書くのを手助けせずに、コードの問題を検出するだけでは不十分であることに気づきました。これがきっかけで、開発者を支援し、セキュリティの負担を軽減し、顧客の期待を超える製品を開発するようになりました。Team Awesomeの一員としてデスクにいない時は、RSAカンファレンス、BlackHat、DefConなどのカンファレンスでプレゼンテーションを行うステージでのプレゼンテーションを楽しんでいます。
マティアスは、15年以上のソフトウェアセキュリティの実務経験を持つ研究者および開発者です。フォーティファイ・ソフトウェアや自身の会社であるセンセイ・セキュリティなどの企業向けにソリューションを開発してきました。マティアスはキャリアを通じて、複数のアプリケーションセキュリティ研究プロジェクトを主導し、それが商用製品につながり、10件以上の特許を取得しています。デスクから離れている時には、上級アプリケーション・セキュリティ・トレーニング・コースの講師を務め、RSA Conference、Black Hat、DefCon、BSIMM、OWASP AppSec、BruConなどのグローバルカンファレンスで定期的に講演を行っています。
マティアスはゲント大学でコンピューター工学の博士号を取得し、そこでアプリケーションの内部動作を隠すためのプログラムの難読化によるアプリケーションセキュリティを学びました。
リソースの不足とレートの制限により、APIの脆弱性は、タイトルで説明されていることとほぼ同じように振る舞います。すべてのAPIは、その環境に応じて利用可能なリソースとコンピューティングパワーが制限されています。また、多くのAPIは、ユーザーや他のプログラムからの要求に応じて、必要な機能を実行する必要があります。この脆弱性は、あまりにも多くのリクエストが同時に来て、APIがそれらのリクエストを処理するための十分なコンピューティングリソースを持っていない場合に発生します。その結果、APIは新たな要求に対応できなくなり、利用できなくなります。
APIは、レートやリソースの制限が正しく設定されていなかったり、コード内で制限が定義されていなかったりすると、この問題の影響を受けやすくなります。例えば、ビジネスが特に忙しい時期になると、APIが過負荷になる可能性があります。しかし、これはセキュリティ上の脆弱性でもあります。なぜなら、脅威となるアクターは、サービス拒否（DDoS）攻撃を行うために、保護されていないAPIに意図的にリクエストを過負荷にすることができるからです。
ところで、これまでのAPIゲーミフィケーションのチャレンジはいかがでしたか？もしあなたが、今すぐレート制限のある脆弱性を扱うスキルを試したいなら、アリーナに足を踏み入れてください。
さて、もう少し踏み込んでみましょう。
リソースの不足やレートの制限によるAPIの脆弱性の例を教えてください。
この脆弱性がAPIに潜り込む方法は2つあります。1つ目は、コーダーがAPIのスロットルレートを単純に定義していない場合です。インフラのどこかにスロットルレートのデフォルト設定があるかもしれませんが、それに頼るのは良いポリシーとは言えません。そうではなく、それぞれのAPIに個別にレートを設定する必要があります。特に、APIは機能や利用可能なリソースが大きく異なる場合があるからです。
例えば、数人のユーザーにしかサービスを提供しないように設計された内部APIであれば、非常に低いスロットルレートでも問題なく動作します。しかし、ライブの E コマースサイトの一部である一般向けの API では、同時ユーザー数の急増の可能性を補うために、特別に高いレートを定義する必要があるでしょう。いずれの場合も、予想されるニーズ、潜在的なユーザー数、利用可能なコンピューティングパワーに基づいて、スロットルレートを定義する必要がある。
特にトラフィックの多い API では、パフォーマンスを最大化するために、レートを無制限に設定したくなるかもしれません。これは、簡単なコードで実現できます（例として、Python Django REST フレームワークを使用します）。
"DEFAULT_THROTTLE_RATES: {
"anon: None,
"user: None
この例では、匿名のユーザーも、システムに知られているユーザーも、時間経過によるリクエスト数を気にすることなく、無制限にAPIにアクセスすることができます。なぜなら、APIがどれだけ多くのコンピューティングリソースを持っていても、攻撃者はボットネットなどを配備して、最終的にはAPIの動作を遅くしたり、場合によっては完全にオフラインにしたりすることができるからである。そうなると、有効なユーザーはアクセスを拒否され、攻撃が成功することになります。
リソース不足やレート制限の問題を解消するために
組織がデプロイするすべてのAPIは、そのコードの中でスロットルレートを定義する必要があります。これには、実行タイムアウト、最大許容メモリ、ユーザーに返すことのできる1ページあたりのレコード数、定義された時間枠内で許可されるプロセス数などが含まれます。
上記の例では、スロットリング率を大きく開放するのではなく、匿名ユーザーと既知のユーザーで異なる率を設定するなど、厳密に定義することができます。
"DEFAULT_THROTTLE_RATES: {
"anon: config("THROTTLE_ANON, default=200/hour),
"user: config("THROTTLE_USER, default=5000/hour)
今回の例では、匿名のユーザーが1時間にリクエストできる回数を200回に制限しています。すでにシステムで審査されている既知のユーザーは、1時間あたり5,000リクエストと、より大きな余裕が与えられます。しかし、これらの制限は、ピーク時の偶発的な過負荷を防ぐためや、ユーザーアカウントが漏洩してサービス妨害攻撃に使用された場合の補償のためのものである。
最後に考慮すべきグッドプラクティスとして、ユーザーがスロットリングの限界に達したときには、その限界がいつリセットされるかについての説明とともに、ユーザーに通知を表示することをお勧めします。これにより、有効なユーザーは、アプリケーションがリクエストを拒否する理由を知ることができます。また、承認されたタスクを実行している有効なユーザーがAPIへのアクセスを拒否された場合にも、スロットリングを増加させる必要があることをオペレーション担当者に知らせることができるため、この方法は役に立つ。
をご覧ください。 Secure Code Warriorブログページでは、この脆弱性に関するより詳しい情報や、他のセキュリティ上の欠陥の被害から組織や顧客を守るための方法を紹介しています。また、Secure Code Warrior トレーニングプラットフォームのデモをお試しいただくことで、サイバーセキュリティに関するすべてのスキルを磨き、最新の状態に保つことができます。
目次
マティアス・マドゥ博士は、セキュリティ専門家、研究者、CTO、セキュア・コード・ウォリアーの共同創設者です。マティアスはゲント大学で静的解析ソリューションを中心としたアプリケーションセキュリティの博士号を取得しました。その後、米国のFortifyに入社し、開発者が安全なコードを書くのを手助けせずに、コードの問題を検出するだけでは不十分であることに気づきました。これがきっかけで、開発者を支援し、セキュリティの負担を軽減し、顧客の期待を超える製品を開発するようになりました。Team Awesomeの一員としてデスクにいない時は、RSAカンファレンス、BlackHat、DefConなどのカンファレンスでプレゼンテーションを行うステージでのプレゼンテーションを楽しんでいます。
Secure Code Warriorは、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする文化を築くお手伝いをします。アプリケーションセキュリティマネージャー、開発者、CISO、またはセキュリティ関係者であるかに関わらず、安全でないコードに関連するリスクを軽減するお手伝いをします。
デモを予約[ダウンロード]始めるためのリソース
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.
.png)
