Hochladen von Speicher- und Bereitstellungsdaten in die linked artifacts page

Verknüpfen Sie Pakete und Builds in Ihrer Organisation mit Storage- und Bereitstellungsdaten.

Wer kann dieses Feature verwenden?

Anyone with write access to an organization-owned repository

Organization accounts on any plan

In diesem Artikel

Dazu linked artifacts page gehören Speichereinträge und Bereitstellungseinträge für Artefakte, die Sie in Ihrer Organisation erstellen. Metadaten für jedes Artefakt werden von Ihrer Organisation mithilfe einer der folgenden Methoden bereitgestellt:

  • Ein Workflow, in dem eine der GitHub Aktionen für Artefaktbescheinigungen eingeschlossen ist.
  • Eine Integration mit Dynatrace, JFrog Artifactory oder Microsoft Defender for Cloud
  • Ein benutzerdefiniertes Skript mit der REST-API für Artefaktemetadaten

Die verfügbaren Methoden hängen davon ab, ob Sie einen Speicherdatensatz oder einen Bereitstellungsdatensatz hochladen. Weitere Informationen zu Datensatztypen finden Sie unter Informationen zu verknüpften Artefakten.

Hochladen eines Speicherdatensatzes

Sie können einen Speicherdatensatz hochladen, indem Sie einen Artefaktnachweis erstellen oder eine Integration mit JFrog Artifactory aktivieren. Wenn Sie diese Optionen nicht verwenden möchten, müssen Sie eine benutzerdefinierte Integration mit der REST-API einrichten.

Nachweis mit GitHub Actions

Sie können einen Speicherdatensatz für ein Artefakt mithilfe GitHubder First-Party-Aktionen für Artefaktnachweise hochladen. Sie können dies im gleichen Workflow tun, den Sie zum Erstellen des Artefakts verwenden. Diese Aktionen erstellen signierte Provenienz- und Integritätsgarantien für die von Ihnen erstellte Software und laden automatisch einen Speicherdatensatz in den linked artifacts page hoch.

Die Nachweis erstellt automatisch Speicherdatensätze in der linked artifacts page, wenn beides zutrifft:

  • Die push-to-registry Einstellung ist auf true
  • Der Workflow, der die Aktion enthält, verfügt über die artifact-metadata: write Berechtigung

Weitere Informationen zur Verwendung dieser Aktionen finden Sie unter Verwenden von Artefaktnachweisen zur Ermittlung der Herkunft von Builds.

Wenn das Artefakt keinen Nachweis erfordert oder Wenn Sie Bereitstellungseinträge oder zusätzliche Speichermetadaten hochladen möchten, lesen Sie die folgenden Abschnitte.

Verwenden der JFrog-Integration

Diese bidirektionale Integration hält Ihre Speicherdatensätze GitHub automatisch auf dem neuesten Stand mit dem Artefakt auf JFrog. Beispielsweise werden die von Ihnen erstellten GitHub Bestätigungen automatisch in JFrog hochgeladen, und die Beförderung eines Artefakts in die Produktion auf JFrog fügt automatisch den Produktionskontext zum Datensatz GitHub hinzu.

Anweisungen zum Einrichten finden Sie unter Get Started with JFrog Artifactory and GitHub Integration in der JFrog-Dokumentation.

Verwenden der REST-API

Bei Artefakten, die nicht attestiert werden müssen und nicht auf JFrog gespeichert werden, können Sie eine benutzerdefinierte Integration mithilfe des Endpunkts "Create artifact metadata storage record API" erstellen. Sie sollten ihr System so konfigurieren, dass er den Endpunkt aufruft, wenn ein Artefakt in Ihrem ausgewählten Paket-Repository veröffentlicht wird.

Hinweis

Wenn das Artefakt keinem Provenienznachweis GitHubzugeordnet ist, ist der github_repository Parameter obligatorisch.

Hochladen eines Bereitstellungsdatensatzes

Wenn Sie bereitgestellte Workloads mit Dynatrace oder Microsoft Defender for Cloud (MDC) überwachen, können Sie eine Integration verwenden, um Bereitstellungsdaten automatisch mit dem linked artifacts page zu synchronisieren. Andernfalls müssen Sie eine benutzerdefinierte Integration mit der REST-API einrichten.

