Skip to main content

​
Übersicht

  • Funktion: Corgea meldet sich an Ihrer privaten Package-Registry an und kann so die internen Pakete analysieren, von denen Ihre Projekte abhängen – einschließlich aller Pakete, die diese internen Pakete mitbringen.
  • Zielgruppe: Teams, deren Anwendungen von intern veröffentlichten Paketen abhängen – gemeinsame Bibliotheken, Plattform-SDKs, eigene Frameworks –, die in einer privaten Registry statt in einer öffentlichen wie Maven Central, PyPI oder nuget.org liegen.

​
Warum Sie das brauchen

Corgea analysiert jede Abhängigkeit, indem es sie in der zugehörigen Registry nachschlägt. Öffentliche Pakete sind für alle zugänglich und funktionieren daher sofort. Interne Pakete nicht: Ohne Zugangsdaten kann Corgea sie nicht öffnen, und alles, was dahinter liegt, bleibt unsichtbar. Ohne verbundene Registry sehen Sie typischerweise:
  • Eine Dependency Analysis-Warnung für die betroffene Datei im Tab „Errors“ des Scans.
  • Interne Pakete ohne Unterabhängigkeiten, weil Corgea nicht hineinsehen konnte.
  • Fehlende Schwachstellen, weil alles, was nur über ein internes Paket erreichbar ist, nie analysiert wird.
Nach dem Verbinden werden Ihre internen Pakete wie jede andere Abhängigkeit behandelt: Sie erscheinen im Abhängigkeitsbaum mit allem, was sie mitbringen, und Schwachstellen darin werden wie gewohnt gemeldet, priorisiert und behoben.

​
Verfügbarkeit

Private Package-Registries stehen Enterprise-Kunden mit dediziertem Tenant zur Verfügung. Die Funktion wird pro Organisation freigeschaltet und ist standardmäßig deaktiviert – wenden Sie sich an support@corgea.com, um sie für Ihr Konto zu aktivieren.
Solange die Funktion für Ihre Organisation nicht aktiviert ist, wird sie ausgeblendet: Es gibt keinen Eintrag Package Registries auf der Integrations-Seite und kein Registry-Panel in den Projekteinstellungen.

​
Unterstützte Pakettypen

​
Kompatible Registries

Corgea verbindet sich über das Standardprotokoll des jeweiligen Pakettyps und ist damit nicht an einen Anbieter gebunden. Jede Registry, die Pakete so bereitstellt, wie es der Standard-Client erwartet, und Benutzername und Token akzeptiert, funktioniert. Dazu gehören:
  • Sonatype Nexus Repository
  • Azure Artifacts
  • GitHub Packages
  • Google Artifact Registry
  • MyGet
  • ProGet
  • Selbst gehostete Registry-Server

​
Vorbereitung

Sie benötigen:
  1. Eine Registry, die Corgea erreichen kann. Corgea verbindet sich über das Internet mit Ihrer Registry. Eine Registry, die nur aus Ihrem VPN oder privaten Netzwerk erreichbar ist oder hinter einer IP-Allowlist liegt, funktioniert erst, wenn Sie den Zugriff erlauben.
  2. Ein Token mit Leserechten. Corgea lädt nur Pakete herunter und liest deren Abhängigkeitsinformationen. Es veröffentlicht nie.
  3. Ein Token, das nicht schnell abläuft. Corgea speichert das angegebene Token und verwendet es bei jedem Scan erneut.
Manche Registries stellen kurzlebige Tokens aus, die nach wenigen Stunden ablaufen. Diese funktionieren beim ersten Scan und schlagen danach fehl. Verwenden Sie ein langlebiges Token, ein Dienstkonto oder einen API-Key.
Legen Sie ein eigenes Dienstkonto mit Leserechten für Corgea an, statt ein persönliches Token zu verwenden. So bleibt der Zugriff auf das Nötige beschränkt und die Verbindung funktioniert weiter, wenn jemand das Team verlässt.

​
Registry einrichten

​
Schritt 1 – Registry-Daten ermitteln

