Die Artefaktanalyse bietet zwei Möglichkeiten zum Scannen von Images: automatisches Scannen und On-Demand-Scannen. In diesem Dokument werden die Funktionen für beide Arten von Scans beschrieben.
Artefaktanalyse bietet auch eine Metadatenverwaltung. Weitere Informationen dazu, wie Sie Scannen und Metadatenspeicherung kombinieren können, um Ihre CI/CD-Pipeline von Anfang bis Ende zu schützen, finden Sie in der Übersicht zur Artefaktanalyse.
Weitere Informationen zu den Kosten für das Scannen von Container-Images finden Sie unter Preise.
In dieser Übersicht wird davon ausgegangen, dass Sie bereits mit der Verwendung von Docker-Repositories in der Artifact Registry oder der Container Registry (eingestellt) vertraut sind.
Automatischer Scan
Die Artefaktanalyse führt Scans auf Sicherheitslücken für Ihre Artefakte in Artifact Registry oder Container Registry (Eingestellt) durch. Bei der Artefaktanalyse werden auch Abhängigkeiten und Lizenzen ermittelt, damit Sie die Zusammensetzung Ihrer Software besser nachvollziehen können.
Das automatische Scannen umfasst zwei Hauptaufgaben: On-Push-Scannen und kontinuierliche Analyse.
On-Push-Scanning
Artefaktanalyse scannt neue Images, sobald sie in Artifact Registry oder Container Registry hochgeladen werden. Bei diesem Scan werden Informationen zu den Paketen im Container extrahiert. Die Bilder werden nur einmal und zwar anhand des Digest des Images gescannt. Das bedeutet, dass das Hinzufügen oder Ändern von Tags keine neuen Scans auslöst.
Artefaktanalyse erkennt nur Sicherheitslücken in Paketen, die öffentlich auf Sicherheitslücken überwacht werden.
Wenn der Scan eines Images abgeschlossen ist, ist das entstandene Sicherheitslückenergebnis die Sammlung der Vorkommen von Sicherheitslücken in einem Image.
Kontinuierliche Analyse
Die Artefaktanalyse erstellt Vorkommen für Sicherheitslücken, die beim Hochladen des Images gefunden wurden. Nach dem ersten Scan werden die Metadaten für gescannte Images in Artifact Registry und Container Registry kontinuierlich auf neue Sicherheitslücken geprüft.
Die Artefaktanalyse erhält mehrmals täglich neue und aktualisierte Informationen zu Sicherheitslücken aus Sicherheitslückenquellen. Wenn neue Sicherheitslückendaten eingehen, aktualisiert die Artefaktanalyse die Metadaten der gescannten Images, um sie auf dem neuesten Stand zu halten. Die Artefaktanalyse aktualisiert vorhandene Vorkommen von Sicherheitslücken, erstellt neue Vorkommen von Sicherheitslücken für neue Hinweise und löscht Vorkommen von Sicherheitslücken, die nicht mehr gültig sind.
Die Artefaktanalyse aktualisiert nur die Metadaten für Images, die in den letzten 30 Tagen per Push oder Pull übertragen wurden. Nach 30 Tagen werden die Metadaten nicht mehr aktualisiert und die Ergebnisse sind veraltet. Außerdem archiviert die Artefaktanalyse Metadaten, die seit mehr als 90 Tagen inaktiv sind. Diese Metadaten sind dann nicht mehr in der Google Cloud Console, in gcloud oder über die API verfügbar. Wenn Sie ein Image mit veralteten oder archivierten Metadaten noch einmal scannen möchten, übertragen Sie es per Pull. Das Aktualisieren von Metadaten kann bis zu 24 Stunden dauern.
Manifestlisten
Sie können die Sicherheitsrisikoprüfung auch mit Manifestlisten verwenden. Eine Manifestliste ist eine Liste von Verweispunkten auf Manifeste für mehrere Plattformen. Sie ermöglichen es, ein einzelnes Image mit mehreren Architekturen oder Varianten eines Betriebssystems zu verwenden.
Das Scannen auf Sicherheitslücken mit der Artefaktanalyse wird nur für Linux-amd64-Images unterstützt. Wenn Ihre Manifestliste auf mehrere Linux amd64-Images verweist, wird nur das erste gescannt. Wenn es keine Verweise auf Linux amd64-Images gibt, erhalten Sie keine Scanergebnisse.
On-Demand-Scanning
Mit dem On-Demand-Scanning können Sie Container-Images lokal auf Ihrem Computer oder in Ihrer Registry mit der gcloud CLI scannen. So können Sie Ihre CI/CD-Pipeline je nachdem anpassen, wann Sie auf die Ergebnisse der Sicherheitslückenprüfung zugreifen müssen.
Unterstützte Pakettypen
Wenn Sie Container-Images in Docker-Repositories in Artifact Registry pushen, kann Artefaktanalyse nach Sicherheitslücken in verschiedenen Arten von Betriebssystempaketen und Anwendungssprachpaketen suchen.
Container Registry wird eingestellt. Bei der Container Registry werden beim automatischen Scannen nur Betriebssystempakete geprüft. Wenn Sie Container Registry verwenden, informieren Sie sich hier über die Umstellung auf Artifact Registry.
In den folgenden Tabellen werden die Pakettypen verglichen, die mit den einzelnen Scandiensten von Artefaktanalyse gescannt werden können:
Unterstützte Betriebssystempakete
Automatisches Scannen mit Artifact Registry | Automatische Prüfung mit Container Registry (Eingestellt) | On-Demand-Scanning | |
---|---|---|---|
AlmaLinux OS | |||
Alpine | |||
CentOS | |||
Schutzblech | |||
Debian | |||
Google Distroless | |||
Red Hat Enterprise Linux (RHEL) | |||
Red Hat Universal Base Image (UBI) | |||
Rocky Linux | |||
SUSE Linux Enterprise Server (SLES) | |||
Ubuntu | |||
Wolfi |
Unterstützte Sprachpakete für Anwendungen
Automatisches Scannen mit Artifact Registry | Automatische Prüfung mit Container Registry (Eingestellt) | On-Demand-Scanning | |
---|---|---|---|
Go-Pakete | |||
Java-Pakete | |||
Node.js-Pakete | |||
PHP-Pakete | |||
Python-Pakete | |||
Ruby-Pakete | |||
Rust-Pakete | |||
.NET-Pakete |
Die Artefaktanalyse scannt nur Anwendungssprachpakete in Artifact Registry, wenn die Pakete containerisiert und in einem Repository im Docker-Format gespeichert sind. Die anderen Repository-Formate der Artifact Registry werden nicht unterstützt.
Weitere Informationen zu den Funktionen der einzelnen Registry-Produkte finden Sie im Vergleichsdiagramm.
Die Artefaktanalyse wird in Windows Server-Containern nicht unterstützt.
Artefaktanalyse-Schnittstellen
In der Google Cloud Console können Sie Sicherheitslücken und Metadaten von Images für Container in Artifact Registry ansehen.
Mit der gcloud CLI können Sie Sicherheitslücken und Image-Metadaten einsehen.
Sie können zu diesem Zweck auch die Artifact Analysis REST API verwenden. Wie bei anderen Cloud Platform-APIs müssen Sie sich vor dem Zugriff mit OAuth2 authentifizieren. Nach der Authentifizierung können Sie mit der API auch benutzerdefinierte Hinweise und Vorkommen erstellen und Sicherheitslückenvorkommen ansehen.
Die Artifact Analysis API unterstützt sowohl gRPC als auch REST/JSON. Sie können die API entweder über die Clientbibliotheken oder über cURL für REST/JSON aufrufen.
Bereitstellung anfälliger Images steuern
Mit der Binärautorisierung können Sie im Rahmen Ihrer Cloud Build-Pipeline eine Zulassungsliste für Sicherheitslücken erstellen, die auf den Informationen zu Sicherheitslücken basiert, die von der Artefaktanalyse zur Verfügung gestellt werden. Wenn die Sicherheitslücken gegen die Richtlinie in der Zulassungsliste verstoßen, schlägt der Build fehl.
Sie können die Artefaktanalyse auch mit der Binärautorisierung verbinden, um Attestierungen zu erstellen. Dadurch wird verhindert, dass Container-Images mit bekannten Sicherheitsproblemen in Ihrer Bereitstellungsumgebung ausgeführt werden.
Sicherheitslückenquellen
Im folgenden Abschnitt sind die Sicherheitslückenquellen aufgeführt, die bei der Artefaktanalyse verwendet werden, um CVE zu erhalten.
Betriebssystempaket-Scans
Für die Artefaktanalyse werden die folgenden Quellen verwendet:
- AlmaLinux OS
- Alpine
- CentOS: Red Hat und CentOS verwenden dieselbe Quelle für Sicherheitsdaten. Da CentOS-Pakete nach Red Hat-Paketen veröffentlicht werden, kann es einige Zeit dauern, bis eine für eine Sicherheitslücke in Red Hat verfügbare Korrektur auch für CentOS verfügbar ist.
- Kettenschutz
- Debian
- Google Distroless basiert auf Debian und verwendet die Debian-Sicherheitslückendaten.
- National Vulnerability Database
- Red Hat Enterprise Linux (RHEL)
- Red Hat Universal Base Image (UBI)
- Rocky Linux
- SUSE Linux Enterprise Server (SLES)
- Ubuntu
- Wolfi
Scans von Sprachpaketen
Die Artefaktanalyse unterstützt das Scannen auf Sicherheitslücken für Sprachpakete in einem Container-Image. Die Daten zu Sicherheitslücken stammen aus der GitHub Advisory Database.
In den meisten Fällen wird jeder Sicherheitslücke eine CVE-ID zugewiesen. Diese ID ist die Hauptkennung für diese Sicherheitslücke. Wenn einer Sicherheitslücke keine CVE-ID zugewiesen ist, wird stattdessen eine GHSA-ID als Kennung verwendet. Wenn diese Sicherheitslücke später eine CVE-ID erhält, wird die Sicherheitslücken-ID entsprechend aktualisiert. Weitere Informationen finden Sie unter Nach einer bestimmten Sicherheitslücke in einem Projekt suchen.
Unterstützte Betriebssystemversionen
Artefaktanalyse unterstützt das Scannen auf Sicherheitslücken für folgende Versionen von Betriebssystemsoftware:
- AlmaLinux-Betriebssystem – Versionen: 8, 9 und Nebenversionen
- Alpine Linux-Versionen: 3.3, 3.4, 3.5, 3.6, 3.7, 3.8, 3.9, 3.10, 3.11, 3.12, 3.13, 3.14, 3.15, 3.16, 3.17, 3.18, 3.19, 3.20
- CentOS-Versionen: 6, 7, 8 und Nebenversionen
- Chainguard: Rolling Updates auf einem einzelnen Release-Track.
- Debian GNU/Linux – Versionen: 9, 10, 11, 12
- Red Hat Enterprise Linux (RHEL): Versionen 6, 7, 8, 9 und Minor-Versionen werden für automatische Registrierungsscans unterstützt.
- Red Hat Universal Base Image (UBI) – Versionen 8, 9 und Nebenversionen
- Rocky Linux – Versionen: 8, 9 und Nebenversionen
- SUSE Linux Enterprise Server (SLES) – Versionen: 12, 15 und Minor-Versionen; SLES for SAP wird mit denselben Versionen unterstützt
- Ubuntu-Versionen: 12.04, 12.10, 13.04, 14.04, 14.10, 15.04, 15.10, 16.04, 16.10, 17.04, 17.10, 18.04, 18.10, 20.04, 20.10, 21.04, 21.10, 22.04, 22.10, 23.04, 23.10, 24.04
- Wolfi – Rolling-Updates auf einem einzelnen Release-Track.
Beschränkungen
- Die Artefaktanalyse liefert Ergebnisse des Sicherheitslücken-Scans für RHEL basierend auf der neuesten Nebenversion für jede veröffentlichte Hauptversion. Bei älteren Minor-Versionen von RHEL können Ungenauigkeiten in den Scanergebnissen auftreten.
- RHEL-Version 9 wird für On-Demand-Scans nicht unterstützt.
Paketmanager und semantische Versionierung
- Go – Artefaktanalyse: Hier werden Sicherheitslücken für Pakete in der Go-Standardbibliothek und externe Go-Pakete gemeldet, die nicht in der Standardbibliothek enthalten sind. Die Sicherheitslücken werden für jeden Pakettyp mit einem anderen Label gemeldet.
- Java – Die Artefaktanalyse unterstützt Maven-Pakete, die den Maven-Namenskonventionen entsprechen. Wenn die Paketversion Leerzeichen enthält, wird sie nicht gescannt.
- Node.js – Die Paketversion wird gemäß der Spezifikation für die semantische Versionsverwaltung abgeglichen.
- PHP – Bei der Artefaktanalyse werden Composer-Pakete gescannt. Weitere Informationen finden Sie unter Semantische Versionsverwaltung für Composer.
- Python: Die Python-Version wird gemäß der PEP 440-Semantik abgeglichen.
- Ruby: Bei der Artefaktanalyse werden RubyGems-Pakete gescannt. Weitere Informationen finden Sie unter Semantische Versionsverwaltung von RybyGems.
- Rust: Die Artefaktanalyse scannt Cargo-Pakete. Weitere Informationen finden Sie unter Semantische Versionsverwaltung in Rust.
- .NET – Die Artefaktanalyse scannt NuGet. Weitere Informationen finden Sie unter Semantische Versionierung mit NuGet.