C6: コンポーネントを評価して更新する (Assess and Update your Components)

説明

ソフトウェア開発ではライブラリやフレームワークを活用することが一般的です。セキュリティを組み込んだ安全なライブラリやソフトウェアフレームワークは、ソフトウェア開発者がセキュリティ関連の設計や実装の欠陥を防ぐのに役立ちます。

アプリケーションを何もないところから作成する開発者には、セキュリティ機能を適切に実装したり保守するために十分な知識、時間、予算がないかもしれません。セキュリティフレームワーク (オープンソースとベンダーの両方) を活用することで、セキュリティ目標をより効率的かつ正確に達成することに役立ちます。

可能であれば、定期的なアップデートやメンテナンスが櫃となる別のサードパーティライブラリをインポートするのではなく、フレームワークの既存の安全な機能を使うことに重点を置くべきです。開発者に別のライブラリを強要するのではなく、既に使用しているものを活用してもらうほうがよいでしょう。

サードパーティのライブラリやフレームワークをソフトウェアに組み込む際には、以下の二つのベストプラクティスを考慮することが重要です。

1. 信頼できるライブラリやフレームワークを特定して、ソフトウェアに導入します。

2. パッケージを監視および更新して、サードパーティコンポーネントによってもたらされる可能性のあるセキュリティ脆弱性に対して、ソフトウェアが脆弱でないようにします。

脅威

• 攻撃者は古いサードパーティコンポーネントの既知の脆弱性を悪用して、認可されていないアクセスを得たり、悪意のあるコードを実行する可能性があります。

• 攻撃者は開発プロセスで使用されるライブラリやフレームワークを侵害してサプライチェーン攻撃を実行し、最終製品に悪意のあるコードを挿入する可能性があります。

• 攻撃者は適切に堅牢化されていないサードパーティコンポーネントの安全でない設定を悪用して、機密情報を抽出する可能性があります。

• 攻撃者は外部ライブラリの既知の脆弱性を狙ってサービス拒否攻撃を仕掛けて、サービスの可用性を妨害する可能性があります。

実装

以下ではこれらの各カテゴリについて、ソフトウェアを保護するための詳細を説明します。

信頼できるライブラリを特定するためのベストプラクティス

ソフトウェアの次のライブラリやフレームワークを選択するために使用できる基準をいくつか以下に示します。これは網羅的なリストではありませんが、出発点としてはよいでしょう。

1. ソース (Sources): 公式ソースから安全なリンクを介して推奨セキュリティライブラリをダウンロードし、署名付きパッケージを優先して、改変された悪意のあるコンポーネントが含まれる可能性を減らします (A08:2021-ソフトウェアとデータの整合性の不具合 (Software and Data Integrity Failures) を参照)。

2. 評判 (Popularity): 大規模なコミュニティを持つ多くのアプリケーションで使用されているライブラリやフレームワークを活用します。パッケージのソースコードリポジトリが獲得した GitHub スターの数や、パッケージマネージャ内からのダウンロード数などのデータポイントを考慮します。

3. アクティビティ (Activity): ライブラリやフレームワークが積極的に保守されており、問題がタイムリーに解決されていることを確認します。

4. 成熟度 (Maturity): 安定バージョンを使用します。開発の初期段階にあるプロジェクトではソフトウェアに対するリスクが高くなります。

5. 複雑度 (Complexity): 依存関係が多く、大規模で複雑なライブラリは、ソフトウェアに組み込むことがより困難になります。また、依存関係の数が多いということは、それらの依存関係すべてを最新にして安全に保つために、将来のアップグレードの回数が多くなることを示しています。

6. セキュリティ (Security): パッケージがオープンソースである場合、静的アプリケーションセキュリティテスト (SAST) や ソフトウェア構成分析 (SCA) を使用して、最初に含める前に悪意のあるコードやセキュリティ上の弱点を特定するのに役立ちます。

安全に保つためのベストプラクティス

新しいセキュリティ脆弱性は毎日開示されており、NIST National Vulnerability Database (NVD) などのパブリックデータベースで公開されています。NVD では共通脆弱性識別子 (Common Vulnerabilities and Exposures, CVE) を使用して公に知られている脆弱性を特定します。さらに、パブリックデータベースで利用可能なエクスプロイトにより、攻撃者は攻撃を自動化できます。このため、ソフトウェアに既知のセキュリティ脆弱性がないことを定期的に確認することが重要です。

1. すべてのサードパーティコンポーネントの インベントリカタログを保守します 。ビルドパイプライン内から SBOM (Software-Bill-Of-Materials) を自動的に作成することをお勧めします。SBOM には、使用されているすべてのサードパーティの依存関係とそのバージョンが含まれており、さまざまなサプライチェーン管理ツールによって自動的に監視できます。
2. 継続的なチェックを実行します。 SBOM を OWASP dependency-track などの定期的または継続的な監視ツールと併用して、一般に公開されている既知の脆弱性を自動的に検出します。

3. 早期かつ頻繁にセキュリティを検証します。 ソフトウェア開発の初期段階で SCA ツールを統合し、ソフトウェア開発ライフサイクルのあらゆる段階でソフトウェアとその依存関係のセキュリティ脆弱性の数と重大度を可視化します。

4. 積極的に ライブラリとコンポーネントを更新します。ソフトウェアの更新は、アプリケーションや製品のライフサイクル全体にわたって、構想から廃止に至るまで、繰り返し発生するタスクである必要があります。

防止される脆弱性

安全なフレームワークとライブラリはウェブアプリケーションのさまざまな脆弱性を防ぐのに役立ちます。Top 10 2021 既知の脆弱性を持つ脆弱で古くなったコンポーネント の使用で説明されているように、これらのフレームワークやライブラリを最新の状態に保つことが重要です。

参考情報

• OWASP Cheat Sheet: Third Party JavaScript Management
• OpenSSF Scorecard - Security health metrics for Open Source

ツール

• OWASP Dependency-Check ­- プロジェクトの依存関係を特定し、公開されている脆弱性をチェックします
• OWASP Dependency-Track - SBOM ファイルに新しい脆弱性がないか定期的に監視します
• Retire.JS スキャナ - JavaScript ライブラリ向け

• Renovate - 依存関係の自動更新向け
• Harbor : ポリシーとロールベースのアクセス制御でアーティファクトを保護するオープンソースレジストリ