Zwei Schutzmechanismen prüfen den Code selbst: Code-Scanning wendet feste Regeln auf jede Änderung und auf die Standardbranch an, und Sicherheits-Rezension von Pull Requests überprüft die von Coroid Rezension aufgezeigten Sicherheitsprobleme, bevor eines davon einen pull request zum Scheitern bringen kann.
Code-Scanning
Coroid's Regeln
Die Abteilung Sicherheit ist für diese Regeln zuständig. Sie gehörten zu den Anti-Slop-Maßnahmen in der Qualitätskontrolle und befinden sich nun hier – jede Regel hat somit ihren festen Platz:
| Regel | Sucht nach |
|---|---|
security.hardcoded-secret | Anmeldeinformationen, die im Code hinterlegt sind. Siehe Gekappte Geheimnisse. |
security.tls-disabled | TLS-Zertifikatsüberprüfung deaktiviert. |
security.auth-removed | Authentifizierungs- oder Berechtigungsfilter, Dekoratoren oder Middleware wurden entfernt oder auskommentiert. |
security.cors-wildcard-credentials | Jeder Ursprung ist zusammen mit Anmeldeinformationen erlaubt. |
security.sql-concat | SQL wird aus interpolierten Zeichenfolgen erstellt und an eine Abfragefunktion übergeben. |
security.eval | Code, der aus Eingaben ausgeführt wird: eval, new Function, nicht gesäubert dangerouslySetInnerHTML. |
security.remote-script-exec | Heruntergeladene Skripte werden direkt in eine Shell oder einen Interpreter eingespeist. |
security.policy-changed | Änderungen an der Scanner-Konfiguration. Siehe Schutzmaßnahmen und Durchsetzung. |
deps.nonexistent | Neue Abhängigkeiten, die in ihrem Registry nicht existieren. |
deps.known-malicious | Neue Abhängigkeiten mit einer Warnung vor bösartigen Paketen. |
deps.suspicious-new | Neue Abhängigkeiten, die vor weniger als 30 Tagen veröffentlicht wurden, sehr wenige Downloads aufweisen, einen Namen haben, der nur ein oder zwei Buchstaben von einem populären Paket abweicht, oder kürzlich einen neuen Maintainer erhielten. |
deps.install-script | Neue npm-Abhängigkeiten, die beim Installieren ein Skript ausführen. |
Die Regeln zur Abhängigkeitshygiene, nicht fixierte Versionen sowie Abweichungen zwischen Manifest- und Lockfile bleiben in der Qualitätskontrolle bei Anti-Slop. Siehe Anti-Slop.
Die Regeln werden bei Änderungen ausgeführt, im selben Scan wie die Anti-Slop-Prüfung der Qualitätskontrolle, sowie bei jedem Push und täglich auf der Standardbranch – unabhängig davon, ob Anti-Slop aktiviert ist. Die Abteilung Sicherheit, nicht die Einstellungen von Anti-Slop, bestimmt die Wirkung jeder Regel. Unter Sicherheit → Einstellungen → Code-Scanning sind sie aufgelistet. Solange das Code-Scanning die Regeln nicht durchsetzt, behält jede Regel die Aktion bei, die sie in der Qualitätskontrolle hatte – eine Regel, die zum Blockieren eingestellt war, blockiert also weiterhin.
Ihr eigener Scan-Befehl
Falls Ihr Projekt bereits über einen Sicherheitsscanner verfügt, geben Sie dessen Befehl unter
Ihr eigener Scan-Befehl im Bereich Code-Scanning ein. Er wird als Projekt-
security_scan Prüfung bei jeder Änderung ausgeführt. Lassen Sie das Feld leer, um den Scanner zu deaktivieren.
Ergebnisse externer Tools wie SonarQube, Snyk oder Semgrep können ebenfalls als Rezensionsnachweise bei Coroid eingereicht werden. Siehe Anbieter von Rezensionsnachweisen.
Sicherheits-Rezension von Pull Requests
Coroid Rezension prüft Pull Requests in der Qualitätskontrolle. Wenn ein Sicherheitsproblem festgestellt wird, wird es nicht als Fließtext in die Rezension eingetragen. Das Problem wird vielmehr als strukturierter Nachweis gemeldet: Art der Schwachstelle, Datei und Zeilen sowie Schweregrad. Die Abteilung Sicherheit speichert jeden Nachweis als Noch nicht bestätigt.
Die unabhängige Prüfung
Bei kritischen und hohen Nachweisen führt Coroid eine unabhängige Prüfung durch: ein separater, begrenzter Modellaufruf, der die in dem Nachweis genannte Datei am Head-Commit des pull request betrachtet und das Problem selbst ableiten muss. Falls dies gelingt, wird der Nachweis zu einem validierten statischen Fund. Falls der Code, der das Problem bestimmt, in einer anderen Datei liegt, kann die Prüfung ihn nicht bestätigen – der Nachweis bleibt dann unbestätigt.
Die Prüfung verbraucht die Credits Ihrer Organisation wie andere Modellaufgaben, innerhalb festgelegter Grenzen pro pull request. Sobald die Credits oder Stunden aufgebraucht sind, wird die Prüfung nicht ausgeführt – die Rezension gibt dann an: „Ein mögliches Sicherheitsproblem konnte nicht verifiziert werden: Die Credits oder Stunden der Organisation sind aufgebraucht.“
Was die Rezension zum Scheitern bringt
| Beobachten | Durchsetzen | |
|---|---|---|
| Ein bestätigter Nachweis ab dem Schwellenwert (standardmäßig hoch) | Neutral, „FUND BESTÄTIGT“ | Coroid Rezension-Prüfung scheitert, „FUND BESTÄTIGT“ |
| Ein Nachweis, der nicht bestätigt ist | Scheitert nie | Scheitert nie |
Ein durchgesetzter, bestätigter kritischer oder hoher Nachweis führt zum Scheitern von Coroid Rezension – selbst wenn die Rezension in der Qualitätskontrolle auf beratend gesetzt ist. Dies ist die einzige Ausnahme davon, dass beratende Rezensionen nie scheitern. Eine Rezension, die nur aufgrund nicht bestätigter Sicherheitsnachweise Änderungen verlangt, gilt als beratend.
Die Sicherheits-Rezension erfordert, dass Coroid Rezension für das Projekt aktiviert ist. Ist Coroid Rezension deaktiviert, wird dies in der Zeile unter Sicherheit → Einstellungen angezeigt.
Was bei GitHub ankommt
Bevor jeglicher Review-Text, Kommentar oder Check bei GitHub ankommt, durchläuft er das Veröffentlichungsgateway. In einem öffentlichen Repository oder in einem Repository, dessen Sichtbarkeit Coroid nicht bestätigen kann, wird ein nicht öffentliches Sicherheitsproblem durch die Meldung „Coroid hat ein mögliches Sicherheitsproblem festgestellt; Details finden Sie unter Coroid“ ersetzt – samt Link. Siehe Offenlegung.