セキュリティを制する者たち 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、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
デモを予約するダウンロード始めるためのリソース
セキュア・バイ・デザインベストプラクティスの定義、開発者の能力向上、予防的セキュリティ成果のベンチマーク
このリサーチペーパーでは、Secure Code Warrior 共同設立者であるピーテル・ダニュー（Pieter Danhieux）氏とマティアス・マドゥ（Matias Madou）博士、そして専門家であるクリス・イングリス（Chris Inglis）氏（元米国サイバーディレクター、現パラディン・キャピタル・グループ戦略顧問）、デヴィン・リンチ（Devin Lynch）氏（パラディン・グローバル・インスティテュート・シニアディレクター）が、CISO、アプリケーション・セキュリティ担当副社長、ソフトウェア・セキュリティの専門家など、企業のセキュリティ・リーダー20人以上への詳細なインタビューから得られた主な知見を明らかにします。
セキュリティ スキルのベンチマーク: 企業におけるセキュアな設計の合理化
セキュアバイデザイン（SBD）構想の成功に関する有意義なデータを見つけることは、非常に困難である。CISO は、セキュリティプログラム活動の投資収益率（ROI）とビジネス価値を、従業員レベルと企業レベルの両方で証明しようとすると、しばしば困難に直面します。言うまでもなく、企業にとって、現在の業界標準に対して自社の組織がどのようにベンチマークされているかを把握することは特に困難です。大統領の国家サイバーセキュリティ戦略は、関係者に「デザインによるセキュリティとレジリエンスを受け入れる」ことを求めている。セキュアバイデザインの取り組みを成功させる鍵は、開発者にセキュアなコードを保証するスキルを与えるだけでなく、規制当局にそれらのスキルが整っていることを保証することである。本プレゼンテーションでは、25万人以上の開発者から収集した社内データ、データに基づく顧客の洞察、公的研究など、複数の一次ソースから得られた無数の定性的・定量的データを紹介します。こうしたデータ・ポイントの集積を活用することで、複数の業種におけるセキュア・バイ・デザイン・イニシアチブの現状をお伝えすることを目的としています。本レポートでは、この領域が現在十分に活用されていない理由、スキルアッププログラムの成功がサイバーセキュリティのリスク軽減に与える大きな影響、コードベースから脆弱性のカテゴリーを排除できる可能性について詳述しています。
始めるためのリソース
明らかになった：サイバー業界はセキュア・バイ・デザインをどのように定義しているか
最新のホワイトペーパーでは、当社の共同設立者であるピーテル・ダニュー（Pieter Danhieux）氏とマティアス・マドゥ（Matias Madou）博士が、CISO、AppSecリーダー、セキュリティ専門家を含む20人以上の企業セキュリティリーダーと対談し、このパズルの重要なピースを見つけ出し、Secure by Design運動の背後にある現実を明らかにしました。セキュア・バイ・デザインは、セキュリティ・チーム全体で共有された野心ですが、共有されたプレイブックはありません。
