オープンソース依存関係およびライブラリのサプライチェーンセキュリティ

概要

GitLab 製品を含む現代のアプリケーションがサードパーティのオープンソース依存関係やライブラリに大きく依存するようになるにつれ、ソフトウェアサプライチェーンのセキュリティはますます重要になっています。 たった 1 つの侵害された依存関係が、深刻な実世界での結果をもたらす可能性があります。 このガイドは、開発者およびセキュリティチームメンバーに対して、プロジェクトでオープンソース依存関係を評価し安全に使用するためのベストプラクティスと考慮事項を提供します。

このガイドラインを使用するタイミング

以下の場合にこのガイドラインを適用してください。

• 新しい依存関係を追加するマージリクエスト（MR）のレビュー
• 既存の依存関係への更新の評価
• セキュリティのために現在の依存関係を監査する場合

これには以下への変更が含まれます。

• ライブラリマニフェスト（例: Gemfile、package.json、go.mod）
• ロックファイル（例: Gemfile.lock、yarn.lock、go.sum）
• ベンダードされた依存関係

依存関係の評価プロセス

依存関係の必要性を評価する

新しい依存関係を追加する前に、まずそれが本当に必要かどうかを評価してください。

• 依存関係の機能のうち、実際にどれくらいを使用しますか？
• 必要な機能を、適度な量のコードで直接実装できますか？
• このコードを自分で維持する方が、新しい依存関係を管理するよりも単純ですか？
• 依存関係は、社内で実装すべきでない複雑な問題（暗号など）を解決していますか？
• 依存関係には、追加する必要がある他の依存関係がありますか？

初期リスク評価

詳細な評価に入る前に、以下を考慮してください。

• 依存関係が必要とするアクセスと権限のスコープ
• この依存関係を使用するコンポーネントまたは機能の重要度

プロジェクトの健全性と安全な開発プラクティスを評価する

注: これらの基準は依存関係を使用するための要件ではありませんが、プロジェクトの健全性とセキュリティの良い指標となります。

• プロジェクトは積極的に開発・維持され、成熟していますか？
  • コードが最後に更新されたのはいつですか？
  • 最後のリリースはいつ出荷されましたか？
  • リリースは何回ありますか？
  • 新しいリリースはどのくらいの頻度で出荷されますか？
  • 評価しているソフトウェア依存関係のバージョンは、安定した「リリース」バージョンですか？（例: alpha、beta、v0.x ではない）
  • プロジェクトは 90 日以上前のものですか？
• プロジェクトはソフトウェア業界やオープンソースコミュニティで広く知られている、または広く採用されていますか？
  • 広範な採用は、安定性、信頼性、コミュニティの信頼を示す可能性があります
  • あまり知られていない、新しい、専門的、またはニッチな依存関係でも、以下の場合には適切である可能性があります:
    • 私たちのセキュリティ要件を満たしている
    • 代替案よりも特定のニーズをよりよく解決している
  • 注: 採用率の低さだけでは、他のセキュリティとメンテナンスの基準を満たしていれば、不適格な要因にはなりません
• プロジェクトの複雑さを考えると、十分な数のメンテナーとコントリビューターがいますか？
• プロジェクトは依存関係を更新していますか？
• プロジェクトは十分なテストカバレッジがありますか？
  • プロジェクトのパイプラインまたはテストにはセキュリティチェックまたはテストが含まれていますか？
• プロジェクトはよく文書化されており、ドキュメントにはソフトウェアコンポーネントを安全に使用または実装する方法に関するガイダンスが含まれていますか？
• プロジェクトには、脆弱性を報告するための確立された文書化されたプロセスがあり、これらの脆弱性は適時に対処されていますか？
• 評価している依存関係のバージョンは、既知の脆弱性または CVE の影響を受けていますか？影響を受けている場合、修正は利用可能ですか？
• このプロジェクトへのコミットは暗号的に署名されていますか？
• プロジェクトには、コードがメインブランチにマージされる前の変更に対するコードレビュープロセスがありますか？
  • プロジェクトはマージ/プルリクエストの承認を必要としますか？
