ソフトウェアサプライチェーンのセキュリティ確保は、「ソフトウェアファクトリー」の発見とガバナンスから始まります。
今日のソフトウェア開発環境では、チームはコード リポジトリ、ビルド パイプライン、コンテナー イメージなどの分散資産を扱います。この分散モデルは柔軟性を提供し、生産を高速化しますが、特にクラウド ネイティブ アプリケーションが普及するにつれて、資産が断片化され、ガバナンスとセキュリティ監視が複雑になります。
その結果、セキュリティ問題が発生した場合や、許可されていないソフトウェア成果物が本番環境に導入された場合、セキュリティ チームは孤立した本番環境ワークロードのコード所有者を追跡するのに貴重な時間を失うことがよくあります。ソフトウェア サプライ チェーンは重要な攻撃対象領域となっており、開発段階からビルド段階までセキュリティ シグナルを早期に収集して盲点を回避し、ソフトウェア開発ライフサイクル (SDLC) 全体のすべての資産が監視されるようにすることが不可欠です。
DevSecOps チームには通常、新しいコード パスやツールが頻繁に導入されるこの変化する開発環境を継続的にマッピングするための自動化ツールがありません。情報はさまざまなプラットフォーム間でサイロ化されたままになることが多く、セキュリティ目的でアクセスすることが困難です。ソフトウェアが段階的に推進されるにつれて、開発プラットフォームとツールは開発、統合、展開ごとに異なることがよくあります。
アプリケーション セキュリティ ポスチャ管理 (ASPM) および可観測性ベンダーはセキュリティ スキャンを集約しますが、コード パスを本番環境に接続する完全なビューを提供できないことがよくあります。
古くなった資産の存在は、問題を複雑化させます。特に大規模な組織では、どのリポジトリがまだ運用中でアクティブであるかを特定することは大変な作業です。合併や買収により、多様なプラットフォームや開発標準が追加され、この問題はさらに複雑になります。
DevSecOps チームは、マニフェストの記入やコンテナのラベル付けなどの手動プロセスに頼ることがよくありますが、これは面倒でエラーが発生しやすく、より緊急の優先事項のために後回しにされることが多々あります。
常に変化する戦場を守るようなものだと考えてください。セキュリティ チームは資産を守るために正確な地図を必要とします。これらの資産は常に開発中であり、新しいターゲットを特定して保護する必要があります。これに対処するには、変化が発生したときにそれをマップする継続的な検出メカニズムが必要です。
このアプローチはベストプラクティスとフレームワークによってサポートされています。例えば、 サイバーセキュリティおよびインフラストラクチャセキュリティエージェンシー（CISA） 組織はソフトウェアコンポーネントの出所を確認し、包括的なインベントリを保守管理の一環として維持することが義務付けられています。 自己証明プロセス。 同様に、 NIST セキュア ソフトウェア開発フレームワーク (SSDF) と OWASP DevSecOps 成熟度モデル (DSOMM) 継続的な発見と可視性の重要性を強調します。
この投稿の残りの部分では、これらの課題に対処するための青写真を概説し、Scribe Security が組織がこれらの機能を効果的に実装するのにどのように役立つかについて説明します。
効果的な発見のための Scribe の青写真
Discovery はグラフでモデル化されたマップを生成し、資産、関係、工場のセキュリティ体制のビューを提供します。これにより、次のことが可能になります。
- 完全な可視性と所有権管理。
- クエリ機能が強化されました。
- KPI とセキュリティ成熟度メトリックの監視。
- リスク要因のより迅速な特定と優先順位付け。
- 初期スキャン
初期スキャンの目的は、資産の高レベル マップを作成し、さらに分析が必要な資産を特定することです。完全なディープ スキャンには時間がかかり、運用環境にリンクされていない資産や廃止された資産など、多くの資産は無関係になる可能性があります。この初期スキャンでは通常、リポジトリ名、ID、アクティビティ統計などの基本的な詳細が収集されますが、コミットや貢献者の完全なリストは含まれません。
8 つの方法は、「右から左へ」スキャンすることです。スキャナーは、本番環境にアクセスすることで (たとえば、KXNUMXs クラスター API 経由)、実行中のコンテナ イメージ (ビジネス価値を反映する重要な資産) を識別できます。そこから、スキャンはコンテナ レジストリと関連リポジトリまでさかのぼります。通常、レジストリと先行する SDLC パイプラインの間には直接的な接続がないため、スキャンはここで停止します。
補完的なスキャンは「左から右へ」実行でき、さまざまな SDLC ステージ (開発、統合、テストなど) にわたるコード リポジトリ、ビルド パイプライン、レジストリを識別します。
その結果、プラットフォーム全体にわたる優先順位付けされた資産リストが作成され、コードから本番環境までの系統をトレースし、SDLC のセキュリティ体制を評価するための詳細なスキャンの準備が整います。優先順位付けは、本番環境との関連性、アクティビティ レベル、最新性などの要素に基づいています。資産の重要性に関する組織的な知識が、このプロセスのガイドとして役立つ場合があります。
最初のスキャンは定期的にスケジュールすることも、コード プッシュなどのイベントによってトリガーすることもできます。後続のスキャンでは、新しく検出された資産を詳細にスキャンするために glob を使用するなど、自動選択基準を適用できます。
- ディープスキャン
関連するアセットが優先順位付けされると、ディープ スキャンによって、ブランチ ID、コミット ID とコミッター ID、パイプライン実行 ID など、アセット間の関係を確立する詳細な属性が収集されます。このスキャンの期間は、アセットの範囲と API レート制限によって異なります。
このステージの終わりまでに、資産関係グラフが形成され始め、コード リポジトリ (ビルド情報を含む) とランタイム環境 (レジストリ資産を含む) の周囲に接続された資産のクラスターが形成されます。ただし、レジストリには通常、ビルド成果物をプッシュしたパイプラインに関する情報は保存されないため、完全な系統はまだ不完全です。
- クラスターの接続
インベントリが確立されると、パイプラインで CLI ツールをインストルメント化してビルドの起源の詳細をキャプチャするか、CI ログを処理することで、系統を完成させることができます。インストルメンテーションは最も信頼性の高い方法で、コード リポジトリ ID、パイプライン ID と実行 ID、イメージ ID などの主要な属性を記録します。これにより、以前は分離されていたクラスターが効果的にリンクされ、コードから本番環境まで完全なエンドツーエンドの系統が作成されます。
補完的なアプローチは CI ログ処理です。これは関連する属性を取得しますが、より多くのリソースが必要で、既存のログに依存します。この方法はより迅速な実装を提供しますが、両方のアプローチを組み合わせることで最良の結果が得られます。つまり、重要なパイプラインをインストルメント化し、新しく発見されたパイプラインにログ分析を使用して、さらにインストルメント化するために評価することができます。
このクラスタリング アプローチでは、マイクロサービスなどの複数のコンポーネントで構成された Web アプリケーションなどの複雑な製品について、個別の系統を統合した構造に集約することも検討されています。
- ソフトウェア部品表（SBOM）
ここまでは、プラットフォーム間で開発資産を接続し、コードから本番環境までの関連資産の明確な系統を確立することに重点が置かれてきました。ここで、ソフトウェア成果物自体の構成に注目が移ります。このステップでは、それらの成果物と関連するコード リポジトリから SBOM が生成され、既存のインベントリに追加されます。
コード リポジトリとアーティファクト SBOM を単一の SBOM に統合し、依存関係を関連付けて無関係なもの (開発ライブラリやテスト ライブラリなど) を除外するロジックを使用することで、どちらかのソースが単独で提供できるものよりも正確で包括的な SBOM が実現します。
- セキュリティ体制とDevSecOPs KPI
資産インベントリとその関係を継続的にマッピングすることで、これらの資産のセキュリティ体制を評価する最適な機会が得られます。重要な要素には、人間と非人間の ID のアクセス許可、コード署名の検証、リスクのある依存関係や脆弱な依存関係、さまざまなプラットフォームとアカウントにわたるセキュリティ設定などがあります。
このデータはさまざまなディメンションに集約され、製品リリース、本番環境への展開時間、DevSecOps の成熟度などの KPI を測定できます。具体的には、コード署名やセキュリティ設定の遵守などのセキュリティ制御の採用をチームが評価できるため、進捗状況を追跡し、堅牢なセキュリティ プラクティスを確保するのに役立ちます。
- SDLC とソフトウェア サプライ チェーン グラフの視覚化とクエリ
検出プロセスの主な利点の 1 つは、SDLC とソフトウェア サプライ チェーンを動的なグラフまたは「バトル マップ」として視覚化できることです。この視覚化により、開発ライフサイクル全体の包括的なビューが提供され、資産とその関係の追跡が容易になります。
本当の力はグラフをクエリする機能から生まれ、チームは次のような重要な質問をすることができます。
- 「ビルドまたはデプロイメント中にセキュリティ チェックに失敗したコンポーネントはどれですか?」
- 「本番環境のどのワークロードが孤立していますか？」
- 「脆弱性をもたらす変更を実行したのは誰ですか?」
- 「パッチを適用する必要がある資産の所有者は誰ですか?」
系統をクエリすると、チームは問題の根本原因を特定するのに役立ちます。これは、手動のドキュメント化に比べて明らかに有利です。手動で管理された所有権マッピングはすぐに古くなり、DevSecOps チームが適切な関係者を非効率的に探すことにつながることがよくあります。対照的に、クエリ可能なグラフにより、所有権と説明責任が常に最新になり、コードやインフラストラクチャの責任を追跡する時間の無駄が削減されます。
- 検出ツールの展開オプション
組織には検出ツールの導入に対するさまざまなニーズがあり、さまざまなセキュリティ要件を満たすには柔軟な導入オプションを提供することが不可欠です。一部のチームは、管理とスケーリングを簡素化するために、SaaS プラットフォーム経由のリモート アクセスを好みます。一方、セキュリティ プロトコルが厳格なチームは、開発プラットフォーム API トークンなどの機密性の高い資格情報をより厳密に管理するために、ローカル スキャナーの導入を選択する場合があります。SaaS とローカル導入のどちらを選択するかは、組織のセキュリティ体制、コンプライアンスのニーズ、データの管理などの要因によって異なります。
まとめ
ソフトウェア サプライ チェーンのセキュリティ確保は継続的な戦いです。明確なマップなしにこの戦いに挑む組織は存在しません。堅牢な検出プロセスを実装することで、SDLC とサプライ チェーン全体を包括的に可視化し、開発から運用まですべての資産が確実に把握されるようにすることができます。Scribe Security のブループリントなどのツールを使用すると、接続された系統を構築し、正確な SBOM を生成し、セキュリティ体制を評価し、開発エコシステム内の重要な関係を視覚化できます。このレベルの洞察により、DevSecOps チームは脆弱性を迅速に特定し、その起源を追跡し、ソフトウェア ランドスケープの最新の理解を維持できます。これは、今日のペースが速く複雑な開発環境で優位に立つために不可欠です。
筆記 ソフトウェア サプライ チェーンのセキュリティを確保するための重要な手段として、検出とガバナンスのための包括的なソリューションを提供します。
- 初期スキャンとディープスキャン – 環境全体のコード リポジトリ、パイプライン、コンテナー イメージなどの資産を識別して優先順位を付け、関連するコンポーネントのインベントリを構築します。
- エンドツーエンドの系統 – CLI ツールと CI ログを使用して分離されたアセット クラスターを接続し、コードから本番環境までの完全な系統を形成します。
- ソフトウェア部品表（SBOM） – 無関係な依存関係を除外して、成果物とリポジトリ データを合成し、正確な SBOM を生成します。
- セキュリティ態勢の評価 – アクセス制御、コード署名、脆弱な依存関係を継続的に評価して、セキュリティ KPI を測定します。
- 視覚化とクエリ – SDLC 全体を視覚化し、脆弱性、孤立したワークロード、資産の所有権を追跡するためのクエリを可能にします。
- 柔軟な展開 – さまざまなセキュリティ ニーズに対応し、機密データを制御するために、SaaS とローカルの両方の展開をサポートします。
このコンテンツは、エンドツーエンドのソフトウェア サプライ チェーン セキュリティ ソリューションの大手プロバイダーである Scribe Security によって提供されており、ソフトウェア サプライ チェーン全体のコード成果物とコード開発および配信プロセスに最先端のセキュリティを提供しています。 詳しくはこちら。
関連記事
