Regeln erkennen bekannte Muster. Die Sicherheitsprüfung sucht nach dem, was Regeln übersehen: Ein AI-Modell liest den wichtigsten Code des Projekts sowie den Code, der seit der letzten Prüfung geändert wurde, um Schwachstellen zu identifizieren. Nur das, was eine unabhängige Überprüfung bestätigt, zählt als Ergebnis.
Aktivierung
Sicherheit → Einstellungen → Sicherheitsprüfung verfügt über einen Schalter und legt die Ausführungshäufigkeit fest: täglich, wöchentlich (Standardeinstellung) oder monatlich. Solange Sie den Schalter nicht umlegen, folgt die Prüfung Ihrem Plan: bei kostenpflichtigen Abos aktiviert, bei der kostenlosen Version deaktiviert. Sie können die Prüfung für eine kostenlose Organisation aktivieren oder für eine kostenpflichtige Organisation deaktivieren – entweder für die Organisationseinstellungen oder für ein einzelnes Projekt.
Die Prüfung liest den Standardzweig jedes Projekts aus, in dem sie aktiviert ist.
Was eine Ausführung bewirkt
- Dateien auswählen. Coroid ordnet die Quelldateien des Projekts nach Priorität und liest zuerst die wichtigsten Dateien: Code im Bedrohungsmodell's hochrelevante Pfade und Einstiegspunkte, wobei Code, der seit der letzten Prüfung geändert wurde, vor unverändertem Code geprüft wird. Eine Ausführung liest maximal 40 Dateien.
- Schwachstellen suchen. Für jede Datei sucht das Modell nach einer festen Reihe von Schwachstellentypen: SQL-, Befehls- und andere Injektionsangriffe, Cross-Site-Scripting, Cross-Site-Request-Forgery, Server-Side-Request-Forgery, Pfaddurchquerung, offene Umleitungen, unsichere Deserialisierung, fehlende Zugriffssteuerung, fehlerhafte Authentifizierung, hartcodierte Zugangsdaten, schwache Kryptografie, Informationsfreigabe und Ressourcenüberlastung. Es muss die betreffenden Zeilen nennen; Antworten, die auf Elemente außerhalb des gezeigten Codes verweisen, werden ignoriert.
- Bestätigen. Jedes Problem wird als Noch nicht bestätigt. Bei kritischen und hochgradigen Problemen führt eine unabhängige Überprüfung das Problem erneut aus dem Code dieses Commits ab. Falls dies der Fall ist, wird das Problem zu einem bestätigten Ergebnis mit einem validierten statischen Nachweis als Beleg. Siehe Nachweise.
- Beweisen. Bei einem bestätigten kritischen oder hochgradigen Ergebnis erstellt die Prüfung einen Beweis und führt ihn zweimal gegen Ihre kompilierte Anwendung aus. Siehe Beweise.
- Varianten suchen. Fehler treten oft in Gruppen auf. Für jedes bestätigte Ergebnis durchsucht Coroid das Repository nach demselben Muster und prüft jeden Treffer auf die gleiche Weise.
Ergebnisse der Prüfung werden unter Sicherheitsprüfung als Quelle in Sicherheit → Ergebnisse angezeigt.
Kosten
Die Prüfung nutzt ein AI-Modell, wodurch sie wie andere Aufgaben Ihre Credits und Agentenstunden verbraucht. Während der Ausführung wird sie in Mission Control angezeigt und in Einstellungen → Aktivität mit ihren Kosten aufgeführt.
Jede Ausführung hat ein Budget. Sobald dieses erreicht ist oder Ihre Credits bzw. Agentenstunden aufgebraucht sind, wird die Ausführung gestoppt und das bereits Bestätigte bleibt erhalten; die nächste Ausführung beginnt erneut mit dem wichtigsten Code. Bei großen Projekten erstreckt sich die Ausführung über mehrere Jobs, sodass eine einzelne Ausführung nie lange einen Agentenplatz belegt.
Behebung der gefundenen Probleme
Ein bestätigtes Ergebnis mit einer Behebungspriorität ab dem festgelegten Schwellenwert initiiert automatisch eine Behebungsaufgabe unter dem Mandat „Sicherheitsbehebungen“ – genauso wie bei einer vulnerablen Abhängigkeit. Inhaber und Administratoren können auch Beheben bei jedem offenen Code-Ergebnis auswählen. Siehe Behebungs-Pull-Requests.
Ein Prüfungsergebnis betrifft Ihren eigenen Code und ist daher nicht öffentlich. In öffentlichen Repositorys oder bei Repositorys, deren Sichtbarkeit Coroid nicht bestätigen kann, wird die Behebung bis zur Veröffentlichung durch einen Inhaber oder Administrator privat gehalten. Siehe Offenlegung.
Beweise
Bei einem bestätigten kritischen oder hochgradigen Ergebnis erstellt die Prüfung zudem einen Beweis: einen kleinen Black-Box-Test, der das schwachstellenanfällige Verhalten von außerhalb der laufenden Anwendung zeigt – beispielsweise wenn ein Nutzer die Bestellung eines anderen Nutzers einsehen kann. Das Modell kann die Erstellung eines solchen Beweises ablehnen, wenn das Problem auf diese Weise nicht nachgewiesen werden kann; in diesem Fall bleibt die unabhängige Überprüfung als Beleg bestehen.
Coroid führt den Beweis gegen Ihr Projekt aus, das vom geprüften Commit kompiliert wurde:
- Es holt sich diesen Commit, installiert die Abhängigkeiten und kompiliert die Anwendung – genauso wie bei einer Vorschau.
- Der Kompilierungsvorgang startet in einer isolierten Umgebung ohne Ausgangsmöglichkeiten: kein Internet, keine externen Namensauflösungen, keine anderen Dienste, keine Zugangsdaten und keine Kundendaten. Datenbanken, Caches oder Warteschlangen, die die Anwendung benötigt, laufen ebenfalls in derselben Umgebung – allerdings leer. Vor dem Ausführen des Beweises prüft die Umgebung, ob tatsächlich kein Zugriff auf externe Elemente möglich ist; falls doch, wird die Ausführung gestoppt und es werden keine Ergebnisse aufgezeichnet.
- Der Beweis, der dazu dient, über die Anwendung eigene Nutzer und Daten zu erstellen, wird ausgeführt und meldet, ob der Fehler aufgetreten ist.
Eine zweite Ausführung in einer neuen Umgebung mit eigener Kompilierung muss den Fehler ebenfalls aufzeigen. Nur dann erhält das Ergebnis einen nachvollziehbaren Fehler als Beleg. Ein Beweis, der den Fehler nicht nachvollzieht oder dessen zweite Ausführung die Bestätigung nicht liefert, ändert nichts.
Der Beweise Abschnitt des Ergebnisses zeigt an, was ausgeführt wurde: die Dateien und Befehle des Beweises, der Commit sowie das Ende der Ausgabe. Jeder, der das Ergebnis einsehen kann, kann diese Informationen lesen. Beweise werden so lange aufbewahrt, wie das Ergebnis offen ist, und 90 Tage nach dessen Schließung.
Ein Nachweis als Regressionstest aufbewahren
Inhaber und Administratoren können einen reproduzierten Nachweis dauerhaft speichern Jede Änderung kontinuierlich überprüfenAnschließend wird der Nachweis bei jedem Ausführungsvorgang von Quality Graph für das Projekt in einer neuen, isolierten Umgebung gegen den entsprechenden Commit geprüft: Der Test besteht, solange das Problem weiterhin behoben ist, und schlägt fehl, wenn das Problem erneut auftritt. Bei GitHub gibt der Test lediglich an, ob ein Sicherheits-Regressionstest erfolgreich oder fehlgeschlagen ist; der eigentliche Nachweis bleibt in Coroid gespeichert. Ein aufbewahrter Nachweis bleibt so lange vorhanden, wie der Test aktiv ist. Für diese Funktion benötigt das Projekt ein Quality Graph (das in der Qualitätskontrolle eingerichtet wird).
Für Nachweise ist der Proof-Runner erforderlich, den Coroid umgebungsabhängig aktiviert. Wo dieser noch nicht verfügbar ist, dient die oben beschriebene unabhängige Überprüfung als Nachweis für die Audit-Ergebnisse.
Der Sicherheits-Auditbericht
Unter „Neue Aufgaben“ ist kein schriftlicher Sicherheits-Auditbericht mehr verfügbar. Stattdessen führt ein Link zu den Audit-Ergebnissen in der Rubrik „Sicherheit“.