Security führt ein Verzeichnis über alle Pakete, die jedes Projekt installiert, und vergleicht es mit veröffentlichten Warnhinweisen. So wird eine anfällige Version erkannt, sobald sie in einen pull request gelangt – und erneut, wenn ein neuer Warnhinweis eine bereits genutzte Version betrifft.
Das Verzeichnis
Beim jeweiligen neuen Head des Standard-Branches sowie mindestens einmal täglich liest Coroid die Lockdateien des Projekts mit OSV-Scanner, der auf einer bestimmten Version fixiert ist und gegen seinen veröffentlichten Prüfsummenwert überprüft wird. Der Scanner erhält nur die Abhängigkeitsdateien sowie eine von Coroid generierte Konfiguration – ohne Netzwerkzugriff oder Anmeldeinformationen. Ein eigenes osv-scanner.toml hat keine Auswirkung.
Unter Sicherheit → Abhängigkeiten wird das Verzeichnis jedes Projekts angezeigt: die Pakete samt ihren installierten Versionen, welches Manifest jeweils welches Paket deklariert, welche anfällig sind, die Abdeckung jeder Datei sowie wann die Warnhinweis-Daten zuletzt gelesen wurden. Exportieren CycloneDX lädt das Verzeichnis als CycloneDX 1.5-Datei herunter. Darin werden nur Schwachstellen aufgeführt, die bereits öffentlich bekannt sind. Siehe Offenlegung.
Was Coroid vollständig ausliest
Die Abdeckung erfolgt pro Lockdatei, nicht pro Repository. In einem Monorepo bildet jede Lockdatei eine eigene Gruppe mit eigener Abdeckung – somit bleiben die Ergebnisse einer vollständigen Lockdatei gültig, auch wenn ein anderes Manifest nur teilweise abgedeckt ist.
| Datei | Ökosystem | Exakte Versionen | Vollständige transitive Abhängigkeiten | Abdeckung |
|---|---|---|---|---|
package-lock.json | npm | Ja | Ja | Vollständig |
npm-shrinkwrap.json | npm | Ja | Ja | Vollständig |
pnpm-lock.yaml | npm | Ja | Ja | Vollständig |
yarn.lock | npm | Ja | Ja | Vollständig |
requirements.txt | PyPI | Ja | Nein | Teilweise |
go.mod | Go | Ja | Nein | Teilweise |
Diese Tabelle wird aus den Testdaten von Coroid generiert, die über den Scanner ausgeführt werden – sie ändert sich also nur, wenn die Tests angepasst werden.
- npm-Workspaces, pnpm und Yarn: Ein Workspace-
package.jsonohne eigene Lockdatei wird vom Root-Lockfile abgedeckt. Einpackage.json, das nicht mehr mit seiner Lockdatei übereinstimmt, gilt als teilweise abgedeckt, bis die Lockdatei neu generiert wird. - npm-Lockdateien müssen Version 2 oder 3 sein. Einträge für pnpm und Yarn, die aus Git, einer lokalen Datei oder einem Patch stammen, werden als teilweise abgedeckt gewertet.
requirements.txtdeckt nur Versionen ab, die mit==.- Andere Abhängigkeitsdateien (
package.jsonohne Lockdatei,pyproject.toml,poetry.lock,Pipfile,Cargo.lock,Gemfile.lock,pom.xml, Gradle, Composer, NuGet und andere) werden gefunden und als teilweise abgedeckt angezeigt – inklusive des Dateinamens –, sodass ein Projekt niemals als vollständig abgedeckt gilt, wenn dies nicht der Fall ist.
Warnhinweise
Coroid liest Warnhinweise aus OSV, das auch die Warnhinweise von GitHub enthält, für jedes Ökosystem, das Ihre Projekte nutzen. Stündlich werden neue oder geänderte Einträge gelesen, täglich der gesamte Bestand. Der Vergleich erfolgt anhand der gespeicherten Verzeichnisse – somit ist kein Zugriff auf Ihr Repository nötig.
Coroid zielt darauf ab, 95 % der neuen Warnhinweise innerhalb von 60 Minuten nach ihrer Veröffentlichung in den gelesenen Daten mit jedem Verzeichnis abzugleichen – dabei wird die benötigte Zeit pro Abgleich gemessen. Eine zeitliche Garantie ab dem ursprünglichen Bekanntwerden einer Schwachstelle kann nicht gegeben werden: Dies hängt davon ab, wann der Warnhinweis veröffentlicht wird.
Ist die Warnhinweis-Datenquelle mehr als 90 Minuten verzögert oder der letzte Lesevorgang fehlgeschlagen, zeigen Übersicht und Abhängigkeiten den Hinweis „Warnhinweis-Feed verspätet seit …“ an – solange gilt die Abdeckung keines Projekts als vollständig.
Wird ein Warnhinweis zurückgezogen, berechnet Coroid neu, welche der verbleibenden Warnhinweise für dieselbe Schwachstelle noch gelten. Ein Fund wird nur als „Nicht mehr anwendbar“ geschlossen, wenn keine passenden Warnhinweise mehr vorliegen – niemals als „behoben“.
Auf Pull Requests
Der Coroid Security -Check prüft die Lockdateien, die pull request geändert hat – sowohl am Basisstand als auch am Head – und zählt nur die anfälligen Versionen, die durch die Änderung eingeführt werden:
- Beobachten: Der Check besteht oder meldet neutral, welche Befunde festgestellt wurden.
- Erzwingen: Eine Änderung, die eine als anfällig bekannte Version mit dem gewählten Schweregrad (standardmäßig hoch) oder höher einführt, besteht den Prüfungsvorgang nicht. Ebenso scheitert die Prüfung bei unvollständiger Abdeckung der von der Änderung betroffenen Lockdatei – dabei wird angegeben, warum dies der Fall ist und wie die Prüfung erneut ausgeführt werden kann.
Dieselbe Prüfung wird vor dem Öffnen von Fix- und Feature-Pull-Requests von Coroid selbst durchgeführt. Informationen dazu, wie sich die Prüfung verhält, wie sie erforderlich gemacht werden kann und wie sie erneut ausgeführt wird, finden Sie unter GitHub-Berechtigungen und die Coroid-Sicherheitsprüfung.
Benachrichtigungen
Das erste vollständige Inventar eines Repositorys bildet eine stille Basislinie: Die darin enthaltenen Ergebnisse werden in der Rubrik Sicherheit angezeigt, ohne dass Benachrichtigungen versendet werden. Danach informiert eine neue kritische Abhängigkeitserkennung die Organisationseigentümer und Administratoren einmalig über das Benachrichtigungssystem, per E-Mail, sofern E-Mail aktiviert ist, sowie über Slack, sofern Slack verbunden ist. Bei einer öffentlichen Warnung nennt das Benachrichtigungssystem das betreffende Paket und die Warnung; bei noch nicht öffentlichen Warnungen wird lediglich darauf hingewiesen, dass eine kritische Erkennung Aufmerksamkeit erfordert. Weitere Details finden Sie unter Offenlegung.