ストレージとデプロイのデータをアップロードしてlinked artifacts page

組織内のパッケージとビルドをストレージと展開データに関連付けます。

この機能を使用できるユーザーについて

Anyone with write access to an organization-owned repository

Organization accounts on any plan

この記事で

          linked artifacts pageには、組織で構築した成果物のストレージ レコードとデプロイ レコードが含まれます。 各成果物のメタデータは、次のいずれかの方法を使用して組織によって提供されます。

* GitHubに対する**** のアクションのいずれかを含むワークフロー * Dynatrace、JFrog Artifactory、またはMicrosoft Defender for Cloud * アーティファクト メタデータ REST API を使用したカスタム スクリプト

使用できる方法は、ストレージ レコードとデプロイ レコードのどちらをアップロードするかによって異なります。 レコード・タイプの詳細については、 AUTOTITLE を参照してください。

ストレージ レコードのアップロード

ストレージ レコードをアップロードするには、 成果物の構成証明 を作成するか、 JFrog Artifactory との統合を有効にします。 これらのオプションを使用しない場合は、 REST API とのカスタム統合を設定する必要があります。

          GitHub Actionsを用いて証明する

成果物構成証明のために GitHub のファーストパーティアクションを使用して、成果物のストレージレコードをアップロードできます。 これは、成果物のビルドに使用するのと同じワークフローで行うことができます。 これらのアクションにより、ビルドするソフトウェアの署名付き実証と整合性の保証が作成され、ストレージ レコードが linked artifacts pageに自動的にアップロードされます。

attest アクションは、次の両方の場合、linked artifacts page にストレージ レコードを自動的に作成します。

  •         `push-to-registry` オプションは次の値に設定されます。`true`
  • アクションを含むワークフローには、 artifact-metadata: write アクセス許可があります

これらのアクションの使用方法の詳細については、 AUTOTITLE を参照してください。

成果物に構成証明が必要ない場合、またはデプロイ レコードまたは追加のストレージ メタデータをアップロードする場合は、次のセクションを参照してください。

JFrog 統合の利用

この双方向統合により、GitHub のストレージ レコードが JFrog 上の成果物と自動的に同期され、常に最新の状態に保たれます。 たとえば、 GitHub に作成した構成証明は自動的に JFrog にアップロードされ、成果物を JFrog で運用に昇格すると、 GitHubのレコードに実稼働コンテキストが自動的に追加されます。

セットアップ手順については、JFrog ドキュメントの「Get Started with JFrog Artifactory and GitHub Integration」を参照してください。

REST API の使用

証明する必要がない成果物と JFrog に格納されていない成果物の場合は、 成果物メタデータ ストレージ レコードの作成 API エンドポイントを使用してカスタム統合を作成できます。 選択したパッケージ リポジトリに成果物が発行されるたびにエンドポイントを呼び出すシステムを構成する必要があります。

メモ

成果物が GitHubの起源証明に関連付けられていない場合は、github_repository パラメーターが必須です。

デプロイ レコードのアップロード

Dynatrace または Microsoft Defender for Cloud (MDC) を使用してデプロイされたワークロードを監視する場合は、統合を使用してデプロイ データを linked artifacts pageに自動的に同期できます。 それ以外の場合は、REST API とのカスタム統合を設定する必要があります。

Dynatrace 統合の使用

Dynatrace で監視されている Kubernetes 環境で実行されているコンテナー イメージの GitHub にデプロイ レコードを送信するように Dynatrace を構成できます。 Dynatrace は、デプロイされたイメージをリポジトリにマップし、ランタイム コンテキストを報告します。

さらに、Dynatrace からのデプロイ レコードには、次のようなランタイム リスク コンテキストが含まれる場合があります。

  • インターネット公開
  • 機密データ アクセス

このコンテキストは、組織レベルのアラート フィルター処理やセキュリティ キャンペーンで使用して、インターネットに公開されたワークロードまたは機密データワークロードに影響するアラートの修復に優先順位を付けることができます。

セットアップ手順については、Dynatrace ドキュメントの「GitHub Advanced Securityセキュリティ統合 - 概要」を参照してください。

Microsoft Defender for Cloud 統合の使用

          MDC インスタンスをGitHub組織に接続できます。 
          MDC は、デプロイデータとランタイムデータを GitHubに自動的に送信します。

