リンクされた成果物について

          linked artifacts pageは、成果物が格納されている場所に関係なく、GitHubに基づいて組織のビルドを監査し、優先順位を付けるのに役立ちます。

この記事で

          linked artifacts pageは、コンテナー イメージ、パッケージ、運用コードのビルドなど、GitHub Actionsを使用して組織が構築するソフトウェア成果物の統合ビューを提供します。

このページには、成果物の構築方法、成果物が格納または実行されている場所、成果物に関連付けられているコンプライアンスとセキュリティのメタデータが表示されます。

組織内のチームは、 linked artifacts page のデータを使用して次のことができます。

  • 検出された脆弱性が運用環境で実行されているか、インターネットに公開されているかに基づいて、 GitHub Advanced Security 機能からのアラートに優先順位を付ける
  • 成果物を迅速に関連付けて、詳細を確立し、保存場所や所有するチームを設定します。
  • 成果物の証明と整合性の監査可能な証拠をエクスポートしてコンプライアンスを満たす
  • デプロイされた成果物に関連付けられているリポジトリを検索し、ブランチ ルールセットでそれらをターゲットにする

          linked artifacts pageに表示される成果物はどれですか?

          linked artifacts pageは、各組織に固有です。 これには、組織のリポジトリ内の GitHub Actions を使用して構築された成果物のメタデータが含まれています。 他の場所から組織が消費する成果物、例えばオープンソースの依存関係などは表示されません。

成果物レコードは、パブリック API または外部レジストリとの統合を使用して、組織によってアップロードされます。 linked artifacts pageは成果物ファイル自体を格納しません。 各成果物に関連付けられているメタデータの権限のあるソースを提供するだけです。

成果物をGitHubに表示するためにlinked artifacts pageに格納する必要がないため、JFrog Artifactory や linked artifacts page など、GitHub Packagesを任意のパッケージ レジストリと共に使用できます。

どのメタデータが含まれていますか?

          linked artifacts pageは、ストレージ レコードとデプロイ レコードという 2 種類のレコードのデータを結合します。 これらのレコードは、さまざまな API エンドポイントまたは統合を使用してアップロードされます。

ストレージレコード

ストレージ レコードには、成果物のソース コードを含むリポジトリ、成果物が格納されているレジストリ、成果物の整合性と証明を証明する構成証明が含まれます。 このデータを使用して、成果物の所有チームをすばやく見つけ、詳細をビルドできます。

アーティファクト ページのスクリーンショット。 強調表示されたフィールド: ストレージ レジストリ、アーティファクト リポジトリ、ソース リポジトリ。

          _アーティファクト リポジトリ_は必須ではありません。 これは、特定の外部パッケージ レジストリ内のリポジトリの概念を指します。複数のパッケージをグループ化できる場所です。 これに対し、 _ソース リポジトリは、_ 成果物がビルドされている GitHub リポジトリを参照します。 ソース リポジトリは必須であり、成果物にビルドの証明書がある場合は自動的に検出されます。

構成証明と SLSA レベルの詳細については、 AUTOTITLE を参照してください。

展開記録

デプロイ レコードには、成果物がデプロイされている環境と、成果物に関連付けられているランタイム リスク ("機密データ" や "インターネット公開" など) が含まれます。

アーティファクト ページのスクリーンショット。 強調表示されたフィールド: "Prod"、"機密データ"、"pacific-east" のタグを含む "デプロイ" リスト。

メモ

デプロイ レコードには、別のソースからのリポジトリのデプロイ ダッシュボードからのデプロイ アクティビティは含 まれません 。 「リポジトリのデプロイメントアクティビティを表示する」を参照してください。

成果物データはどこで入手できますか?

成果物メタデータは、 linked artifacts page 自体で使用できるだけでなく、 GitHubのポリシーおよびセキュリティ サーフェイスに統合されます。 Teams はこのデータを使用して、ポリシーの決定を行ったり、セキュリティの問題に優先順位を付けたりすることができます。 たとえば、次のことができます。

  •         `deployed`フィルターまたは`deployable` フィルターを使用して、組織およびエンタープライズルールセット内のリポジトリまたはターゲット リポジトリを検索します。 「[AUTOTITLE](/search-github/searching-on-github/searching-for-repositories#search-based-on-deployment-context)」を参照してください。
  • 実行時のリスクによって、セキュリティ キャンペーン、 code scanning アラート、および Dependabot アラートをフィルター処理します。 「運用コンテキストを使用した Dependabot とコード スキャンアラートの優先順位付け」を参照してください。
  • 個々の code scanning と Dependabot アラートの属性としてランタイム リスクを表示します。

          linked artifacts pageはプロセスにどのように適合しますか?

このワークフロー例では、 linked artifacts page を他の GitHub 機能や外部システムと統合する方法を示します。

  1. 開発者は、ソフトウェア パッケージのコードが定義されている GitHub リポジトリにコードをコミットします。

  2. リポジトリ内の GitHub Actions ワークフローは自動的に次のようになります。

    1. パッケージをビルドします。
    2.     GitHub Packagesや JFrog Artifactory など、選択したレジストリにパッケージをプッシュします。
    3. パッケージのビルドに使用されるリポジトリ、コミット、およびワークフローにパッケージをリンクして、暗号署名された実績証明を作成します。
    4. ステージング環境または運用環境にパッケージをデプロイします。 Kubernetes アドミッション コントローラーを使用するなど、構成証明された成果物のみを運用環境にデプロイできるように、デプロイ システムをゲートすることができます。

  3. パッケージのメタデータ (リンクされたリポジトリ、構成証明、デプロイ履歴など) は、 linked artifacts pageにアップロードされます。

  4. セキュリティ リーダーは、 linked artifacts pageのデータを使用して、コード スキャンと Dependabot アラートをトリアージし、運用環境に影響を与えるか、特定のランタイム リスクがあるアラートに対処するキャンペーンを作成します。

  5. 監査が必要な場合、コンプライアンス チームのメンバーは、組織のすべてのリンクされた成果物の SBOM、実績の詳細、展開レコードを 1 つのソースからエクスポートします。

次のステップ

組織の linked artifacts pageにレコードを追加するには、 ストレージとデプロイのデータをアップロードしてlinked artifacts page を参照してください。

組織の linked artifacts page を表示するには、「 AUTOTITLE」を参照してください。