Codeers Conquer Security Infrastructure as Codeシリーズ - ビジネスロジック
さて、これで（今のところ）終わりです。Infrastructure as Codeシリーズは今回で終了となります。Docker、Ansible、Kubernetes、Terraform、CloudFormationなどのセキュリティ問題を楽しく攻略していただけたでしょうか。
これで自分のスキルを試す準備ができたと思いますか？最後のゲーム化されたチャレンジをお試しください。
まだいくつかの点で不明な点がある場合は、読み進めてください。
今日、私たちが注目したい脆弱性は、ビジネスロジックの脆弱性です。これは、コーダーがビジネスロジックのルールを適切に実装しなかった場合に発生するもので、悪意のあるユーザがアプリケーションを悪用した場合、様々な種類の攻撃に対して脆弱になる可能性があります。各アプリケーションに実装されている目的や機能に応じて、ビジネスロジックの欠陥は、特権の昇格、不適切なリソースの使用、あるいは意図しない数多くのビジネスプロセスの実行を可能にするかもしれません。
多くの脆弱性とは異なり、ビジネスロジックルールの不正な実装は驚くほど巧妙です。そのため、アプリケーションやコードに紛れ込まないように、特別な注意を払う必要があります。
ビジネスロジックの欠陥の例としてはどのようなものがありますか？
ビジネスロジックの欠陥を誘発することがいかに簡単であるかの例として、Docker Composeファイルで定義されたDocker環境の次の例を考えてみましょう。コンテナが機能を実行できるように準備するために、開発者は次の例のようにDocker Composeファイルで定義された標準的なリソースポリシーを使用するかもしれません。
デプロイ：
リソース。
limits:
cpus:"0.5"
reservations:
cpus:"0.5"
表面的には問題ないように見えますが、このコンテナのリソースポリシーは、リソースの使用を適切に制限していません。攻撃者は、このビジネスロジックの欠陥を利用して、サービス拒否（DoS）攻撃を実行することができます。
ユーザーが多くのリソースを占有することを制限するために、開発者は各コンテナがサポートできる内容をより明確に定義しようとするかもしれません。そのため、新しいコードには配置制約が含まれているかもしれません。
デプロイ：
リソース。
limits:
cpus:"0.5"
reservations:
cpus:"0.5"
placement:
constraints:
- "node.labels.limit_cpu == 100M"
- "node.labels.limit_memory == 0.5"
一見すると、これはビジネスロジックの欠陥を解決するように見えます。しかし、この新しい配置制約は、Dockerコンテナサービスのリソース使用制限には影響しません。コンテナをスケジュールするノードを選択するためにのみ使用されます。この場合、DoS攻撃はまだ可能です。攻撃者はまずDockerコンテナを侵害する必要がありますが、その後は制限なくリソースを消耗することができるでしょう。
このように、ビジネスロジックの欠陥を考え、それを排除するためにプログラミングすることは、難しいことです。
ビジネスロジックの不備を解消
ビジネスロジックの欠陥で重要なのは、その存在を知ることです。新しいコードが書かれている間は、それらを環境に入れないように注意を払う必要があります。ビジネスルールとベストプラクティスを明確に定義し、設計、実装、テストを含むアプリケーション開発プロセスのすべての段階でチェックする必要があります。
例えば、ビジネスロジックの欠陥によって上記の例のようなDoS攻撃が可能になるのを防ぐためには、作成したすべてのDockerコンテナが使用できるリソースの量を制限することがベストプラクティスです。具体的には、limitセクションで、Dockerコンテナが使用できるCPUの数とメモリの量を指定する必要があります。例としては、次のようになります。
デプロイ：
リソース。
limits:
cpus:"0.5"
memory: 100M
reservations:
cpus:"0.5"
memory:50M
上記の例のようなコードをポリシーとして使用することで、ビジネスロジック上の大きな欠陥を環境から取り除き、DoS攻撃を防ぐことができます。これは、仮に攻撃者がDockerコンテナの1つを侵害したとしても機能します。その場合でも、攻撃者はその足場を利用してリソースを枯渇させることはできません。
脅威のモデル化は、さまざまな攻撃がどのように行われるかを定義し、ビジネスロジックのルールを使用して攻撃を防止・制限することで有効です。また、コンプライアンスルールや既知の不正使用事例に基づいてテストを行うことで、見落としがちなビジネスロジックの欠陥を発見することができます。
ビジネスロジックの欠陥は、アプリケーションに忍び込む可能性のある最も巧妙な脆弱性の一つですが、注目を集める他のリスクに劣らず危険です。ビジネスロジックの欠陥がどのようにして発生するかを知り、ベストプラクティスを用いることで、アプリケーションの開発段階ではそのような脆弱性を排除することができ、本番環境ではそのような脆弱性を悪用する方法を熟知した攻撃者に悪用されることはありません。
をご覧ください。 Secure Code Warriorブログページでは、この脆弱性や、他のセキュリティ上の欠陥の被害から組織や顧客を守るための方法について、さらに詳しい情報が掲載されています。また、Secure Code Warrior トレーニングプラットフォームでは、このIaCチャレンジのデモを試すことができ、サイバーセキュリティに関するすべてのスキルを磨き上げ、最新の状態に保つことができます。
この脆弱性は、コーダーがビジネスロジックのルールを適切に実装しなかった場合に発生し、悪意のあるユーザーがアプリケーションを悪用した場合、さまざまな種類の攻撃に対して脆弱になる可能性があります。
Matias Madou, Ph.D. セキュリティ専門家、研究者、CTO兼共同設立者（Secure Code Warrior ）。Ghent大学でアプリケーションセキュリティの博士号を取得し、静的解析ソリューションに焦点を当てた。その後、米国Fortify社に入社し、開発者が安全なコードを書くことを支援せずに、コードの問題を検出するだけでは不十分であることに気づきました。開発者を支援し、セキュリティの負担を軽減し、お客様の期待を上回る製品を開発することを志すようになった。Team Awesomeの一員としてデスクワークをしていないときは、RSA Conference、BlackHat、DefConなどのカンファレンスでプレゼンテーションをするのが好きである。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
デモを予約する
Matias Madou, Ph.D. セキュリティ専門家、研究者、CTO兼共同設立者（Secure Code Warrior ）。Ghent大学でアプリケーションセキュリティの博士号を取得し、静的解析ソリューションに焦点を当てた。その後、米国Fortify社に入社し、開発者が安全なコードを書くことを支援せずに、コードの問題を検出するだけでは不十分であることに気づきました。開発者を支援し、セキュリティの負担を軽減し、お客様の期待を上回る製品を開発することを志すようになった。Team Awesomeの一員としてデスクワークをしていないときは、RSA Conference、BlackHat、DefConなどのカンファレンスでプレゼンテーションをするのが好きである。
マティアスは、15年以上のソフトウェアセキュリティの実務経験を持つ研究者・開発者です。フォーティファイ・ソフトウェア社や自身の会社（Sensei Security）などでソリューションを開発してきました。キャリアの中で、Matiasは、商用製品につながる複数のアプリケーションセキュリティ研究プロジェクトを主導し、10件以上の特許を取得しています。また、RSAカンファレンス、Black Hat、DefCon、BSIMM、OWASP AppSec、BruConなどの世界的なカンファレンスで定期的に講演を行っているほか、高度なアプリケーションセキュリティトレーニング（courses ）の講師も務めています。
Matiasはゲント大学でコンピュータ工学の博士号を取得し、アプリケーションの内部構造を隠すためのプログラム難読化によるアプリケーションセキュリティを研究しました。
さて、これで（今のところ）終わりです。Infrastructure as Codeシリーズは今回で終了となります。Docker、Ansible、Kubernetes、Terraform、CloudFormationなどのセキュリティ問題を楽しく攻略していただけたでしょうか。
これで自分のスキルを試す準備ができたと思いますか？最後のゲーム化されたチャレンジをお試しください。
まだいくつかの点で不明な点がある場合は、読み進めてください。
今日、私たちが注目したい脆弱性は、ビジネスロジックの脆弱性です。これは、コーダーがビジネスロジックのルールを適切に実装しなかった場合に発生するもので、悪意のあるユーザがアプリケーションを悪用した場合、様々な種類の攻撃に対して脆弱になる可能性があります。各アプリケーションに実装されている目的や機能に応じて、ビジネスロジックの欠陥は、特権の昇格、不適切なリソースの使用、あるいは意図しない数多くのビジネスプロセスの実行を可能にするかもしれません。
多くの脆弱性とは異なり、ビジネスロジックルールの不正な実装は驚くほど巧妙です。そのため、アプリケーションやコードに紛れ込まないように、特別な注意を払う必要があります。
ビジネスロジックの欠陥の例としてはどのようなものがありますか？
ビジネスロジックの欠陥を誘発することがいかに簡単であるかの例として、Docker Composeファイルで定義されたDocker環境の次の例を考えてみましょう。コンテナが機能を実行できるように準備するために、開発者は次の例のようにDocker Composeファイルで定義された標準的なリソースポリシーを使用するかもしれません。
デプロイ：
リソース。
limits:
cpus:"0.5"
reservations:
cpus:"0.5"
表面的には問題ないように見えますが、このコンテナのリソースポリシーは、リソースの使用を適切に制限していません。攻撃者は、このビジネスロジックの欠陥を利用して、サービス拒否（DoS）攻撃を実行することができます。
ユーザーが多くのリソースを占有することを制限するために、開発者は各コンテナがサポートできる内容をより明確に定義しようとするかもしれません。そのため、新しいコードには配置制約が含まれているかもしれません。
デプロイ：
リソース。
limits:
cpus:"0.5"
reservations:
cpus:"0.5"
placement:
constraints:
- "node.labels.limit_cpu == 100M"
- "node.labels.limit_memory == 0.5"
一見すると、これはビジネスロジックの欠陥を解決するように見えます。しかし、この新しい配置制約は、Dockerコンテナサービスのリソース使用制限には影響しません。コンテナをスケジュールするノードを選択するためにのみ使用されます。この場合、DoS攻撃はまだ可能です。攻撃者はまずDockerコンテナを侵害する必要がありますが、その後は制限なくリソースを消耗することができるでしょう。
このように、ビジネスロジックの欠陥を考え、それを排除するためにプログラミングすることは、難しいことです。
ビジネスロジックの不備を解消
ビジネスロジックの欠陥で重要なのは、その存在を知ることです。新しいコードが書かれている間は、それらを環境に入れないように注意を払う必要があります。ビジネスルールとベストプラクティスを明確に定義し、設計、実装、テストを含むアプリケーション開発プロセスのすべての段階でチェックする必要があります。
例えば、ビジネスロジックの欠陥によって上記の例のようなDoS攻撃が可能になるのを防ぐためには、作成したすべてのDockerコンテナが使用できるリソースの量を制限することがベストプラクティスです。具体的には、limitセクションで、Dockerコンテナが使用できるCPUの数とメモリの量を指定する必要があります。例としては、次のようになります。
デプロイ：
リソース。
limits:
cpus:"0.5"
memory: 100M
reservations:
cpus:"0.5"
memory:50M
上記の例のようなコードをポリシーとして使用することで、ビジネスロジック上の大きな欠陥を環境から取り除き、DoS攻撃を防ぐことができます。これは、仮に攻撃者がDockerコンテナの1つを侵害したとしても機能します。その場合でも、攻撃者はその足場を利用してリソースを枯渇させることはできません。
脅威のモデル化は、さまざまな攻撃がどのように行われるかを定義し、ビジネスロジックのルールを使用して攻撃を防止・制限することで有効です。また、コンプライアンスルールや既知の不正使用事例に基づいてテストを行うことで、見落としがちなビジネスロジックの欠陥を発見することができます。
ビジネスロジックの欠陥は、アプリケーションに忍び込む可能性のある最も巧妙な脆弱性の一つですが、注目を集める他のリスクに劣らず危険です。ビジネスロジックの欠陥がどのようにして発生するかを知り、ベストプラクティスを用いることで、アプリケーションの開発段階ではそのような脆弱性を排除することができ、本番環境ではそのような脆弱性を悪用する方法を熟知した攻撃者に悪用されることはありません。
をご覧ください。 Secure Code Warriorブログページでは、この脆弱性や、他のセキュリティ上の欠陥の被害から組織や顧客を守るための方法について、さらに詳しい情報が掲載されています。また、Secure Code Warrior トレーニングプラットフォームでは、このIaCチャレンジのデモを試すことができ、サイバーセキュリティに関するすべてのスキルを磨き上げ、最新の状態に保つことができます。
さて、これで（今のところ）終わりです。Infrastructure as Codeシリーズは今回で終了となります。Docker、Ansible、Kubernetes、Terraform、CloudFormationなどのセキュリティ問題を楽しく攻略していただけたでしょうか。
これで自分のスキルを試す準備ができたと思いますか？最後のゲーム化されたチャレンジをお試しください。
まだいくつかの点で不明な点がある場合は、読み進めてください。
今日、私たちが注目したい脆弱性は、ビジネスロジックの脆弱性です。これは、コーダーがビジネスロジックのルールを適切に実装しなかった場合に発生するもので、悪意のあるユーザがアプリケーションを悪用した場合、様々な種類の攻撃に対して脆弱になる可能性があります。各アプリケーションに実装されている目的や機能に応じて、ビジネスロジックの欠陥は、特権の昇格、不適切なリソースの使用、あるいは意図しない数多くのビジネスプロセスの実行を可能にするかもしれません。
多くの脆弱性とは異なり、ビジネスロジックルールの不正な実装は驚くほど巧妙です。そのため、アプリケーションやコードに紛れ込まないように、特別な注意を払う必要があります。
ビジネスロジックの欠陥の例としてはどのようなものがありますか？
ビジネスロジックの欠陥を誘発することがいかに簡単であるかの例として、Docker Composeファイルで定義されたDocker環境の次の例を考えてみましょう。コンテナが機能を実行できるように準備するために、開発者は次の例のようにDocker Composeファイルで定義された標準的なリソースポリシーを使用するかもしれません。
デプロイ：
リソース。
limits:
cpus:"0.5"
reservations:
cpus:"0.5"
表面的には問題ないように見えますが、このコンテナのリソースポリシーは、リソースの使用を適切に制限していません。攻撃者は、このビジネスロジックの欠陥を利用して、サービス拒否（DoS）攻撃を実行することができます。
ユーザーが多くのリソースを占有することを制限するために、開発者は各コンテナがサポートできる内容をより明確に定義しようとするかもしれません。そのため、新しいコードには配置制約が含まれているかもしれません。
デプロイ：
リソース。
limits:
cpus:"0.5"
reservations:
cpus:"0.5"
placement:
constraints:
- "node.labels.limit_cpu == 100M"
- "node.labels.limit_memory == 0.5"
一見すると、これはビジネスロジックの欠陥を解決するように見えます。しかし、この新しい配置制約は、Dockerコンテナサービスのリソース使用制限には影響しません。コンテナをスケジュールするノードを選択するためにのみ使用されます。この場合、DoS攻撃はまだ可能です。攻撃者はまずDockerコンテナを侵害する必要がありますが、その後は制限なくリソースを消耗することができるでしょう。
このように、ビジネスロジックの欠陥を考え、それを排除するためにプログラミングすることは、難しいことです。
ビジネスロジックの不備を解消
ビジネスロジックの欠陥で重要なのは、その存在を知ることです。新しいコードが書かれている間は、それらを環境に入れないように注意を払う必要があります。ビジネスルールとベストプラクティスを明確に定義し、設計、実装、テストを含むアプリケーション開発プロセスのすべての段階でチェックする必要があります。
例えば、ビジネスロジックの欠陥によって上記の例のようなDoS攻撃が可能になるのを防ぐためには、作成したすべてのDockerコンテナが使用できるリソースの量を制限することがベストプラクティスです。具体的には、limitセクションで、Dockerコンテナが使用できるCPUの数とメモリの量を指定する必要があります。例としては、次のようになります。
デプロイ：
リソース。
limits:
cpus:"0.5"
memory: 100M
reservations:
cpus:"0.5"
memory:50M
上記の例のようなコードをポリシーとして使用することで、ビジネスロジック上の大きな欠陥を環境から取り除き、DoS攻撃を防ぐことができます。これは、仮に攻撃者がDockerコンテナの1つを侵害したとしても機能します。その場合でも、攻撃者はその足場を利用してリソースを枯渇させることはできません。
脅威のモデル化は、さまざまな攻撃がどのように行われるかを定義し、ビジネスロジックのルールを使用して攻撃を防止・制限することで有効です。また、コンプライアンスルールや既知の不正使用事例に基づいてテストを行うことで、見落としがちなビジネスロジックの欠陥を発見することができます。
ビジネスロジックの欠陥は、アプリケーションに忍び込む可能性のある最も巧妙な脆弱性の一つですが、注目を集める他のリスクに劣らず危険です。ビジネスロジックの欠陥がどのようにして発生するかを知り、ベストプラクティスを用いることで、アプリケーションの開発段階ではそのような脆弱性を排除することができ、本番環境ではそのような脆弱性を悪用する方法を熟知した攻撃者に悪用されることはありません。
をご覧ください。 Secure Code Warriorブログページでは、この脆弱性や、他のセキュリティ上の欠陥の被害から組織や顧客を守るための方法について、さらに詳しい情報が掲載されています。また、Secure Code Warrior トレーニングプラットフォームでは、このIaCチャレンジのデモを試すことができ、サイバーセキュリティに関するすべてのスキルを磨き上げ、最新の状態に保つことができます。
以下のリンクをクリックし、この資料のPDFをダウンロードしてください。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
レポートを見るデモを予約する
Matias Madou, Ph.D. セキュリティ専門家、研究者、CTO兼共同設立者（Secure Code Warrior ）。Ghent大学でアプリケーションセキュリティの博士号を取得し、静的解析ソリューションに焦点を当てた。その後、米国Fortify社に入社し、開発者が安全なコードを書くことを支援せずに、コードの問題を検出するだけでは不十分であることに気づきました。開発者を支援し、セキュリティの負担を軽減し、お客様の期待を上回る製品を開発することを志すようになった。Team Awesomeの一員としてデスクワークをしていないときは、RSA Conference、BlackHat、DefConなどのカンファレンスでプレゼンテーションをするのが好きである。
マティアスは、15年以上のソフトウェアセキュリティの実務経験を持つ研究者・開発者です。フォーティファイ・ソフトウェア社や自身の会社（Sensei Security）などでソリューションを開発してきました。キャリアの中で、Matiasは、商用製品につながる複数のアプリケーションセキュリティ研究プロジェクトを主導し、10件以上の特許を取得しています。また、RSAカンファレンス、Black Hat、DefCon、BSIMM、OWASP AppSec、BruConなどの世界的なカンファレンスで定期的に講演を行っているほか、高度なアプリケーションセキュリティトレーニング（courses ）の講師も務めています。
Matiasはゲント大学でコンピュータ工学の博士号を取得し、アプリケーションの内部構造を隠すためのプログラム難読化によるアプリケーションセキュリティを研究しました。
さて、これで（今のところ）終わりです。Infrastructure as Codeシリーズは今回で終了となります。Docker、Ansible、Kubernetes、Terraform、CloudFormationなどのセキュリティ問題を楽しく攻略していただけたでしょうか。
これで自分のスキルを試す準備ができたと思いますか？最後のゲーム化されたチャレンジをお試しください。
まだいくつかの点で不明な点がある場合は、読み進めてください。
今日、私たちが注目したい脆弱性は、ビジネスロジックの脆弱性です。これは、コーダーがビジネスロジックのルールを適切に実装しなかった場合に発生するもので、悪意のあるユーザがアプリケーションを悪用した場合、様々な種類の攻撃に対して脆弱になる可能性があります。各アプリケーションに実装されている目的や機能に応じて、ビジネスロジックの欠陥は、特権の昇格、不適切なリソースの使用、あるいは意図しない数多くのビジネスプロセスの実行を可能にするかもしれません。
多くの脆弱性とは異なり、ビジネスロジックルールの不正な実装は驚くほど巧妙です。そのため、アプリケーションやコードに紛れ込まないように、特別な注意を払う必要があります。
ビジネスロジックの欠陥の例としてはどのようなものがありますか？
ビジネスロジックの欠陥を誘発することがいかに簡単であるかの例として、Docker Composeファイルで定義されたDocker環境の次の例を考えてみましょう。コンテナが機能を実行できるように準備するために、開発者は次の例のようにDocker Composeファイルで定義された標準的なリソースポリシーを使用するかもしれません。
デプロイ：
リソース。
limits:
cpus:"0.5"
reservations:
cpus:"0.5"
表面的には問題ないように見えますが、このコンテナのリソースポリシーは、リソースの使用を適切に制限していません。攻撃者は、このビジネスロジックの欠陥を利用して、サービス拒否（DoS）攻撃を実行することができます。
ユーザーが多くのリソースを占有することを制限するために、開発者は各コンテナがサポートできる内容をより明確に定義しようとするかもしれません。そのため、新しいコードには配置制約が含まれているかもしれません。
デプロイ：
リソース。
limits:
cpus:"0.5"
reservations:
cpus:"0.5"
placement:
constraints:
- "node.labels.limit_cpu == 100M"
- "node.labels.limit_memory == 0.5"
一見すると、これはビジネスロジックの欠陥を解決するように見えます。しかし、この新しい配置制約は、Dockerコンテナサービスのリソース使用制限には影響しません。コンテナをスケジュールするノードを選択するためにのみ使用されます。この場合、DoS攻撃はまだ可能です。攻撃者はまずDockerコンテナを侵害する必要がありますが、その後は制限なくリソースを消耗することができるでしょう。
このように、ビジネスロジックの欠陥を考え、それを排除するためにプログラミングすることは、難しいことです。
ビジネスロジックの不備を解消
ビジネスロジックの欠陥で重要なのは、その存在を知ることです。新しいコードが書かれている間は、それらを環境に入れないように注意を払う必要があります。ビジネスルールとベストプラクティスを明確に定義し、設計、実装、テストを含むアプリケーション開発プロセスのすべての段階でチェックする必要があります。
例えば、ビジネスロジックの欠陥によって上記の例のようなDoS攻撃が可能になるのを防ぐためには、作成したすべてのDockerコンテナが使用できるリソースの量を制限することがベストプラクティスです。具体的には、limitセクションで、Dockerコンテナが使用できるCPUの数とメモリの量を指定する必要があります。例としては、次のようになります。
デプロイ：
リソース。
limits:
cpus:"0.5"
memory: 100M
reservations:
cpus:"0.5"
memory:50M
上記の例のようなコードをポリシーとして使用することで、ビジネスロジック上の大きな欠陥を環境から取り除き、DoS攻撃を防ぐことができます。これは、仮に攻撃者がDockerコンテナの1つを侵害したとしても機能します。その場合でも、攻撃者はその足場を利用してリソースを枯渇させることはできません。
脅威のモデル化は、さまざまな攻撃がどのように行われるかを定義し、ビジネスロジックのルールを使用して攻撃を防止・制限することで有効です。また、コンプライアンスルールや既知の不正使用事例に基づいてテストを行うことで、見落としがちなビジネスロジックの欠陥を発見することができます。
ビジネスロジックの欠陥は、アプリケーションに忍び込む可能性のある最も巧妙な脆弱性の一つですが、注目を集める他のリスクに劣らず危険です。ビジネスロジックの欠陥がどのようにして発生するかを知り、ベストプラクティスを用いることで、アプリケーションの開発段階ではそのような脆弱性を排除することができ、本番環境ではそのような脆弱性を悪用する方法を熟知した攻撃者に悪用されることはありません。
をご覧ください。 Secure Code Warriorブログページでは、この脆弱性や、他のセキュリティ上の欠陥の被害から組織や顧客を守るための方法について、さらに詳しい情報が掲載されています。また、Secure Code Warrior トレーニングプラットフォームでは、このIaCチャレンジのデモを試すことができ、サイバーセキュリティに関するすべてのスキルを磨き上げ、最新の状態に保つことができます。
目次
Matias Madou, Ph.D. セキュリティ専門家、研究者、CTO兼共同設立者（Secure Code Warrior ）。Ghent大学でアプリケーションセキュリティの博士号を取得し、静的解析ソリューションに焦点を当てた。その後、米国Fortify社に入社し、開発者が安全なコードを書くことを支援せずに、コードの問題を検出するだけでは不十分であることに気づきました。開発者を支援し、セキュリティの負担を軽減し、お客様の期待を上回る製品を開発することを志すようになった。Team Awesomeの一員としてデスクワークをしていないときは、RSA Conference、BlackHat、DefConなどのカンファレンスでプレゼンテーションをするのが好きである。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、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.
セキュアコード・トレーニングのトピックと内容
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.
始めるためのリソース
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.