セットアップ手順については、GitHubのドキュメントの「MDCする」を参照してください。

メモ

          Microsoft Defender for Cloudとの統合はパブリック プレビューであり、変更される可能性があります。

REST API の使用

          [成果物デプロイ レコードの作成](/rest/orgs/artifact-metadata#create-an-artifact-deployment-record) API エンドポイントを使用すると、システムは特定の成果物のデプロイ データを、名前、ダイジェスト、環境、クラスター、デプロイなど、GitHubに送信できます。 成果物が新しいステージング環境または運用環境にデプロイされるたびに、このエンドポイントを呼び出す必要があります。

メモ

成果物が GitHubで真正性証明と関連付けられていない場合は、github_repositoryパラメーターが必須です。

アップロードの確認

レコードが正常にアップロードされたことを確認するには、組織の設定で更新された成果物を表示できます。 「linked artifacts page で organization のビルドをチェックする」を参照してください。

不要なレコードの削除

          linked artifacts pageから成果物を削除することはできません。 ただし、成果物の状態を反映するようにストレージ レコードまたはデプロイ レコードを更新できます。 「[AUTOTITLE](/code-security/how-tos/secure-your-supply-chain/establish-provenance-and-integrity/remove-linked-artifacts)」を参照してください。


          GitHub Actions の例

成果物のビルドと発行に使用するのと同じワークフロー内の linked artifacts page にデータをアップロードできます。

証明書の生成

次の例では、Docker イメージをビルドして発行し、次の手順で ${{ steps.push.outputs.digest }} 出力を使用して、実証構成証明を生成します。

          `attest` アクションは、linked artifacts pageが設定され、ワークフローに`push-to-registry: true`アクセス許可が含まれている場合に、ストレージ レコードを`artifact-metadata: write`に自動的にアップロードします。


env:
  IMAGE_NAME: my-container-image
  ACR_ENDPOINT: my-registry.azurecr.io

jobs:
  generate-build:
    name: Build and publish Docker image
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
      attestations: write
      packages: write
      artifact-metadata: write

    steps:
      - name: Build and push Docker image
        id: push
        uses: docker/build-push-action@263435318d21b8e681c14492fe198d362a7d2c83
        with:
          context: .
          push: true
          tags: |
            ${{ env.ACR_ENDPOINT }}/${{ env.IMAGE_NAME }}:latest
            ${{ env.ACR_ENDPOINT }}/${{ env.IMAGE_NAME }}:${{ github.sha }}

      - name: Generate artifact attestation
        uses: actions/attest@v4
        with:
          subject-name: ${{ env.ACR_ENDPOINT }}/${{ env.IMAGE_NAME }}
          subject-digest: ${{ steps.push.outputs.digest }}
          push-to-registry: true

REST API の使用

または、構成証明を生成していない場合は、アーティファクト メタデータ API を直接呼び出すことができます。


env:
  IMAGE_NAME: my-container-image
  IMAGE_VERSION: 1.1.2
  ACR_ENDPOINT: my-registry.azurecr.io

jobs:
  generate-build:
    name: Build and publish Docker image
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
      packages: write
      artifact-metadata: write

    steps:
      - name: Build and push Docker image
        id: push
        uses: docker/build-push-action@263435318d21b8e681c14492fe198d362a7d2c83
        with:
          context: .
          push: true
          tags: |
              ${{ env.ACR_ENDPOINT }}/${{ env.IMAGE_NAME }}:latest
              ${{ env.ACR_ENDPOINT }}/${{ env.IMAGE_NAME }}:${{ github.sha }}

      - name: Create artifact metadata storage record
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          jq -n --arg artifactName "${{ env.IMAGE_NAME }}" --arg artifactVersion "${{ env.IMAGE_VERSION }}" --arg artifactDigest "${{ steps.push.outputs.digest }}" '{"name": $artifactName, "digest": $artifactDigest, "version": $artifactVersion, "registry_url": "https://azurecr.io/", "repository": "my-repository"}' > create-record.json

          gh api -X POST orgs/${{ github.repository_owner }}/artifacts/metadata/storage-record --input create-record.json
        shell: bash

次のステップ

データをアップロードすると、組織内のチームは、ストレージデータと展開データのコンテキストを使用してセキュリティ アラートの優先順位を付けることができます。 「運用コンテキストを使用した Dependabot とコード スキャンアラートの優先順位付け」を参照してください。