Coders Conquer Security Infrastructure as Codeシリーズ - 信頼できないソースからのコンポーネントの使用
「Infrastructure as Code（IaC）」シリーズも終盤に差し掛かりましたが、皆さんのような開発者のIaCセキュリティの旅をサポートできたことを嬉しく思います。
チャレンジには挑戦しましたか？現在のスコアはどうでしょう？本題に入る前に、信頼できないソースからのコンポーネントを使用する際のリスクについて、どれくらい理解しているか確認してみましょう。
まだ不安な点がありますか？続きを読んでみましょう。
今回焦点を当てる脆弱性を招く行為は、信頼できないソースからのコードの使用です。一見無害に見えるこの慣行が、大きな問題を引き起こしています。オープンソースのコードやリソースを利用することには多くの利点があります。一般的に、専門家が自身のアイデアや成果物、完成したコードをGitHubなどのリポジトリに公開することで、プログラムやアプリの開発に苦労している他の開発者がそれを活用できるようになります。完成したコードをプログラムの機能に組み込むことで、開発者は毎回ゼロから作り直す手間を省くことができます。
しかし、信頼性が低く、精査されていない、あるいは危険な可能性のあるソースからコードスニペットを使用することには大きなリスクが伴います。実際、信頼できないソースからのコード使用は、安全であるはずのアプリケーションに大小さまざまなセキュリティ脆弱性が入り込む最も一般的な経路の一つです。脆弱性は作成者の不注意によって生じることもあれば、攻撃者が悪意を持ってコードを書き込むケースもあります。後者の場合、そのコードは、それを利用する被害者を罠にかけることを目的として共有されます。
なぜ信頼できないソースからのコード使用は危険なのでしょうか？
例えば、開発者が急いでアプリケーションの設定を行わなければならない状況を想像してください。設定作業は複雑になりがちです。そこで、時間をかけてすべての設定を検討する代わりに、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環境であれば、コードは以下のようになります。
COPY src/config/default-ssl.conf /etc/apache2/sites-available/
リモートのサードパーティ設定ファイルに依存するのではなく、ローカルにコピーしたファイルを使用します。これにより、予期せぬ変更や悪意のある改ざんを防ぐことができます。
安全なコードライブラリの使用に加え、ソフトウェアのライフサイクル全体を通じてコンポーネントを継続的に監視するパッチ管理プロセスを導入してください。また、NVDやCVEなどのツールを使用して、クライアントおよびサーバー側のすべてのコンポーネントのセキュリティアラートを確認しましょう。最後に、外部コードに付随する不要な依存関係や機能は削除してください。
これらの手順に従うことで、開発者は外部リソースをより安全に活用し、アプリケーションやコードに誤って脆弱性を持ち込むリスクを回避できます。
この脆弱性に関する詳細や、他のセキュリティ上の欠陥から組織や顧客を守る方法については、Secure Code Warriorのブログをご覧ください。また、Secure Code WarriorトレーニングプラットフォームでIaCチャレンジのデモを試して、サイバーセキュリティスキルを常に最新の状態に保ちましょう。
AI主導の開発をリリース前にガバナンスする
AIを活用したリスク測定、コミット時のセキュアコーディングポリシーの強制、そしてSDLC全体を通じたセキュアなデリバリーの加速を実現します。
他のブログ記事を見る
セキュアコーディング、AIガバナンス、ソフトウェアリスク管理に関する専門的なコンテンツをご覧ください。
%252520%252520(3).avif)
Supercharged Security Awareness: How Tournaments are Inspiring Developers at Erste Group
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.
Security as culture: How Blue Prism cultivates world-class secure developers
Learn how Blue Prism, the global leader in intelligent automation for the enterprise, used Secure Code Warrior's agile learning platform to create a security-first culture with their developers, achieve their business goals, and ship secure code at speed
.avif)
AIを活用した開発をリリース前にセキュアに
開発者のリスクを可視化し、ポリシーを適用することで、ソフトウェア開発ライフサイクル全体における脆弱性を未然に防ぎます。
