Pull-Requests zur Behebung von Fehlern korrigieren

Eine Schwachstelle zu finden ist der einfache Teil. Die Aufgabe der Sicherheit besteht darin, die Behebung zu mergen und bereitzustellen. Bei anfälligen Abhängigkeiten öffnet Coroid das Update pull request selbst, und Ihr Team überprüft es und merged es.

Wenn Coroid eines öffnet#

Mit Anfällige Abhängigkeiten beheben aktiviert, führt eine Abhängigkeitswarnung mit der festgelegten Behebungs-Schweregradstufe (standardmäßig hoch) zu einer Behebungsaufgabe im entsprechenden Projekt:

• Eine Aufgabe pro Paket und pull request, wobei alle betroffenen Warnhinweise berücksichtigt werden.
• Zuerst kritische Fehler, anschließend hohe.
• Maximal 5 offene Pull-Requests zur Behebung pro Projekt standardmäßig (bis zu 50). Die nächste Behebung wartet auf einen freien Slot.

Inhaber und Administratoren können außerdem auswählen Beheben bei jeder offenen Abhängigkeitswarnung mit einem öffentlichen Warnhinweis. Wenn keine korrigierte Version verfügbar ist, bietet „Beheben“ stattdessen eine Maßnahmenaufgabe: das Paket entfernen oder ersetzen, einen gepatchten Fork festlegen oder den anfälligen Aufruf absichern.

Automatische Updates funktionieren derzeit für npm-Projekte. Für andere Ökosysteme wird angezeigt: „Für dieses Ökosystem gibt es noch kein automatisches Update“. In diesem Fall bietet „Beheben“ die Maßnahmenaufgabe an.

Was die Kosten dafür ausmacht#

Behebungsaufgaben nutzen ein AI-Modell und verbrauchen dabei Agentenstunden wie andere Aufgaben. Sie laufen unter dem integrierten Sicherheitsbehebungen Mandat, das jede Organisation hat:

• Umfang: Abhängigkeitsupdates und Sicherheitsmaßnahmen – nichts weiter.
• Budget: Nur Agentenstunden; standardmäßig ein Viertel der monatlichen Agentenstunden Ihres Plans. Inhaber können die Stunden sowie ob sie wöchentlich oder monatlich gezählt werden, unter Sicherheit → Einstellungen → Anfällige Abhängigkeiten beheben ändern.
• Keine Ablauffrist für die Überprüfung. Es handelt sich um eine dauerhafte Standardeinstellung, die nicht erneuert werden muss.
• Priorität: Sicherheitsbehebungen haben Vorrang vor anderen selbstgestarteten Aufgaben.

Wenn „Anfällige Abhängigkeiten beheben“ in den Organisations-Einstellungen deaktiviert wird, wird das Mandat pausiert. Das Mandat wird zusammen mit den anderen in Qualitätskontrolle → Mandate.

Wenn eine Organisation mit bereits verbundenen Repositories Security nutzt, erhalten ihre Inhaber eine Benachrichtigung im Benachrichtigungsbereich: „Sicherheitsbehebungen beginnen in sieben Tagen“. Die Behebungsarbeit startet sieben Tage nach dieser Benachrichtigung, sodass ein Inhaber sie vor dem ersten pull request deaktivieren kann. Neue Organisationen starten sofort.

Warum eine Behebung eventuell wartet#

Im Abschnitt zur Behebung einer Warnung steht, worauf gewartet wird. Die üblichen Gründe:

• die Grenze für offene pull request-Aufträge des Projekts ist erreicht;
• das Budget des Mandats oder die Agentenstunden des Plans sind aufgebraucht (die Erkennung läuft jedoch weiter);
• die Agentenarbeit ist in Mission Control pausiert oder es ist kein freier Agenten-Slot verfügbar;
• die siebentägige Frist ist noch nicht abgelaufen;
• es wurde noch kein kompatibles Update veröffentlicht oder das Ökosystem unterstützt kein automatisches Update;
• „Anfällige Abhängigkeiten beheben“ ist deaktiviert.

Wie das Update ausgewählt wird#

Für jede Stelle, an der ein anfälliges Paket installiert ist, wählt Coroid die kleinste Version oberhalb der installierten Version aus, die alle betreffenden Warnhinweise behebt – innerhalb des deklarierten Bereichs und der möglichen Hauptversion. Ein Downgrade erfolgt nie. Ein Arbeitsbereich mit einer bestimmten Hauptversion und ein anderer mit einer anderen erhalten jeweils ihre eigene gepatchte Version im selben pull request. Ein transitives Paket wird durch das Update des übergeordneten Pakets oder die Überschreibung des Paket-Managers aktualisiert. Jede wesentliche Änderung oder Konsolidierung auf eine Version wird im pull request begründet angegeben. Wenn kein einziges Update alles behebt, korrigiert der Pull-Request das, was möglich ist, und listet die restlichen Fehler als nicht behoben auf.

Was das pull request enthält#

• Die damit behobenen Warnhinweise samt ihrer Schweregradstufe.
• Das Paket-Inventar vor und nach der Änderung, wobei die anfällige Version entfernt wird.
• Die Prüfungen Ihres Projekts: Wenn das Projekt ein Delivery-Diagramm mit ausführbaren Prüfungen hat, müssen diese bei der gepushten Änderung das Ergebnis „GO AHEAD“ liefern, bevor Coroid das pull request öffnet; andernfalls endet die Aufgabe mit dem entsprechenden Grund. Wenn das Projekt keine Prüfungen konfiguriert hat, wird das pull request dennoch geöffnet und es wird angezeigt, dass Coroid keine Projektprüfungen durchgeführt hat, dass Ihr Repository selbst die CI für das pull request nutzt und wo die Prüfungen in der Qualitätskontrolle konfiguriert werden können.
• Die Gründe für jede wesentliche oder bereichsbezogene Änderung.
• Alle Warnhinweise, die nicht behoben werden konnten, werden als nicht behoben aufgelistet.

Es endet mit dem Satz: „Menschen überprüfen und mergen die Änderungen. Der Bereitstellungsstatus wird erst durch das Scannen der bereitgestellten Revision festgelegt.“ Das Ergebnis wird ab dem nächsten vollständigen Inventar im Code sowie für jede Umgebung durch das Scannen der jeweils dort ausgeführten Revision korrigiert. Siehe Ergebnisse und ihr Lebenszyklus.

Code-Ergebnisse#

Bei einem Code-Ergebnis Beheben erstellt eine Aufgabe zur Behebung im entsprechenden Projekt. Inhaber und Administratoren können diese für jedes offene Code-Ergebnis nutzen. Die Aufgabe verlangt vom Entwickler, in den Commit-Nachrichten und im pull request die beschriebene Behebung – nicht den Angriff – anzugeben und einen Regressionstest hinzuzufügen. Sie unterliegt denselben Regeln wie andere Aufgaben und verbraucht Agenten-Stunden.

In einem öffentlichen Repository oder einem Repository, dessen Sichtbarkeit Coroid nicht bestätigen kann, wird eine noch nicht öffentliche Behebung eines Ergebnisses dort nicht committet. Coroid speichert die vorbereitete Änderung privat, bis ein Inhaber oder Administrator sie veröffentlicht. Siehe Offenlegung.

Geklaute Geheimnisse#

Ein geklautes Zugangsdatenpaar wird durch das Rotieren des Passworts behoben – was Coroid für Sie nicht übernehmen kann. Bei einem Geheimnis-Ergebnis erzeugt die Option „Beheben“ stattdessen eine Checklisten-Aufgabe. Siehe Geklaute Geheimnisse.