ソフトウェアサプライチェーンセキュリティ：ゴールデンパイプラインへの道のり #aqua #セキュリティ #ソフトウェアサプライチェーン
この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。
本ブログは「Aqua Security」社の技術ブログで2023年1月11日に公開された「 Supply Chain Security: Shifting Left to the Golden Pipeline 」の日本語翻訳です。
ソフトウェアサプライチェーンセキュリティ：ゴールデンパイプラインへの道のり
Security Magazine の記事によると、98% の組織がサプライチェーンにおけるサイバーセキュリティ侵害によって悪影響を受けたことがあるそうです。Aqua の2021年ソフトウェアサプライチェーンセキュリティレビューでは、「攻撃者は、マルウェアやバックドアを配布するために、オープンソースの脆弱性やポイズニング、コードの整合性の問題、ソフトウェアサプライチェーンのプロセスやサプライヤーの信頼の悪用に大きく焦点を当てている」と指摘しています。このレポートはまた、彼らが評価したほぼすべての企業が、「サプライチェーン攻撃にさらされる可能性のある脆弱性や設定ミスを抱えている」ことも発見しました。これらの調査結果は、ビジネスが求めるセキュリティと、DevOps が求めるアジリティとスピードの間に、重大な脅威と断絶があることを示しています。
より迅速なデリバリーとサイクルタイムの短縮というビジネスへの期待から、開発チームは自然に CI/CD のプラクティスを受け入れ、採用するようになりました。DevOps は、開発サイクルを短縮し、組織を機敏にし、イノベーションのペースを維持可能にするため設計されました。多くの DevOps チームは、クラウドネイティブテクノロジーとプラクティスを活用することで、これを実現しています。課題は、これらのプラクティスが、各アプリケーションに数百から数千のオープンソースパッケージを使用するなど、多くのサードパーティコンポーネントに依存していることです。そのため、組織は、使用するコンポーネントがどのように開発、統合、配備、保守されているかを可視化し、理解する必要性に迫られます。これを疎かにすると、脆弱性を抱えてしまい、コンポーネントのセキュリティ確保ができず、そして最終的には侵害につながります。
攻撃者は、ターゲットに侵入する最良の方法の1つは、サプライチェーンを介してバックドアを見つけることであることを知っています。今日のソフトウェアのほとんどはゼロから書かれておらず、攻撃者は、ほとんどのソフトウェアアーティファクトが多くのオープンソースコードを含んでいるという事実を利用しています。サードパーティーは通常、企業独自のソースコードよりもセキュリティが低いため、これらは悪質な業者が環境に侵入するための確実な方法となります。ソフトウェアに変更が加えられたり、コードに欠陥があったり、パッチが適用されていないソフトウェアがあると、企業はセキュリティ上の問題を抱えやすくなり、ドアが開いたままになってしまいます。
プライベートは安全ではない
「ゴールデン(黄金)」とは、最終形にあるものを意味し、不変で信頼できる完全体を彷彿とさせます。
DevOps がクラウドに移行し続ける中、多様なツール、プラットフォーム、コンテナ、そして使用される複雑なエコシステムが、リスクのかたまりを作り出しています。アプリケーション開発の考え方では、ゴールデンイメージの考え方はよく知られています。システムまたはアプリケーションを構成するための一貫した信頼できるベースラインで、開発を効率化できます。ゴールデンイメージを導入することで、より迅速な導入、パッチ適用、設定が可能になり、ヒューマンエラーや本番環境における変更を減らすことができるという考え方です。
同じコンセプトを開発パイプラインの構築にも適用してみてはどうでしょうか。プライベートリポジトリでプロジェクトを開始する従来のパイプラインはまだ多く存在します。懸念されるのは、プライベートリポジトリに作成されるプロジェクト以外では、事前の議論やセキュリティがほとんど構築されていない状態で行われる可能性があることです。プライベートだからセキュアということではありません。そこで、私たちは「ゴールデンパイプライン」を提案します。これは、デフォルトでセキュアであり、既存の開発運用モデルの中で機能するパイプラインです。この方法では、セキュリティはアプリケーションに組み込まれ、各段階で検証されるため、本番環境に到達する頃には、すでに限りなくクリーンな状態になっています。
シフトレフトセキュリティを取り込む
このゴールデンイメージが持つ意味合いは、DevOps におけるセキュリティの理想的な解決策というだけではありません。シフトレフトという言葉もよく使われます。セキュリティの統合を議論する際に、使い古されていると言う人もいるでしょう。しかし、「シフトレフト」で言われていることの実態はどうなのでしょうか。
それは、セキュリティを方向ではなく、時間で見ることではないのでしょうか。つまり、セキュリティの議論を時間軸の左側、プロセスの早い段階に移すことです。外的要因で開発が止まったり、プロジェクトに多大な作業が追加され、チーム間の摩擦が起こる前に、問題になりそうなことを最初の段階で見つけることです。分析を左に、検証を右にシフトするようなものだと考えてください。セキュリティに早くから目を向け、後で問題が起きないようにするのです。
その方法は、事前にチームと協力し、セキュリティ対策とポリシーをパイプラインに組み込み、プロジェクト開始前に全員が合意する文書とプロセスを用意することです。
セキュリティと開発の一体化
一貫した「シフトレフト」の実践と「ゴールデンパイプライン」の確立を目指す多くの DevOps チームとセキュリティチームにとって、最も侵入しにくく、かつ安全なポリシーを導入するための合意形成は困難です。サプライチェーンに関する懸念が高まる中、チーム全体でセキュリティを実行するために今調整しておくことは、後の成功を左右することになります。しかし、どのようにセキュリティを強化すればよいのでしょうか。それは、「コミュニケーション」と「フィードバック」です。
開発者を巻き込まずにセキュリティを強化することは、プロジェクトを失敗させることになります。各チームは、自分たちの仕事のやり方に特有の微妙なニュアンスを持っています。あるチームにとって重大なリスクとなるルールを実施しても、別のチームには何の影響もない場合があります。
この問題を解決するために、私たちは2段階のポリシーを推奨しています。1段階目は、一般的な会社のポリシー、標準的なルールです。このタイプは一般的なリスクであり、重く取り締まられることはありません。2段階目は、あなたが強制したいことであれば何でもいいのです。これは粒度の細かいものであるべきです。セキュリティフローにニュアンスを組み込み、主要な利害関係者に役割ベースのアクセス制御と、その範囲に沿った権限を提供します。これにより、チームや利害関係者がポリシーを作成し、責任共有モデルを実現できます。
Aquaを利用してより良い関係を築くために
ソースコードは、アプリケーションの最大の攻撃対象です。ソースコードは、数百万行のコードと複雑な外部依存関係から構成されることがあり、変更のたびにその信頼性を検証する必要があります。リスクをスキャンするためのツールはありますが、すべてをカバーできるわけではありません。
ソフトウェアサプライチェーンセキュリティは、オープンソースライブラリ、商用ソフトウェアベンダー、外部委託開発などのサードパーティを通じて自社のソフトウェアへインストールされるデジタルアーティファクトに関連するリスクを検出、特定、分析、軽減するのに役立ちます。包括的なサプライチェーンセキュリティ戦略は、リスクマネジメントとサイバーセキュリティの原則を組み合わせて、サプライチェーンのリスクを評価し、ブロック、軽減、修復するための対策を実施し、他のツールが見逃している可能性があるものを確認します。
次のプロジェクトの早い段階で包括的なセキュリティテストと堅牢なポリシー主導の制御を組み込むことにより、DevOps パイプラインにおけるアプリケーションの安全な開発と展開を自動化する方法を学びましょう。
Microsoft のスティーブン=グリフィス氏(Cloud Native Principal Specialist & Global Black Belt)と私が、どのようにシフトレフトの実践とゴールデンパイプラインを作ることができるかについて、詳しく説明するウェビナー「Making Security Easier for Your Developer Pipeline」をご覧ください。
- ソフトウェアサプライチェーンに関する問題の特定
- チーム横断的に機能する標準の導入
- 統合的なチェックによりセキュリティ状態を向上させる
- 開発者用ツールを活用して フィードバックループを確保し、 セキュリティをプロセスの一部とする