• リリースは署名されているか、暗号的に検証可能ですか？
• プロジェクトメンテナーは、個人のカスタムメールドメインに登録されたアカウントを使用していますか？
• プロジェクトには、メンテナーアカウントのセキュリティ要件がありますか？（利用可能な場合は、プロジェクトのセキュリティまたは貢献要件を確認してください）

コード検査

• ライブラリコードに悪意のあるまたは問題のあるコンテンツがないかレビューする
• ソースコードを検査する
• 依存関係のバージョン間のコード変更のレビューに役立つように、Gem には diffend.io や Node.js モジュールには app.renovatebot.com などのサービスを使用する
• ベンダードされたライブラリには、標準的なコードレビューツールを使用する
• 依存関係のアップグレードの差分をレビューし、アップグレードが安全で新しい脆弱性を導入しないことを確認する

サプライチェーンセキュリティのベストプラクティス

• セキュリティスキャンの実装: GitLab CI/CD パイプラインで自動脆弱性スキャンを実装します。
• パッケージソースの検証: 信頼できるソースから常にパッケージをダウンロードします。公式パッケージリポジトリまたは評判の良いよく知られたソースに固執してください。
• パッケージ名の二重チェック: パッケージ名のスペルとフォーマットに注意を払ってください。
• パッケージの整合性の検証: 多くのパッケージマネージャーは、チェックサムまたはデジタル署名を使用してパッケージの整合性を検証するメカニズムを提供します。
• 依存関係のピン留め: ロックファイルまたは類似のメカニズムを使用して、プロジェクトで使用される依存関係の正確なバージョンを指定します。これは「dependency confusion」攻撃を防ぐのに役立ちます。
• セキュリティ侵害の計画: 侵害された依存関係を迅速に削除または置き換えるための計画の策定を検討してください。

AppSec エンジニア向けの依存関係レビューガイドライン

Ruby Gems

Gemfile に新しい gem が追加された場合、または Gemfile.lock でバージョンが変更された場合、開発者には AppSec チームに連絡 してレビューをリクエストするよう求めています。レビューを行う AppSec エンジニアとして、上記のガイドラインを参照し、以下の手順に従ってこのようなレビューを実施してください。

• まず、gem がよく維持されているかどうかを確認します。
  • gem のコードをより詳しく見て、異常がないか確認します。このステップは時間がかかる可能性があるため、gem のコードをレビューするのにかかる時間と、GitLab 開発者がピングしてきた MR/Issue の緊急性のバランスを取るようにしてください。
  • gitlab-com/gl-security/product-security/appsec/tooling/appsec-command-line-utils の diffgem ヘルパー関数は、Ruby ファイルのみの diff を表示することで gem バージョン変更のレビューを支援するために作成されました。（spec、json、yaml、その他のノイズへの変更は除外）
  • プロジェクト CI/CD で有効化されている場合、Depscore は新しい依存関係に対して チェック を実行し、Gem レビューを支援するために結果を MR にコメントします。
• コードで gem の最新バージョンを使用しているかを確認します。
• gem のドキュメントを読んで、避けるべき構成や使用法がないかを確認します。
• セキュリティアドバイザリと修正をチェックして、セキュリティ修正の品質を評価します。

上記を行った後、開発者がピングしてきた MR/Issue にコメントを追加し、以下を述べてください。

• 該当する gem を確認しました。gem の GitLab/GitHub ページへのハイパーリンクを追加してください。
• gem がよく維持されているかどうかを述べてください。維持されていない場合は、開発者に代替の gem を使用するよう依頼してください。
• コードで gem の最新バージョンを使用しているかどうかを述べてください。そうでない場合は、開発者に最新バージョンに移行するよう依頼してください。
• 開発者が gem を安全でない方法で使用していることに気付いた場合は、gem のドキュメントを開発者に示すことで、gem の安全な使用法を推奨するか、gem の安全でない構成を無効化してください。

NPM パッケージ

Gems の依存関係レビューガイドラインは npm パッケージのレビューにも適用できますが、それに加えて以下も行ってください。

• npm aliases が見つかった場合、エイリアス名で参照されているパッケージが悪意のあるものではないことを確認します。

ページのソースコードを見る - ページの編集 - please contribute.