Kommentare in Pull Requests

Kommentare in Pull Requests zeigen deinem Team direkt im Pull Request, welche Abhängigkeitsversionen im Lockfile einen bekannten Sicherheitshinweis haben, angefangen mit denen, die die Änderung hinzufügt. Das ist eine Deep-Funktion, und sie ist aus, bis du sie einschaltest.

Was sie tut

Wenn ein Pull Request geöffnet wird, neue Commits bekommt oder wieder geöffnet wird, liest Lockpick dein Lockfile an zwei Stellen: am Head des Pull Requests und an der Stelle, an der sein Branch vom Basis-Branch abgezweigt ist (der Merge-Base). Es prüft die exakten Versionen an beiden Stellen gegen bekannte Sicherheitshinweise.

Die Prüfung ist deterministisch. Es wird kein Code ausgeführt, und keine KI bewertet sie.

Lockpick vergleicht die beiden Listen und kann so unterscheiden, was der Pull Request hinzufügt oder ändert und was schon vorher da war. Probleme, die nach dem Abzweigen des Branches auf deinem Basis-Branch gelandet sind, werden ihm nicht angerechnet.

Es liest jedes Lockfile, das das Repository hat, oder die, die du gewählt hast. Jedes Lockfile wird für sich geprüft, sodass die Go-Module und die JavaScript-Projekte eines Monorepos alle abgedeckt sind. Ein Lockfile, das der Pull Request nicht ändert, wird nicht erneut heruntergeladen, wenn Lockpick genau diese Datei schon gelesen hat.

Unterstützte Lockfiles

Gelesen werden nur die exakten Versionen, die ein Lockfile festlegt. Nichts wird aufgelöst, installiert oder ausgeführt.

Zwei Dateien werden nur erkannt, um dir zu sagen, wie du sie prüfbar machst:

• bun.lockb ist Buns binäres Lockfile. Führe bun install --save-text-lockfile aus, committe das bun.lock, das dabei entsteht, und wähle es.
• Ein Gradle-Build ohne Lockfile (build.gradle oder build.gradle.kts) kann nicht geprüft werden. Aktiviere Dependency Locking (dependencyLocking { lockAllConfigurations() }), führe ./gradlew dependencies --write-locks aus, committe gradle.lockfile und wähle es.

Für diese, und für jedes Lockfile, das Lockpick nicht lesen konnte, sagt der Kommentar, dass er nicht prüfen konnte, nie, dass der Pull Request sauber ist.

Einschalten

Du brauchst:

• eine Website, deren GitHub-Repository verbunden ist, unter Einstellungen und dann Repository;
• Deep oder Master Key im Workspace;
• das Recht, die Website zu verwalten.

Wenn du ein Repository verknüpfst, wird Kommentare in Pull Requests eingeschaltet. Es gibt einen Schalter pro Website, unter Einstellungen und dann GitHub. Schaltest du ihn dort aus, bleibt er aus, auch wenn du dasselbe Repository erneut verknüpfst; ein anderes Repository zu verknüpfen schaltet ihn wieder ein. Ohne Deep oder Master Key zeigt der Schalter „An, aber pausiert“, und nichts wird gepostet.

Wenn du ein Repository verknüpfst, prüft Lockpick jedes Lockfile, das es findet, bis zu 20, und sucht sie bei jedem Lesen des Repositorys neu, sodass auch ein später hinzugefügtes Projekt abgedeckt ist. Lockfiles in testdata- und fixtures-Ordnern werden ausgelassen, und die Sprachen, die GitHub im Repository zählt, entscheiden, welche zuerst kommen: bei einem Repository, das größtenteils Go ist, seine go.mod-Dateien. Du kannst Lockfiles abwählen oder stattdessen einen Pfad wie apps/web/pnpm-lock.yaml eingeben; eine Liste, die du wählst, bleibt bestehen, bis du wieder alle Lockfiles auswählst.

Was der Kommentar zeigt

Lockpick führt einen Kommentar pro Pull Request und bearbeitet ihn an Ort und Stelle. Es postet nicht für jeden Push einen neuen Kommentar.

Jeder Pull Request bekommt den Kommentar, ob er das Lockfile berührt oder nicht. Er listet jede Abhängigkeitsversion am Head des Pull Requests auf, die einen bekannten Sicherheitshinweis hat, direkt und transitiv. Eine Zeile oben zählt sie nach Schweregrad, zum Beispiel „81 verwundbare Versionen: 6 kritisch · 14 hoch · 30 mittel“. Die Zeilen sind sortiert: zuerst Bekannt ausgenutzt, dann kritisch, hoch, mittel, niedrig und Nicht bewertet, dann nach Paketname:

