セキュリティを制する者たち Infrastructure as Code シリーズ - 信頼できないソースからのコンポーネントの使用
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 チャレンジのデモをお試しいただくことで、サイバーセキュリティに関するあらゆるスキルを磨き、最新の状態に保つことができます。
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シリーズもそろそろ終わりに近づいてきましたが、皆さんのような開発者の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 は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。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シリーズもそろそろ終わりに近づいてきましたが、皆さんのような開発者の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 チャレンジのデモをお試しいただくことで、サイバーセキュリティに関するあらゆるスキルを磨き、最新の状態に保つことができます。
目次
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.
始めるためのリソース
.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.