Erstellen Sie in Ihrer Registry ein Token (oder Dienstkonto) mit Lesezugriff auf die Repositories, die Corgea verwenden soll. Notieren Sie den zugehörigen Benutzernamen und die URL des Repositories.
Verwenden Sie die URL des Repositories, das Ihre internen Artefakte bereitstellt, zum Beispiel:

​
Schritt 2 – Registry in Corgea hinzufügen

Gehen Sie zu Integrations → Package Registries und klicken Sie auf Manage. Bereich Package Registries auf der Integrations-Seite
Zum Anlegen, Bearbeiten und Löschen einer Registry benötigen Sie die Berechtigung Manage Integrations. Siehe Berechtigungen.
Klicken Sie auf Add Registry. Liste der Package Registries mit konfigurierten Einträgen Füllen Sie das Formular aus: Formular Add Package Registry im Modus Structured form
Jeder Registry-Eintrag deckt einen Pakettyp ab. Wenn Ihre Registry Maven-, PyPI- und NuGet-Repositories hostet, legen Sie drei Einträge an – einen pro Pakettyp – jeweils mit der passenden URL.

​
Schritt 3 – Projekte auswählen

Lassen Sie Apply to all projects aktiv, damit jedes Projekt Ihrer Organisation die Registry nutzen kann, oder deaktivieren Sie die Option und wählen Sie einzelne Projekte. Siehe Projekte für eine Registry auswählen.

​
Schritt 4 – Neu scannen und Ergebnis prüfen

Starten Sie einen neuen Scan für ein Projekt, das von einem internen Paket abhängt, und prüfen Sie:
  • Die Dependency Analysis-Warnung für diese Datei ist im Tab „Errors“ verschwunden.
  • Ihr internes Paket zeigt nun Unterabhängigkeiten und lässt sich im Abhängigkeitsbaum aufklappen.
  • Schwachstellen, die nur in internen Paketen existieren, erscheinen jetzt.
Das Verbinden einer Registry verändert die Ergebnisse früherer Scans nicht. Starten Sie einen neuen Scan, um die verbesserte Abdeckung zu erhalten.
Kann Corgea Ihre Registry während eines Scans nicht erreichen, wird der Scan trotzdem mit öffentlichen Paketen abgeschlossen und zeigt eine Warnung für die betroffene Datei. Ein Registry-Problem lässt Ihren Scan nie fehlschlagen und blockiert Ihre Pipeline nicht – bis zur Behebung fehlen in den Ergebnissen jedoch Ihre internen Pakete.

​
Einrichtungsmethoden

​
Structured form (empfohlen)

Geben Sie URL, Benutzernamen und Token ein – um den Rest kümmert sich Corgea. Verwenden Sie diese Option, sofern kein besonderer Grund dagegen spricht.

​
Paste config file (fortgeschritten)

Wenn Sie für Ihre Registry bereits eine Konfigurationsdatei Ihres Paketmanagers pflegen, können Sie diese stattdessen einfügen. Wählen Sie diese Option, wenn Ihre Registry Einstellungen benötigt, die das Formular nicht abdeckt – etwa Mirrors, Proxies oder Regeln, welche Pakete aus welcher Quelle kommen. Formular Add Package Registry im Modus Paste config file Fügen Sie die Konfigurationsdatei ein, die Ihr Paketmanager für diese Registry bereits verwendet: eine Maven-settings.xml, eine pip-Konfigurationsdatei oder eine NuGet.Config.
Die Datei muss funktionierende Zugangsdaten enthalten. Wenn Ihre Datei ein verschlüsseltes oder Platzhalter-Passwort verwendet, ersetzen Sie es vor dem Einfügen durch ein echtes Token – Corgea kann das Passwortformat Ihrer Registry nicht entschlüsseln.
Wenn Sie bei einer bestehenden Registry die Einrichtungsmethode wechseln, geben Sie die Zugangsdaten für die neue Methode erneut ein. Corgea behält nur die Zugangsdaten der verwendeten Methode.

​
Projekte für eine Registry auswählen

Registries werden einmal für Ihre Organisation eingerichtet und dann auf zwei Wege auf Projekte angewendet:
  • Apply to all projects (Standard): Jedes Projekt Ihrer Organisation kann die Registry nutzen. Am besten für eine unternehmensweite Registry.
  • Einzelne Projekte: Nur die ausgewählten Projekte. Sinnvoll, wenn eine Registry einem Team gehört oder Sie die Funktion schrittweise einführen.

