ソフトウェア・コンポジション解析 (SCA) ツール ソフトウェアの依存関係にインデックスを付けて、パッケージを可視化します'再使用およびそれらに含まれる脆弱性。 SCAは、'依存関係のソースをパッケージマネージャーやベンダーなどから再調達する'の Web サイト、およびそれぞれに関連付けられたオープンソース ライセンス。
SCAは、複雑なソフトウェア依存チェーンの課題を解決するのに役立ちます。 事実上、最新のソフトウェアはすべてサードパーティのパッケージ、オープンソースのライブラリ、およびコンポーネントに依存しており、それぞれが古くなっているか、独自のアプリに影響を与えるリスクが含まれている可能性があります。 SCAがなければ、'あなたが何かを知るのは難しいです'再使用と、それが脅威をもたらすかどうか。
2023 Cloud Vulnerability Report
The Wiz Research team explores insights on vulnerability management in cloud environments — using recently identified vulnerabilities as examples — and share some insights into their methodology for vulnerability intelligence.
Download now
ソフトウェア・コンポジション解析の利点
SCAの'主な利点は、オープンソースの依存関係の可視性が高まることです。 コードベースをカタログ化します'の全体 ソフトウェアサプライチェーンをクリックすると、その中の作成者、ライセンス、および脆弱性を検査できます。 つまり、ソフトウェアのリスクを軽減し、品質を向上させ、製品に適用される法的または規制的基準への準拠を維持できます。
SCA ソリューションは通常、 SBOM(ソフトウェア部品表). これは、プロジェクトで検出されたすべてのソフトウェアコンポーネントのインベントリです。 SBOM は、アプリに関する正確な結論を裏付けるために必要な情報を提供します'特定のパッケージがそうであるかそうでないかを証明する能力を含む、't が使用されました。 新しい ゼロデイ脆弱性が報告されています オープンソースコンポーネントでは、SBOMを参照して、'影響を受けるかどうか。
さらに、SBOMを使用すると、顧客にある程度の透明性を提供することもできます。 食品パッケージに貼られている成分表示と同様の役割を担っており、製品に含まれるすべてのものをリストアップすることで、顧客は十分な情報を得た上で選択することができます。'安全に消費できます。
SCAは今やソフトウェア開発に不可欠な要素と見なされています特に規制の厳しい業界で活動している組織向けです。 ホワイトハウス'2021年 サイバーセキュリティ大統領令 具体的には、セキュリティを向上させる方法として、ソフトウェア構成ツールとSBOMの使用を指します。
最終的に、SCAはソフトウェアサプライチェーンのコントロールを回復します。 サードパーティのパッケージはソフトウェア開発を加速しますが、深くネストされた依存関係ツリーを開発者が手作業で検査することは不可能です。 SCA手法を実践することで、サプライチェーンを継続的に監視し、リスクが発生したときに対処できる効率的なソリューションが提供されます。
ソフトウェア・コンポジション解析ツールに求めるもの
SCAは、ソフトウェア開発ライフサイクル(SDLC)の新たな部分です。 SCA の実行に役立つツールは複数ありますが、提供される機能は異なる場合があります。 ここは'は、SCAソリューションに求められるものです。
1. SBOMを生成する機能
SBOM は SCA にとって重要なので、ソリューションが SBOM をサポートしていることを確認する必要があります。 脆弱性スキャナーなどのスタンドアロンツールは便利ですが、'を使用すると、パッケージ在庫の傾向を経時的に追跡できます。
SBOMを有用にするには、標準形式で生成する必要があります。 サイクロンDX そして SPDXの. これらの基準に従うことで、SBOMを他のエコシステムツールと簡単に併用することができます。 また、クライアントやコンプライアンスチームがSBOMとそれに含まれるすべての情報を簡単に利用できるようにするのにも役立ちます。
2. 脆弱性スキャンの自動化
SCAソリューションは、パッケージインベントリで見つかった既知の脆弱性を自動的に表面化させる必要があります。 CVEのリストをそれぞれの重大度とともに表示できるため、直面している脅威の大きさをすぐに理解できます。 逆に、この情報を取得するために別のツールに切り替える必要があると、プロセスに摩擦が加わり、効率的な対応を調整することが難しくなります。
3. 実行可能な解決策
脆弱性や古いパッケージの報告は、有用であるためには実用的でなければなりません。 問題の優先順位付けと修正の取り組みをサポートできる SCA ソリューションを探す必要があります (たとえば、開発者ツールやコラボレーション プラットフォーム内で即時アラートを提供するなど)。
ボタンをクリックするだけでパッチが適用されたバージョンのパッケージに更新できるため、修復作業がより迅速になり、一貫性が高まります。 解決オプションを手動で検索する必要がないため、より多くのレポートを短時間で処理できるだけでなく、特定の種類の問題にあまり慣れていないチーム メンバーでも、必要に応じて信頼できる修正を適用できます。
4. CI/CDパイプライン内で自動化する機能
SCAは、ソフトウェアインベントリを完全にカバーするために、自動化と継続の両方を行う必要があります。 開発者のワークステーションでのみ機能するツール、または出力を手動で確認する必要があるツールが獲得されました'情報に基づいた意思決定を行い、時間の経過に伴う傾向を追跡するために必要な全体像を提供します。
代わりに、CI/CDパイプラインベースのスキャンを容易にサポートするなど、SDLCと完全に統合できるソリューションを選択する必要があります。 これにより、新しいサプライチェーンの問題がプロジェクトに入るときにコードをスキャンして検出できるため、脅威が確立される前に緩和策を簡単に適用できます。
5. ライセンスコンプライアンスサポート
オープンソースソフトウェアは、それなりに当たり前のように'開発者が新しいパッケージをインストールするのはとても簡単です。 しかし、そうすることで、パッケージが's ライセンスは'製品との互換性's.
SCAツールには、ライセンスの問題を検出して解決できる堅牢なライセンスコンプライアンス機能が含まれている必要があります。 その後、すべてのコンポーネントが適切にライセンスされていることを顧客に証明し、ソフトウェアの使用がリスクにさらされるかどうかについて顧客が抱く疑問を取り除くことができます。
また、ライセンスの軽減策を自動化する可能性も、SCAソリューションを評価する際に考慮すべき重要なポイントです。 影響を受けるパッケージを削除したり、代替パッケージを提案したりできるオプションを使用すると、問題をより効率的に処理でき、開発者の時間をより生産的なタスクに費やすことができます。
6. コードスキャンとバイナリスキャンの両方をサポート
SCA ソリューションは、複数のタイプのソフトウェアをターゲットにすることができます。 コード指向のツールは、ソースコードと、ソースリポジトリ内のパッケージマネージャーからインストールされた依存関係を検査します。 これらは、問題のあるパッケージがソフトウェアに含まれる前に、問題を早期に検出するための良い方法です。'sが顧客に出荷されます。
しかし、それは'最終出力をスキャンすることも重要です。 たとえば、バイナリを分析すると、どのパッケージが実際に使用されているかを検出できます (依存関係が使用されている可能性があります)'最終ビルドに含まれるか、'tは、その方法のために脅威をもたらします'再使用されます。 同様に、コンテナー・イメージをスキャンすると、コンテナー・ベース・イメージから継承されたパッケージを含め、ランタイム環境に存在するすべてのパッケージを識別できます。
すべてのアーティファクトをスキャンできるツールを選択することで、あらゆる脅威タイプを最も包括的に可視化できます。
Agentless scanning solutions typically have quicker setup and deployment and require less maintenance. They can scan all workloads using cloud native APIs and connects to customer environments with a single org-level connector. If the approach is agent-based, this type of deployment will require ongoing agent installation, update, and maintenance effort.
ソフトウェア・コンポジション解析の実装
SCAは、開発プロセス全体と深く統合する必要があります。 つまり、ソフトウェアライフサイクルの初期段階から、コードがリポジトリに入り始めるとすぐにSCAを使用するということです。 そうしないと、デリバリースプリントの後半でSCAが取り組まれたときに、チームは解決できない問題のバックログに対処することになります。
ビルドとテストのパイプラインに SCA を埋め込むことは、パッケージの問題や脆弱性を検出する最も効果的な方法です。 開発者は、プラットフォーム内で新しい問題をリアルタイムで警告する必要があります。'すでに動作しています。 フィードバックループを緊密にすることで、開発者がリポジトリに入るとすぐに問題が通知されます。'通常、最も簡単に対処できます。
SCA ポリシー (ライセンスのコンプライアンスやパッケージの最小安定性ルールなど) は、すべてのプル要求に適用する必要があります 潜在的に問題のある変更がメインブランチにマージされて顧客に配信されるのを防ぎます。 すべてのパッケージが要件を満たすまでマージをブロックすることで、製品の継続的なコンプライアンスを維持できます。
最後に、そのコンプライアンスを証明するために、 SBOM は、デプロイするビルドごとに生成する必要があります. SBOM をリリースと共に成果物として保存すると、販売調達の議論中に顧客に提示したり、潜在的な調査で規制当局に提示したりできる監査可能な情報が提供されます。
要約すると、SCAは即時、継続的、かつ自動化されるべきです。 SCAは、ソフトウェアプロジェクトの依存関係主導のリスク評価を通知し、開発者やセキュリティチームに実用的なフィードバックを提供します。 そのためには、SCAを初日から採用し、プロジェクト全体に普遍的に適用し、問題のあるサプライチェーンの変更を実施できるようにする必要があります。'解決されるまでデプロイされません。
SCA のベスト・プラクティス
ソフトウェアデリバリプロセスにSCAを実装する際のガイドとして、以下のベストプラクティスに従うことができます。
SCAフィードバックループを強化します。 SCAは迅速に実行し、開発者に即座にフィードバックを提供する必要があります。 これにより、効率が向上し、開発者の満足度が向上します。
開発者の要件を考慮してください。 開発者が SCA ソリューションとそれが提供する詳細レベルに満足していることを確認します。 たとえば、パッケージがどのように使用されるかを取り巻くコンテキストを説明できるツールは、開発者により価値のある洞察を提供できます。
レポートが実用的であることを確認する: SCA はインベントリーのカタログを提供しますが、そのカタログは、何千ものパッケージが関係している場合、処理が困難になることがあります。 したがって、SCAレポートは、実際にアクションを実行できる意味のあるデータに絞り込む必要があります。 これにより、チームがノイズに圧倒されるのを防ぐことができます。
SCA ポリシーを定期的に見直す: SCAポリシーを定期的に見直して、改善の機会を特定し、プロセスの変更に対応します。 例えば、新しい言語、ツール、およびデプロイメント・システムを使用する場合、異なる SCA アプローチが必要になることがあります。
完全な SCA カバレッジを維持: SCAから最大限の保護を得るには、完全で継続的なカバレッジが必要です。 これは、開発者がSCAツールを設定せずに新しいプロジェクトを作成したり、そうでないプログラミング言語を使い始めたりすると、危険にさらされる可能性があります'現在のソリューションでサポートされています。 プロジェクトのインベントリを自動的に検出してスキャンできるプラットフォームは、このリスクを軽減する方法の1つです。
これらの点を念頭に置いておくことで、SCA をうまく使用して、遭遇するサード・パーティー・パッケージの問題の数を最小限に抑えることができます。
概要
この記事では、'ソフトウェア・コンポジション解析(SCA)と、それがソフトウェア・サプライチェーンの保護にどのように役立つかについて検討しました。 SCAは、バージョンの問題、脆弱性、ライセンスコンプライアンスの問題など、アプリが依存する依存関係を可視化します。
しかし、多種多様なSCAツールと手法が利用できるため、 それ'包括的なカバレッジを提供するソリューションを選択することが重要です 生成するすべてのソフトウェア成果物の。 また、最適なソリューションは、自動化された軽減オプションを提供することで問題の解決をサポートし、開発者が有意義な作業により多くの時間を費やせるようにします。
Learn why CISOs at the fastest growing companies choose Wiz to identify and remediate vulnerabilities in their cloud environments.
