継続的保証: ソフトウェア サプライ チェーン セキュリティの不可欠な実践

この これは、新しい NIST SP 800-218 ガイドラインを検討する一連の記事の XNUMX 番目です。最初の記事が見つかるかもしれません こちら.

継続的な保証:
ソフトウェア サプライ チェーン セキュリティの不可欠な実践

前回の記事で説明したように、米国国立標準技術研究所 (NIST) によって確立されたガイドラインは、ソフトウェア製品とサービスが米国政府に提供される方法を劇的に変えることになります。 

具体的には、 NIST SP 800-218 すべてのソフトウェア開発ライフサイクル (SDLC) に統合される一連の高レベルの安全なソフトウェア開発実践を確立します。ソフトウェア サプライ チェーン全体にこれらの慣行を組み込むことで、米国政府だけでなく、最終的には業界全体、世界中に提供するためのより安全な製品とサービスが促進されることが期待されます。 

この記事では、これらの新しい要件を満たす際の継続的保証 (CA) の重要な役割について説明します。 

概要: 継続的保証とは何ですか?またその仕組みは何ですか? 

CA は、継続的インテグレーション、開発、テストという DevOps 分野のすでによく知られた概念を補完する概念であり、作成中の一連のソリューションです。 CA は、最終的なソフトウェア製品のセキュリティに影響を与える可能性のある、製品のビルドや展開などの開発ライフ サイクルのすべてのイベントに関する証拠をきめ細かく収集します。これは、ソフトウェアの消費者 (ユーザー、購入者、その他のリスク関係者など) が、使用する製品からのリスクを制御するための手段です。 

現在、企業は開発するソフトウェア製品のセキュリティを向上させるために、無数のセキュリティ ツールを適用しています。ただし、これらのツールを一貫して使用するための標準を設定するために全体的なポリシーを使用することはほとんどありません。さらに、ソフトウェア製品の消費者が別の組織の場合、リスクの基準を設定するために必要な情報やツールをまったく持っていません。一言で言えば、これは CA が払拭しようとしているソフトウェア サプライ チェーンの盲点です。 

CA の直接の結果は、ソフトウェア製品が改ざんされていないこと、および開発中に重要なセキュリティ関連のテストが実行されたことを保証する手段ですが、そこから得られるものはそれだけではありません。

攻撃者による改ざんや、禁止国などの出所が疑わしい内部コンポーネントのベンダーによる隠蔽を阻止するために、CA は収集した証拠を、情報に暗号で署名し、不変のストアに保存することで、改ざん耐性のある証明書に変換します。隔離された安全な環境。 

収集された証拠を機械で読み取り可能にすることにより、ポリシー エンジンは、製品バージョンまたはアップデートごとにリスク関係者によって設定された基準またはルールを継続的に検証できます。このようにして、関係者は製品がセキュリティ基準に準拠していることを保証できます。 

概念的には、CA 手法を使用すると製品の品質も向上します。特定の製品のパイプラインの集中ポリシーを使用してコード レビューとセキュリティ テストのベースライン標準を制御することで、不整合や秩序あるプロセスに対するその場限りの変更が排除されます。

なぜ連続なのか?

開発プロセスにおけるセキュリティ構成は新しいものではありません。たとえば、脆弱性スキャンなしではバイナリが本番環境に移行しないことをすでに確立している可能性があります。 

現在、ソフトウェアの配信サイクルはますます短くなってきています。その結果、角が切れる可能性があります。コードレビューが省略されたり、セキュリティテストや重要な手順が実行されない可能性があります。さらに、新しい CVE とエクスプロイトが常に報告され、新しいコンポーネント バージョンが常に公開されます。 

これらすべての要素を組み合わせると、設定されたセキュリティ標準に照らしてコンポーネントを継続的にテストし、使用されているプロセスがセキュリティ ポリシーに準拠していることを確認することが義務付けられます。 

セキュリティ ポリシーはリスク ホルダーによって決定されます。使用できるポリシー ルールの例をいくつか示します。 

• 承認されたリストにあるオープンソース パッケージのみの使用を許可する
• プル リクエストごとに 2 人のレビュー担当者が必要です。
• 最終成果物内のすべての独自コンポーネントがソース管理リポジトリまで追跡できることを確認します。

ソフトウェアのセキュリティ水準を上げる

ソフトウェア サプライ チェーン攻撃は、ソフトウェア コンポーネントの予期される動作を変化させます。現在、これらの攻撃は、ソフトウェア コンポーネントの整合性を検証するソフトウェアの消費者と生産者の両方の能力の欠如に依存しています。 

ただし、オープンソースの依存関係から最終製品に至るまで、開発ライフサイクルのあらゆる部分からの証拠に署名し、この証拠を予想されるものと継続的に比較することにより、攻撃者はファイル、ツール、またはファイルを改ざんしようとするときに、より大きな困難に直面することになります。 CI/CD パイプラインの予期される動作。     

証拠の収集: 例と推奨事項

SDLC に従って収集できる証拠の例をいくつか示します。

この証拠を使用して利用できるポリシーの種類は次のとおりです。

継続的コード保証の将来

2022 年 XNUMX 月の安全なソフトウェア開発フレームワーク (SSDF）、NIST は、開発プロセス全体にわたるセキュリティ ツールの実装は自動化に大きく依存する必要があると示唆しています。継続的保証に対する当社のアプローチは、この推奨事項と一致しています。 

すべてのセキュリティ手順と安全対策が正しく構成されていると確信している場合でも、セキュリティ ポリシーが一貫して継続的に適用されていることを顧客とサプライヤーに保証する手段を提供する必要があります。すべての利害関係者、ソフトウェア作成者 (開発者またはベンダー)、および消費者 (ユーザーまたは購入者) は、ソフトウェア サプライ チェーンの各リンクからの証拠を継続的かつ自動的に調査および検証して、独自のセキュリティ基準が満たされていることを確認できる必要があります。 

現在、ソフトウェア サプライ チェーンに対する信頼は低く、これはすべての利害関係者にとって常に不安の種となっています。実装されているセキュリティ対策の可視性を高め、継続的コード保証の証拠を提供することは、ソフトウェア サプライ チェーンの信頼を再構築し、検証可能により安全な製品を生産するために不可欠です。