​
Ein einzelnes Projekt prüfen

Öffnen Sie ein Projekt und gehen Sie zu Settings → Package Registries, um zu sehen, welche Registries gelten:
  • Registries, die überall gelten, zeigen das Kennzeichen All projects. Ändern Sie diese unter Integrations → Package Registries.
  • Andere Registries zeigen einen Schalter, den Sie für dieses Projekt ein- oder ausschalten können.
  • Eine vollständig deaktivierte Registry zeigt das Kennzeichen Disabled.
Das Ändern der Registries eines Projekts erfordert die Berechtigung Change Project. Ist Project Access Control aktiv, benötigen Sie außerdem Zugriff auf dieses Projekt.

​
Mehrere Registries nutzen

Sie können beliebig viele Registries anlegen, und ein Projekt kann mehrere gleichzeitig nutzen:
  • Mehrere Registries für denselben Pakettyp: Pakete werden in allen nachgeschlagen.
  • Verschiedene Pakettypen: werden unabhängig voneinander behandelt.
  • Mehrere Repositories einer Registry: Führen Sie sie unter Additional repositories auf, statt separate Einträge anzulegen.
Verwenden Sie für einen Pakettyp durchgängig dieselbe Einrichtungsmethode. Nutzen einige Structured form und andere Paste config file, werden die eingefügten Dateien übersprungen.

​
Berechtigungen

Wie Sie diese zuweisen, steht unter Berechtigungsgruppen.

​
Sicherheit

Ihre Registry-Zugangsdaten werden als Geheimnisse behandelt:
  • Verschlüsselte Speicherung. Zugangsdaten werden verschlüsselt und nach dem Speichern nie wieder angezeigt. Beim Bearbeiten einer Registry ist das Token-Feld leer; bleibt es leer, behalten Sie Ihr bestehendes Token.
  • Nur während Scans verwendet. Zugangsdaten werden ausschließlich zur Anmeldung an Ihrer Registry während eines Scans genutzt.
  • Isoliert. Zugangsdaten und damit heruntergeladene Pakete werden nie mit einem anderen Scan oder einer anderen Organisation geteilt.
  • Nicht in Ihrem Repository. Corgea schreibt Ihre Zugangsdaten in keine erzeugte Datei.
  • In Logs und Meldungen verborgen. Zugangsdaten werden aus Fehlermeldungen und Diagnosen in Corgea entfernt.
  • Nur Lesezugriff. Corgea lädt ausschließlich Pakete herunter und liest deren Abhängigkeitsinformationen.

​
Registries in eingeschränkten Netzwerken

Blockiert Ihr Netzwerk öffentliche Registries und sollen alle Pakete über Ihre eigene Registry kommen, richten Sie Corgea auf ein Repository aus, das sowohl Ihre internen Pakete bereitstellt als auch die öffentlichen proxyt. Corgea erhält dann alles Nötige aus einer einzigen Quelle. Stellt Ihre Registry nur interne Pakete bereit und sind öffentliche Registries nicht erreichbar, kann die Abhängigkeitsanalyse nicht abgeschlossen werden.

​
Fehlerbehebung

