コーダーがセキュリティインフラストラクチャをコードシリーズで制覇-信頼できないソースからのコンポーネントを使う
Infrastructure as Codeシリーズもそろそろ終わりに近づいてきましたが、皆さんのような開発者のIaCセキュリティの旅をお手伝いすることができてよかったです。
皆さんはチャレンジをプレイしていますか？これまでのところ、あなたのスコアは何点ですか？始める前に、信頼できないソースからのコンポーネントを使用することの落とし穴について、皆さんがどれだけ知っているか見てみましょう。
まだやることがある？続きを読む
今日、私たちが注目する脆弱性を誘発する行為は、信頼できないソースからのコードを使用することであり、一見良さそうに見える行為が大きな問題を引き起こしています。オープンソースのコードやリソースを使用することには多くの利点があります。一般的には、専門家が自分のアイデアや作業、さらには完成したコードをGitHubのようなリポジトリに投稿し、プログラムやアプリを適切に動作させようと奮闘している他の人々が利用できるようにすることができます。完成したコードを使ってプログラムの機能を管理することで、開発者は新しいアプリケーションを作成するたびに車輪を再発明する必要がなくなります。
しかし、信頼性のない、検証されていない、あるいは潜在的に危険なソースからコードスニペットを使用することは、多くのリスクを伴います。実際、信頼されていないソースからのコードを使用することは、大きなセキュリティ脆弱性と小さなセキュリティ脆弱性の両方が、他の安全なアプリケーションに忍び込む最も一般的な方法の1つです。これらの脆弱性は、作成者が誤って誘発することもあります。また、潜在的な攻撃者によって悪意のあるコードが書かれている場合もあります。また、潜在的な攻撃者によって悪意のあるコードが書かれ、そのコードを共有することで、そのコードをアプリケーションに落とし込む被害者が現れることもあります。
信頼できないソースからのコードの使用がなぜ危険なのか？
例えば、開発者が急ぎで開発中のアプリケーションを設定する必要があるとします。この作業は非常に難しいものです。そこで開発者は、可能な限りの設定を行うために多くの時間を費やす代わりに、Google検索を行い、一見完璧に見える設定ファイルを既に完成させている人を見つけます。開発者はそのコードを書いた人のことを何も知らなくても、新しいアプリケーションに追加することは比較的簡単です。それは、Docker環境で2行を使って行うことができます。
RUN cd /etc/apache2/sites-available/ && ˶ˆ꒳ˆ˵
wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/
9d372cfa8855a6be74bcca86efadfbbf/raw/˶ˆ꒳ˆ˵
fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf
これで、Dockerイメージがサードパーティの設定ファイルを動的に取り込むことになります。そして、そのファイルがテストされて問題ないことがわかったとしても、そのポインタが新しいアプリケーションのコードに組み込まれたということは、永続的な依存関係が存在することを意味します。数日後、数週間後、数ヶ月後に、元の作者やコードリポジトリを侵害した攻撃者によってファイルが変更される可能性があります。突然、共有された設定ファイルがアプリケーションに意図したものとは全く異なる動作を指示し、権限のないユーザにアクセスさせたり、あるいは直接データを盗んで流出させたりする可能性があります。
共有資源のより良い利用法
組織が外部ソースからのコードの使用を許可している場合、それが安全に行われることを保証するためのプロセスを導入する必要があります。外部のコードを使用する可能性を評価する際には、必ず安全なリンクを使用して公式のソースからコンポーネントを取得してください。その場合でも、外部のソースにリンクしてそのコードを取り込むことは絶対にしないでください。代わりに、承認されたコードは安全なライブラリに持ち込まれ、その保護された場所からのみ使用されるべきです。つまり、Docker環境では、コードは次のようになります。
src/config/default-ssl.conf /etc/apache2/sites-available/ をCOPYする。
リモートのサードパーティ製設定ファイルに頼るのではなく、それらのファイルのローカルコピーに頼ることになります。これにより、予期せぬ変更や悪意のある変更を防ぐことができます。
セキュアコードライブラリの使用に加えて、パッチ管理プロセスを導入し、ソフトウェアのライフサイクルを通じてコンポーネントを継続的に監視する必要があります。また、クライアント側とサーバ側のすべてのコンポーネントについて、NVDやCVEなどのツールを使用してセキュリティ警告をチェックする必要があります。最後に、使用されていない、または不要な依存関係や、外部のコードに付随してくる可能性のある機能を削除します。
これらの手順を踏むことで、開発者は、アプリケーションやコードに誤って脆弱性を誘発することなく、より安全に外部リソースを利用することができます。
をご覧ください。 Secure Code Warriorブログページでは、この脆弱性や、他のセキュリティ上の欠陥の被害から組織や顧客を守るための方法について、より詳しい情報が掲載されています。また、Secure Code Warrior トレーニングプラットフォームの IaC チャレンジのデモをお試しいただくことで、サイバーセキュリティに関するあらゆるスキルを磨き、最新の状態に保つことができます。
マティアス・マドゥ博士は、セキュリティ専門家、研究者、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などのグローバルカンファレンスで定期的に講演を行っています。
マティアスはゲント大学でコンピューター工学の博士号を取得し、そこでアプリケーションの内部動作を隠すためのプログラムの難読化によるアプリケーションセキュリティを学びました。
Infrastructure as Codeシリーズもそろそろ終わりに近づいてきましたが、皆さんのような開発者のIaCセキュリティの旅をお手伝いすることができてよかったです。
皆さんはチャレンジをプレイしていますか？これまでのところ、あなたのスコアは何点ですか？始める前に、信頼できないソースからのコンポーネントを使用することの落とし穴について、皆さんがどれだけ知っているか見てみましょう。
まだやることがある？続きを読む
今日、私たちが注目する脆弱性を誘発する行為は、信頼できないソースからのコードを使用することであり、一見良さそうに見える行為が大きな問題を引き起こしています。オープンソースのコードやリソースを使用することには多くの利点があります。一般的には、専門家が自分のアイデアや作業、さらには完成したコードをGitHubのようなリポジトリに投稿し、プログラムやアプリを適切に動作させようと奮闘している他の人々が利用できるようにすることができます。完成したコードを使ってプログラムの機能を管理することで、開発者は新しいアプリケーションを作成するたびに車輪を再発明する必要がなくなります。
しかし、信頼性のない、検証されていない、あるいは潜在的に危険なソースからコードスニペットを使用することは、多くのリスクを伴います。実際、信頼されていないソースからのコードを使用することは、大きなセキュリティ脆弱性と小さなセキュリティ脆弱性の両方が、他の安全なアプリケーションに忍び込む最も一般的な方法の1つです。これらの脆弱性は、作成者が誤って誘発することもあります。また、潜在的な攻撃者によって悪意のあるコードが書かれている場合もあります。また、潜在的な攻撃者によって悪意のあるコードが書かれ、そのコードを共有することで、そのコードをアプリケーションに落とし込む被害者が現れることもあります。
信頼できないソースからのコードの使用がなぜ危険なのか？
例えば、開発者が急ぎで開発中のアプリケーションを設定する必要があるとします。この作業は非常に難しいものです。そこで開発者は、可能な限りの設定を行うために多くの時間を費やす代わりに、Google検索を行い、一見完璧に見える設定ファイルを既に完成させている人を見つけます。開発者はそのコードを書いた人のことを何も知らなくても、新しいアプリケーションに追加することは比較的簡単です。それは、Docker環境で2行を使って行うことができます。
RUN cd /etc/apache2/sites-available/ && ˶ˆ꒳ˆ˵
wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/
9d372cfa8855a6be74bcca86efadfbbf/raw/˶ˆ꒳ˆ˵
fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf
これで、Dockerイメージがサードパーティの設定ファイルを動的に取り込むことになります。そして、そのファイルがテストされて問題ないことがわかったとしても、そのポインタが新しいアプリケーションのコードに組み込まれたということは、永続的な依存関係が存在することを意味します。数日後、数週間後、数ヶ月後に、元の作者やコードリポジトリを侵害した攻撃者によってファイルが変更される可能性があります。突然、共有された設定ファイルがアプリケーションに意図したものとは全く異なる動作を指示し、権限のないユーザにアクセスさせたり、あるいは直接データを盗んで流出させたりする可能性があります。
共有資源のより良い利用法
組織が外部ソースからのコードの使用を許可している場合、それが安全に行われることを保証するためのプロセスを導入する必要があります。外部のコードを使用する可能性を評価する際には、必ず安全なリンクを使用して公式のソースからコンポーネントを取得してください。その場合でも、外部のソースにリンクしてそのコードを取り込むことは絶対にしないでください。代わりに、承認されたコードは安全なライブラリに持ち込まれ、その保護された場所からのみ使用されるべきです。つまり、Docker環境では、コードは次のようになります。
src/config/default-ssl.conf /etc/apache2/sites-available/ をCOPYする。
リモートのサードパーティ製設定ファイルに頼るのではなく、それらのファイルのローカルコピーに頼ることになります。これにより、予期せぬ変更や悪意のある変更を防ぐことができます。
セキュアコードライブラリの使用に加えて、パッチ管理プロセスを導入し、ソフトウェアのライフサイクルを通じてコンポーネントを継続的に監視する必要があります。また、クライアント側とサーバ側のすべてのコンポーネントについて、NVDやCVEなどのツールを使用してセキュリティ警告をチェックする必要があります。最後に、使用されていない、または不要な依存関係や、外部のコードに付随してくる可能性のある機能を削除します。
これらの手順を踏むことで、開発者は、アプリケーションやコードに誤って脆弱性を誘発することなく、より安全に外部リソースを利用することができます。
をご覧ください。 Secure Code Warriorブログページでは、この脆弱性や、他のセキュリティ上の欠陥の被害から組織や顧客を守るための方法について、より詳しい情報が掲載されています。また、Secure Code Warrior トレーニングプラットフォームの IaC チャレンジのデモをお試しいただくことで、サイバーセキュリティに関するあらゆるスキルを磨き、最新の状態に保つことができます。
Infrastructure as Codeシリーズもそろそろ終わりに近づいてきましたが、皆さんのような開発者のIaCセキュリティの旅をお手伝いすることができてよかったです。
皆さんはチャレンジをプレイしていますか？これまでのところ、あなたのスコアは何点ですか？始める前に、信頼できないソースからのコンポーネントを使用することの落とし穴について、皆さんがどれだけ知っているか見てみましょう。
まだやることがある？続きを読む
今日、私たちが注目する脆弱性を誘発する行為は、信頼できないソースからのコードを使用することであり、一見良さそうに見える行為が大きな問題を引き起こしています。オープンソースのコードやリソースを使用することには多くの利点があります。一般的には、専門家が自分のアイデアや作業、さらには完成したコードをGitHubのようなリポジトリに投稿し、プログラムやアプリを適切に動作させようと奮闘している他の人々が利用できるようにすることができます。完成したコードを使ってプログラムの機能を管理することで、開発者は新しいアプリケーションを作成するたびに車輪を再発明する必要がなくなります。
しかし、信頼性のない、検証されていない、あるいは潜在的に危険なソースからコードスニペットを使用することは、多くのリスクを伴います。実際、信頼されていないソースからのコードを使用することは、大きなセキュリティ脆弱性と小さなセキュリティ脆弱性の両方が、他の安全なアプリケーションに忍び込む最も一般的な方法の1つです。これらの脆弱性は、作成者が誤って誘発することもあります。また、潜在的な攻撃者によって悪意のあるコードが書かれている場合もあります。また、潜在的な攻撃者によって悪意のあるコードが書かれ、そのコードを共有することで、そのコードをアプリケーションに落とし込む被害者が現れることもあります。
信頼できないソースからのコードの使用がなぜ危険なのか？
例えば、開発者が急ぎで開発中のアプリケーションを設定する必要があるとします。この作業は非常に難しいものです。そこで開発者は、可能な限りの設定を行うために多くの時間を費やす代わりに、Google検索を行い、一見完璧に見える設定ファイルを既に完成させている人を見つけます。開発者はそのコードを書いた人のことを何も知らなくても、新しいアプリケーションに追加することは比較的簡単です。それは、Docker環境で2行を使って行うことができます。
RUN cd /etc/apache2/sites-available/ && ˶ˆ꒳ˆ˵
wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/
9d372cfa8855a6be74bcca86efadfbbf/raw/˶ˆ꒳ˆ˵
fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf
これで、Dockerイメージがサードパーティの設定ファイルを動的に取り込むことになります。そして、そのファイルがテストされて問題ないことがわかったとしても、そのポインタが新しいアプリケーションのコードに組み込まれたということは、永続的な依存関係が存在することを意味します。数日後、数週間後、数ヶ月後に、元の作者やコードリポジトリを侵害した攻撃者によってファイルが変更される可能性があります。突然、共有された設定ファイルがアプリケーションに意図したものとは全く異なる動作を指示し、権限のないユーザにアクセスさせたり、あるいは直接データを盗んで流出させたりする可能性があります。
共有資源のより良い利用法
組織が外部ソースからのコードの使用を許可している場合、それが安全に行われることを保証するためのプロセスを導入する必要があります。外部のコードを使用する可能性を評価する際には、必ず安全なリンクを使用して公式のソースからコンポーネントを取得してください。その場合でも、外部のソースにリンクしてそのコードを取り込むことは絶対にしないでください。代わりに、承認されたコードは安全なライブラリに持ち込まれ、その保護された場所からのみ使用されるべきです。つまり、Docker環境では、コードは次のようになります。
src/config/default-ssl.conf /etc/apache2/sites-available/ をCOPYする。
リモートのサードパーティ製設定ファイルに頼るのではなく、それらのファイルのローカルコピーに頼ることになります。これにより、予期せぬ変更や悪意のある変更を防ぐことができます。
セキュアコードライブラリの使用に加えて、パッチ管理プロセスを導入し、ソフトウェアのライフサイクルを通じてコンポーネントを継続的に監視する必要があります。また、クライアント側とサーバ側のすべてのコンポーネントについて、NVDやCVEなどのツールを使用してセキュリティ警告をチェックする必要があります。最後に、使用されていない、または不要な依存関係や、外部のコードに付随してくる可能性のある機能を削除します。
これらの手順を踏むことで、開発者は、アプリケーションやコードに誤って脆弱性を誘発することなく、より安全に外部リソースを利用することができます。
をご覧ください。 Secure Code Warriorブログページでは、この脆弱性や、他のセキュリティ上の欠陥の被害から組織や顧客を守るための方法について、より詳しい情報が掲載されています。また、Secure Code Warrior トレーニングプラットフォームの IaC チャレンジのデモをお試しいただくことで、サイバーセキュリティに関するあらゆるスキルを磨き、最新の状態に保つことができます。
以下のリンクをクリックして、このリソースのPDFをダウンロードしてください。
Secure Code Warriorは、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする文化を築くお手伝いをします。アプリケーションセキュリティマネージャー、開発者、CISO、またはセキュリティ関係者であるかに関わらず、安全でないコードに関連するリスクを軽減するお手伝いをします。
レポートを表示デモを予約
マティアス・マドゥ博士は、セキュリティ専門家、研究者、CTO、セキュア・コード・ウォリアーの共同創設者です。マティアスはゲント大学で静的解析ソリューションを中心としたアプリケーションセキュリティの博士号を取得しました。その後、米国のFortifyに入社し、開発者が安全なコードを書くのを手助けせずに、コードの問題を検出するだけでは不十分であることに気づきました。これがきっかけで、開発者を支援し、セキュリティの負担を軽減し、顧客の期待を超える製品を開発するようになりました。Team Awesomeの一員としてデスクにいない時は、RSAカンファレンス、BlackHat、DefConなどのカンファレンスでプレゼンテーションを行うステージでのプレゼンテーションを楽しんでいます。
マティアスは、15年以上のソフトウェアセキュリティの実務経験を持つ研究者および開発者です。フォーティファイ・ソフトウェアや自身の会社であるセンセイ・セキュリティなどの企業向けにソリューションを開発してきました。マティアスはキャリアを通じて、複数のアプリケーションセキュリティ研究プロジェクトを主導し、それが商用製品につながり、10件以上の特許を取得しています。デスクから離れている時には、上級アプリケーション・セキュリティ・トレーニング・コースの講師を務め、RSA Conference、Black Hat、DefCon、BSIMM、OWASP AppSec、BruConなどのグローバルカンファレンスで定期的に講演を行っています。
マティアスはゲント大学でコンピューター工学の博士号を取得し、そこでアプリケーションの内部動作を隠すためのプログラムの難読化によるアプリケーションセキュリティを学びました。
Infrastructure as Codeシリーズもそろそろ終わりに近づいてきましたが、皆さんのような開発者のIaCセキュリティの旅をお手伝いすることができてよかったです。
皆さんはチャレンジをプレイしていますか？これまでのところ、あなたのスコアは何点ですか？始める前に、信頼できないソースからのコンポーネントを使用することの落とし穴について、皆さんがどれだけ知っているか見てみましょう。
まだやることがある？続きを読む
今日、私たちが注目する脆弱性を誘発する行為は、信頼できないソースからのコードを使用することであり、一見良さそうに見える行為が大きな問題を引き起こしています。オープンソースのコードやリソースを使用することには多くの利点があります。一般的には、専門家が自分のアイデアや作業、さらには完成したコードをGitHubのようなリポジトリに投稿し、プログラムやアプリを適切に動作させようと奮闘している他の人々が利用できるようにすることができます。完成したコードを使ってプログラムの機能を管理することで、開発者は新しいアプリケーションを作成するたびに車輪を再発明する必要がなくなります。
しかし、信頼性のない、検証されていない、あるいは潜在的に危険なソースからコードスニペットを使用することは、多くのリスクを伴います。実際、信頼されていないソースからのコードを使用することは、大きなセキュリティ脆弱性と小さなセキュリティ脆弱性の両方が、他の安全なアプリケーションに忍び込む最も一般的な方法の1つです。これらの脆弱性は、作成者が誤って誘発することもあります。また、潜在的な攻撃者によって悪意のあるコードが書かれている場合もあります。また、潜在的な攻撃者によって悪意のあるコードが書かれ、そのコードを共有することで、そのコードをアプリケーションに落とし込む被害者が現れることもあります。
信頼できないソースからのコードの使用がなぜ危険なのか？
例えば、開発者が急ぎで開発中のアプリケーションを設定する必要があるとします。この作業は非常に難しいものです。そこで開発者は、可能な限りの設定を行うために多くの時間を費やす代わりに、Google検索を行い、一見完璧に見える設定ファイルを既に完成させている人を見つけます。開発者はそのコードを書いた人のことを何も知らなくても、新しいアプリケーションに追加することは比較的簡単です。それは、Docker環境で2行を使って行うことができます。
RUN cd /etc/apache2/sites-available/ && ˶ˆ꒳ˆ˵
wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/
9d372cfa8855a6be74bcca86efadfbbf/raw/˶ˆ꒳ˆ˵
fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf
これで、Dockerイメージがサードパーティの設定ファイルを動的に取り込むことになります。そして、そのファイルがテストされて問題ないことがわかったとしても、そのポインタが新しいアプリケーションのコードに組み込まれたということは、永続的な依存関係が存在することを意味します。数日後、数週間後、数ヶ月後に、元の作者やコードリポジトリを侵害した攻撃者によってファイルが変更される可能性があります。突然、共有された設定ファイルがアプリケーションに意図したものとは全く異なる動作を指示し、権限のないユーザにアクセスさせたり、あるいは直接データを盗んで流出させたりする可能性があります。
共有資源のより良い利用法
組織が外部ソースからのコードの使用を許可している場合、それが安全に行われることを保証するためのプロセスを導入する必要があります。外部のコードを使用する可能性を評価する際には、必ず安全なリンクを使用して公式のソースからコンポーネントを取得してください。その場合でも、外部のソースにリンクしてそのコードを取り込むことは絶対にしないでください。代わりに、承認されたコードは安全なライブラリに持ち込まれ、その保護された場所からのみ使用されるべきです。つまり、Docker環境では、コードは次のようになります。
src/config/default-ssl.conf /etc/apache2/sites-available/ をCOPYする。
リモートのサードパーティ製設定ファイルに頼るのではなく、それらのファイルのローカルコピーに頼ることになります。これにより、予期せぬ変更や悪意のある変更を防ぐことができます。
セキュアコードライブラリの使用に加えて、パッチ管理プロセスを導入し、ソフトウェアのライフサイクルを通じてコンポーネントを継続的に監視する必要があります。また、クライアント側とサーバ側のすべてのコンポーネントについて、NVDやCVEなどのツールを使用してセキュリティ警告をチェックする必要があります。最後に、使用されていない、または不要な依存関係や、外部のコードに付随してくる可能性のある機能を削除します。
これらの手順を踏むことで、開発者は、アプリケーションやコードに誤って脆弱性を誘発することなく、より安全に外部リソースを利用することができます。
をご覧ください。 Secure Code Warriorブログページでは、この脆弱性や、他のセキュリティ上の欠陥の被害から組織や顧客を守るための方法について、より詳しい情報が掲載されています。また、Secure Code Warrior トレーニングプラットフォームの IaC チャレンジのデモをお試しいただくことで、サイバーセキュリティに関するあらゆるスキルを磨き、最新の状態に保つことができます。
目次
マティアス・マドゥ博士は、セキュリティ専門家、研究者、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)