Verwenden der Dynatrace-Integration

Sie können Dynatrace so konfigurieren, dass Bereitstellungsdatensätze an GitHub gesendet werden für Containerimages, die in Ihren Dynatrace-überwachten Kubernetes-Umgebungen ausgeführt werden. Dynatrace ordnet bereitgestellte Images Ihren Repositorys zu und meldet dann den Laufzeitkontext.

Darüber hinaus können Bereitstellungsdatensätze von Dynatrace den Laufzeitrisikokontext enthalten, z. B.:

  • Öffentliche Internetexposition
  • Zugriff auf vertrauliche Daten

Sie können diesen Kontext in der Filterung auf Organisationsebene und in Sicherheitskampagnen verwenden, um Korrekturen für Warnungen zu priorisieren, die sich auf Internet-offengelegte oder vertrauliche Datenworkloads auswirken.

Anweisungen zum Einrichten finden Sie in der Dynatrace-Dokumentation unter GitHub Advanced Security Sicherheitsintegration – Erste Schritte.

Verwenden der Microsoft Defender-for-Cloud-Integration

Sie können Ihre MDC Instanz mit Ihrer GitHub Organisation verbinden. MDC sendet automatisch Bereitstellungs- und Laufzeitdaten an GitHub.

Anweisungen zum Einrichten finden Sie unter "Schnellstart: Verbinden Ihrer Umgebung GitHubmit" Microsoft Defender for Cloud in der Dokumentation für MDC.

Hinweis

Die Integration mit Microsoft Defender for Cloud ist in öffentliche Vorschau und kann geändert werden.

Verwenden der REST-API

Der API-Endpunkt 'Erstellen eines Artefaktbereitstellungsdatensatzes' ermöglicht Systemen das Senden von Bereitstellungsdaten für ein bestimmtes Artefakt, wie dessen Name, Digest, Umgebungen, Cluster und Bereitstellung, an GitHub. Sie sollten diesen Endpunkt immer dann aufrufen, wenn ein Artefakt in einer neuen Staging- oder Produktionsumgebung bereitgestellt wird.

Hinweis

Wenn das Artefakt keinem Provenienznachweis GitHubzugeordnet ist, ist der github_repository Parameter obligatorisch.

Überprüfen eines Uploads

Um zu überprüfen, ob ein Datensatz erfolgreich hochgeladen wurde, können Sie das aktualisierte Artefakt in den Organisationseinstellungen anzeigen. Weitere Informationen findest du unter Überprüfen der Builds Ihrer Organisation auf den linked artifacts page.

Entfernen unerwünschter Datensätze

Es ist nicht möglich, ein Artefakt aus dem linked artifacts page. Sie können jedoch einen Speicherdatensatz oder Bereitstellungsdatensatz aktualisieren, um den Status eines Artefakts widerzuspiegeln. Weitere Informationen findest du unter Entfernen von Artefakten aus dem linked artifacts page.

Beispiele für GitHub Actions

Sie können Daten in denselben linked artifacts page Workflow hochladen, den Sie zum Erstellen und Veröffentlichen eines Artefakts verwenden.

Generieren eines Nachweises

Im folgenden Beispiel erstellen und veröffentlichen wir ein Docker-Image und verwenden dann die ${{ steps.push.outputs.digest }} Ausgabe im nächsten Schritt, um einen Provenienznachweis zu generieren.

Die attest-Aktion lädt automatisch einen Speicherdatensatz in den linked artifacts page hoch, wenn push-to-registry: true festgelegt ist und der Workflow die artifact-metadata: write-Berechtigung enthält.


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

Verwenden der REST-API

Alternativ können Sie die Artefaktmetadaten-API direkt aufrufen, wenn Sie keinen Nachweis generieren.


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

Nächste Schritte

Nachdem Sie Daten hochgeladen haben, können Teams in Ihrer Organisation den Kontext aus Speicher- und Bereitstellungsdaten verwenden, um Sicherheitswarnungen zu priorisieren. Weitere Informationen findest du unter Priorisieren von Dependabot- und Codeüberprüfungswarnungen mithilfe des Produktionskontexts.