Bedeutung: Corgea hat ein Paket gefunden, das es nicht nachschlagen konnte – meist ein internes Paket in einer Registry, an der keine Anmeldung möglich ist.Vorgehen: Legen Sie eine Registry für diesen Pakettyp an, stellen Sie sicher, dass sie für das Projekt gilt, und scannen Sie erneut. Ist bereits eine Registry verbunden, prüfen Sie URL und Gültigkeit des Tokens.
Bedeutung: Das Projekt soll eine private Registry nutzen, beim Start des Scans war jedoch keine nutzbare Registry verfügbar. Meist wurde die Registry deaktiviert, gilt nicht mehr für das Projekt oder wurde gelöscht.Vorgehen: Gehen Sie zu Integrations → Package Registries und prüfen Sie, dass eine Registry für diesen Pakettyp existiert, Enabled ist und entweder für alle Projekte gilt oder dieses einschließt.
Bedeutung: Corgea hat sich angemeldet, konnte die Pakete aber nicht abrufen. Häufige Ursachen: abgelaufenes oder widerrufenes Token, URL auf das falsche Repository, oder ein Paket, das nicht in der Registry liegt.Vorgehen: Prüfen Sie die Zugangsdaten von außerhalb Ihres Netzwerks:
401 oder 403 bedeutet falsche Zugangsdaten. 404 bedeutet eine falsche URL.
Bedeutung: Das Abrufen Ihrer Abhängigkeiten hat zu lange gedauert, meist bei sehr großen Projekten oder einer langsamen Registry.Vorgehen: Committen Sie Lock-Dateien, wo möglich, damit während des Scans weniger aufzulösen ist, und prüfen Sie die Antwortzeiten Ihrer Registry. Scannen Sie dann erneut.
Bedeutung: Das Repository enthält mehr unabhängige Module, als Corgea in einem Scan auflöst.Vorgehen: Sind die nicht abgedeckten Module relevant, teilen Sie sie in separate Corgea-Projekte auf oder committen Sie Lock-Dateien dafür.
Bedeutung: Ihre internen Pakete wurden abgerufen, die Schwachstellenprüfung darüber wurde jedoch nicht abgeschlossen.Vorgehen: Scannen Sie erneut. Ergebnisse für öffentliche Pakete sind nicht betroffen; es können nur Schwachstellen fehlen, die ausschließlich interne Pakete betreffen.
Bedeutung: Corgea benötigt zur Analyse Ihres Projekts einige öffentlich verfügbare Komponenten, die weder Ihre Registry noch das öffentliche Internet bereitstellt.Vorgehen: Richten Sie die Registry auf ein Repository aus, das auch öffentliche Pakete proxyt. Siehe Registries in eingeschränkten Netzwerken.
Bedeutung: Hier ist nichts zu tun – Corgea ergänzt seinen Registry-Zugriff zusätzlich zu einer in Ihrem Repository eingecheckten Konfiguration, statt sie zu ersetzen. Ihre bestehenden Quellen und Regeln gelten weiter.Vorgehen: Fehlen dennoch Quellen, prüfen Sie, ob eine in Ihrem Repository eingecheckte Konfigurationsdatei valide ist. Eine nicht lesbare Datei lässt Corgea unangetastet, statt Ihren Build zu gefährden.
Bedeutung: Das funktioniert, Ihr Token wird jedoch unverschlüsselt übertragen.Vorgehen: Verwenden Sie außerhalb lokaler Tests https.
Bedeutung: Die Funktion ist standardmäßig deaktiviert und wird in diesem Zustand ausgeblendet statt als gesperrt angezeigt – es ist also nichts anklickbar.Vorgehen: Private Package-Registries stehen Enterprise-Kunden mit dediziertem Tenant zur Verfügung. Wenden Sie sich an support@corgea.com, um die Funktion für Ihre Organisation zu aktivieren, und laden Sie anschließend die Integrations-Seite neu.

​
Best Practices

Beginnen Sie mit einer Registry für ein einzelnes Projekt, prüfen Sie den Abhängigkeitsbaum und wenden Sie sie dann auf alle Projekte an.
  • Eigenes Dienstkonto mit Leserechten statt eines persönlichen Tokens verwenden.
  • Langlebige Tokens nutzen und deren Ablaufdaten verfolgen, damit Scans nicht unbemerkt Abdeckung verlieren.
  • Einen Eintrag pro Pakettyp anlegen, jeweils mit der passenden URL.
  • Ein Repository bevorzugen, das auch öffentliche Pakete proxyt – das funktioniert unabhängig davon, ob Ihr Netzwerk eingeschränkt ist.
  • Das strukturierte Formular bevorzugen und eine eingefügte Konfigurationsdatei nur verwenden, wenn Sie Einstellungen benötigen, die es nicht abdeckt.
  • Lock-Dateien committen, wo es praktikabel ist. Scans sind schneller und Ergebnisse konsistenter.
  • Tokens regelmäßig rotieren und die Registry in Corgea aktualisieren. Lassen Sie das Token-Feld beim Bearbeiten leer, wenn Sie es nicht ändern.

​
Verwandte Themen