• Von diesem Pull Request hinzugefügt oder geändert: Jede Zeile zeigt das Paket, die Version (und die Version, die sie ersetzt hat, wenn der Pull Request sie geändert hat), den Schweregrad, ein Abzeichen Bekannt ausgenutzt, wenn Angreifer das Problem bereits ausnutzen, einen Link zum Sicherheitshinweis und die Version, die es behebt;
• Nach diesem Pull Request weiterhin im Repository: verwundbare Versionen, die auf dem Basis-Branch waren und am Head des Pull Requests noch da sind. Die 25 schwerwiegendsten über alle Lockfiles werden gezeigt, gruppiert unter jedem Lockfile, mit einem Link zum Rest in Lockpick;
• bei einem Go-Repository zählt auch die Go-Version, mit der es baut (die toolchain-Zeile in go.mod, sonst die go-Zeile). Ihre Sicherheitshinweise zur Standardbibliothek sind eine Zeile, Go-Standardbibliothek, mit ihrer Anzahl und dem Release, das sie alle behebt. Lockpick vergleicht nur Versionen und sagt deshalb, dass die Erreichbarkeit nicht geprüft wurde;
• eine Zeile, die sagt, wie viele Sicherheitshinweise der Pull Request behebt, und eine kurze Liste der Versionen, die er behoben hat (Paket, die alte Version → die neue, oder entfernt), die schwerwiegendsten zuerst. Die ersten 10 werden gezeigt, mit einem Link zum Rest.

Wenn keine Version einen bekannten Sicherheitshinweis hat, sagt der Kommentar das in einer Zeile und nennt das Lockfile und den Commit, den er gelesen hat.

Wenn ein späterer Commit das Bild ändert, bearbeitet Lockpick den Kommentar. Eine veraltete Warnung bleibt nicht stehen.

Wenn Lockpick das Lockfile nicht lesen kann, sagt es, dass es nicht prüfen konnte. Das passiert, wenn die Datei größer als 25 MB ist, ein anderes Format hat oder fehlt. Bei einem fehlenden Lockfile sagt es, wo es gesucht hat (auf dem Basis-Branch und am Head des Pull Requests), schlägt das Lockfile vor, auf das die Sprachen des Repositorys hinweisen, und verlinkt die Einstellung. Es sagt nie, dass der Pull Request sauber ist, wenn es die Datei nicht gelesen hat.

Manche Sicherheitshinweise, etwa viele in der Go-Schwachstellendatenbank, haben keinen Schweregrad. Lockpick nimmt dann den Schweregrad einer passenden CVE oder eines passenden GitHub-Sicherheitshinweises, den es hat; gibt es keine, zeigt die Zeile Nicht bewertet und steht nach den bewerteten.

Berechtigungen

Die Lockpick-GitHub-App liest Contents und Metadata. Für diese Funktion braucht sie außerdem Pull requests mit Lese- und Schreibzugriff, damit sie den Pull Request lesen und den Kommentar posten kann.

Lockpick nutzt kurzlebige Tokens, die auf das eine Repository beschränkt sind. Es merged nicht, und es ändert deinen Code nicht.

Bestehende Installationen

Wenn du die Lockpick-GitHub-App vor dieser Funktion installiert hast, musst du die neue Berechtigung auf GitHub akzeptieren. Der Inhaber der Installation bekommt eine E-Mail, und GitHub zeigt auf der Einstellungsseite der Installation einen Hinweis.

Bis sie akzeptiert ist, zeigt Einstellungen und dann Repository Berechtigung ausstehend, mit einem Link zur Installation. Du kannst den Schalter schon vorher einschalten. Er beginnt zu arbeiten, sobald du akzeptierst.

Kontingent und Grenzen

Kommentare in Pull Requests verbrauchen kein Scan-Kontingent. Sie erzeugen keinen Scan.

Damit es fair bleibt, führt Lockpick etwa 20 Prüfungen pro Stunde für jeden Pull Request aus und 600 pro Stunde für jeden Workspace. Eine Prüfung, die eine Grenze ablehnt, wird verworfen. Der nächste Push nach Ablauf der Stunde versucht es erneut und liest immer den neuesten Commit.

In wessen Namen sie handelt

Die Lockpick-GitHub-App postet den Kommentar, aber der Schalter läuft mit dem Zugriff der verwaltenden Person, die ihn eingeschaltet hat.

• Verliert diese Person den Zugriff auf die Website, schaltet sich die Funktion selbst aus. Eine andere verwaltende Person kann sie wieder einschalten.
• Verliert der Workspace Deep, pausiert die Funktion, und die Kommentare hören auf. Sie läuft von selbst weiter, wenn du upgradest.

Ausschalten

Schalte den Schalter aus, trenne das Repository oder wähle ein anderes Repository, und Lockpick hört auf. Kommentare, die schon auf GitHub stehen, bleiben dort. Lockpick löscht sie nie.

Wenn du die Lockpick-GitHub-App auf GitHub deinstallierst, verliert Lockpick jeden Zugriff auf das Repository.

Wenn zwei Websites dasselbe Repository nutzen

Wenn zwei Lockpick-Websites dasselbe Repository verbinden, führt nur eine von ihnen den Kommentar. Der Pull Request bekommt trotzdem einen Kommentar, nicht zwei.