SEC11-BP05 パッケージと依存関係のサービスを一元化する
ビルダーチームに対して、ソフトウェアパッケージとその他の依存関係を取得するための一元化されたサービスを提供します。これにより、記述するソフトウェアに含まれる前にパッケージの検証が可能になります。また、これは組織で使用中のソフトウェアを分析するためのデータソースとなります。
期待される成果: ソフトウェアは、記述されたコードに加えて、他のソフトウェアパッケージのセットで構成されます。これにより、JSON パーサーや暗号化ライブラリなどの、繰り返し使用される機能を容易に実装することができます。これらのパッケージのソースと依存関係を論理的に一元化することで、パッケージが使用される前に、そのパッケージの特性を検証するためのメカニズムをセキュリティチームに提供できます。またこのアプローチによって、既存のパッケージの変更による予期しない問題のリスクや、インターネット上の任意のパッケージをビルダーチームが使用することによるリスクを低減できます。このアプローチを手動および自動化されたテストフローと組み合わせて使用することで、開発中のソフトウェアの品質についての信頼性を高めることができます。
一般的なアンチパターン:
-
インターネット上の任意のリポジトリからパッケージを取得する。
-
ビルダーに提供する前に、新しいパッケージをテストしていない。
このベストプラクティスを活用するメリット:
-
構築中のソフトウェアで使用されるパッケージをより良く理解できる。
-
誰が、どのようなパッケージを使用しているかを把握することで、パッケージの更新が必要な場合に、ワークロードチームに通知することができる。
-
問題のあるパッケージがソフトウェアで使用されるリスクを低減する。
このベストプラクティスを活用しない場合のリスクレベル: 中
実装のガイダンス
ビルダーが簡単に使用できるように、パッケージと依存関係の一元化されたサービスを提供します。一元化されたサービスは、実装されるモノリシックシステムとしてではなく、論理的に一元化します。このアプローチを使用することで、ビルダーのニーズに合ったサービスを提供できます。更新が発生したときや新しい要件が発生したときに、リポジトリにパッケージを追加する効率的な方法を実装する必要があります。AWS CodeArtifact
実装手順:
ソフトウェアを開発しているすべての環境で利用可能な、論理的に一元化されたリポジトリサービスを実装します。
AWS アカウントのベンディングプロセスの一部として、リポジトリへのアクセスを含めます。
パッケージをリポジトリに公開する前に、パッケージの自動化テストを構築します。
最も頻繁に使用されるパッケージ、言語、および変更量が最も多いチームのメトリクスを維持します。
-
新しいパッケージのリクエストとフィードバックの提供を行うための、自動化されたメカニズムをビルダーチームに提供します。
-
リポジトリ内のパッケージを定期的にスキャンして、新しく発見された問題の潜在的な影響を特定します。
リソース
関連するベストプラクティス:
関連ドキュメント:
関連動画:
関連する例:
