Die nativen Sicherheitswerkzeuge von Rust weisen Lücken auf, die Angreifern bereits bekannt sind

Wichtigste Erkenntnisse

• Cargo Audit kennt nur die Meldungen, die bereits von anderen eingereicht wurden.
• Build-Skripte und Proc-Makros führen zur Kompilierungszeit beliebigen Code aus, und in der stabilen Cargo-Version lässt sich dies nicht deaktivieren.
• Eine verlassene Kiste hat kein Ablaufdatum, daher läuft nichts ab, und du erhältst nur dann eine Warnung, wenn jemand sie meldet.
• Wenn ein Sicherheitshinweis ohne gepatchte Version veröffentlicht wird, liegt die Behebung des Problems in Ihrer Verantwortung.

Ein Rust-Team nimmt die Sicherheit von Abhängigkeiten ernst, und der erste Schritt ist fast immer derselbe: Man installiert „cargo audit“, bindet es in die CI ein, wartet, bis es erfolgreich durchläuft, und fühlt sich besser.

Das ist ein guter Schritt. Allerdings beantwortet die Frachtprüfung eine engere Frage, als die meisten Teams annehmen. Dort heißt es: Cargo.lock und zeigt Ihnen an, für welche Crates Sicherheitshinweise vorliegen. Das ist jedoch nicht dasselbe wie zu wissen, ob der Code, den Sie kompilieren wollen, sicher kompiliert werden kann.

Die Tooling-Umgebung von Rust legt großen Wert auf das, was die Sprach-Community als vorrangig erachtet hat: reproduzierbare Builds, unveränderliche Versionen, mit Prüfsummen versehene Lockfiles. Die Lücken sind kein Zeichen von Schlampigkeit. Sie entstehen, wenn eine Toolchain auf ehrliche statt auf feindliche Abhängigkeiten ausgelegt ist.

Was bei einer Frachtprüfung tatsächlich überprüft wird

Drei Dinge, auch wenn dem Tool mehr zugeschrieben wird.

Es gleicht die Einträge in Ihrer Lockfile-Datei mit der RustSec-Advisory-Datenbank ab. Es kennzeichnet entfernte Versionen. Und es zeigt informative Hinweise an – und genau hier tut Rust etwas, was die meisten Paketmanager komplett auslassen.

cargo install cargo-audit --locked
cargo audit

RustSec unterteilt seine Ergebnisse in Kategorien, wobei die drei Arten von Problemen, die keine Sicherheitslücken darstellen, eine größere praktische Bedeutung haben, als die meisten Teams erwarten.

Keine der Informationskategorien führt für sich genommen zu einem Fehlschlag, sodass ein CI-Job, der lediglich ein Cargo-Audit durchführt, den Status „grün“ erhält, obwohl sich direkt im Baum nicht gewartete Crates befinden. Genau das ist es in der Regel, was Teams zu erkennen glauben.

cargo audit --deny warnings

Das ändert die Sache. Sie können auch eine engere Kategorie wie „un gepflegt“, „mangelhaft“ oder „entfernt“ ausschließen, wenn Sie eine bestimmte Art von Befunden hervorheben möchten, ohne die übrigen zu berücksichtigen. Rechnen Sie damit, dass der erste Durchlauf bei einem ausgereiften Projekt laut werden wird.

Das Tag „unmaintained“ existiert nur, wenn es jemand setzt. Eine Crate, deren Betreuer im Jahr 2023 stillschweigend aufgehört hat, Commits zu veröffentlichen, und dies nie angekündigt hat, erzeugt keinerlei Hinweise. Ein reiner Cargo-Audit-Lauf gibt keinen Aufschluss darüber, ob Ihre Abhängigkeiten noch von jemandem gepflegt werden.

Was die einzelnen Rust-Sicherheitstools abdecken

Die Tools unterscheiden sich in zwei Punkten, die wichtiger sind als die Anzahl der Funktionen: ob der Code tatsächlich von einem Menschen überprüft werden muss und ob sie einen Build stoppen können.

„cargo deny“ wird im Vergleich zu dem, was es tatsächlich leistet, viel zu selten genutzt. Es deckt denselben Bereich der RustSec-Sicherheitshinweise ab wie „cargo audit“, fügt Lizenz- und Sperrrichtlinien hinzu und ermöglicht es Ihnen, Quellen auf eine Whitelist zu setzen, sodass sich kein Crate aus einem Repository, das Sie nie genehmigt haben, unbemerkt einschleichen kann. Aktuelle Versionen scheitern bei der Überprüfung auf Schwachstellen- und Hinweis-Advisories; standardmäßig wird bei nicht mehr gepflegten Advisories an beliebiger Stelle im Baum ein Fehler gemeldet, ebenso bei fehlerhaften Advisories in Ihren direkten Abhängigkeiten – was genau das Verhalten ist, das sich die meisten Teams von Anfang an gewünscht haben.

„cargo auditable“ löst ein anderes Problem. Sobald eine Rust-Binärdatei kompiliert ist, lässt sich ihre genaue Abhängigkeitsliste nicht mehr zuverlässig ermitteln. „cargo audit bin“ kann sie durch das Auswerten von Panikmeldungen teilweise rekonstruieren, und die Dokumentation des Tools spricht die Grenzen dieses Verfahrens erfrischend offen an. Eingebetteter C-Code ist für das Tool unsichtbar, und etwa die Hälfte der Rust-Abhängigkeiten geht verloren, da der Compiler sehr gut darin ist, Panic-Meldungen zu entfernen, die niemals ausgelöst werden können. Das Einbetten der tatsächlichen Liste zur Erstellungszeit behebt dieses Problem, und es kostet Sie lediglich ein Wort in Ihrem Build-Befehl.

ausführen. cargo tree --duplicates neben der jeweiligen Prüfung, die Sie gerade durchführen. Mehrere Versionen derselben Crate in einem Baum machen die Behebung des Problems komplizierter, als es auf den ersten Blick scheint, da bei der Aktualisierung eines Abhängigkeitspfads möglicherweise immer noch eine ältere Version in Ihrer Binärdatei enthalten ist.

Die erste Lücke betrifft das Timing

Jedes Tool in dieser Tabelle arbeitet mit einem Abhängigkeitsgraphen, den Cargo bereits aufgelöst hat. Sie können einen Build zum Scheitern bringen oder eine Veröffentlichung blockieren. Was keines von ihnen tut, ist, eine Crate von vornherein aus dem aufgelösten Graphen herauszuhalten.

Bei den meisten Abhängigkeitsproblemen ist das in Ordnung. Ein Crate, von dem bekannt ist, dass es eine Sicherheitslücke aufweist, ist auch zehn Minuten später noch anfällig, und wenn man das im CI entdeckt, ist das früh genug.

Bei bösartigem Code ist dies die falsche Seite der Zeitachse, da Rust nicht vertrauenswürdigen Code bereits während der Kompilierung ausführt. Build-Skripte werden als Teil von cargo build. Prozedurale Makros werden innerhalb des Compilers ausgeführt. Keines von beiden erhält von Cargo eine Sandbox, sodass beide mit den Berechtigungen desjenigen laufen, der den Build gestartet hat, und somit Zugriff auf das Dateisystem, das Netzwerk sowie alle Anmeldedaten haben, über die die Build-Umgebung gerade verfügt.

Bei „Stable Cargo“ gibt es kein Flag, mit dem man eine der beiden Optionen deaktivieren könnte.

cargo vendor vendored/
find vendored/ -name build.rs | wc -l

Probieren Sie das mal in einem echten Projekt aus. Bei einem mittelgroßen Service mit ein paar hundert Crates im Baum lassen sich leicht Dutzende von Build-Skripten finden, und jedes einzelne davon, das zu einem Crate gehört, das tatsächlich für Ihr Ziel kompiliert wird, läuft bei einem Clean-Build. Die Wahrscheinlichkeit ist groß, dass niemand im Team auch nur eines davon gelesen hat.

Das ist keine hypothetische Annahme. Im Mai 2026 dokumentierten Forscher die TrapDoor-Kampagne Kisten gefunden, wie zum Beispiel sui-framework-helpers und move-compiler-tools richtet sich an Sui- und Move-Entwickler. Ihre build.rs Die Skripte suchten nach lokalen Wallet-Keystores, sobald ein Projekt kompiliert und bereitgestellt wurde, und übermittelten die Ergebnisse an GitHub Gists. Kein Installations-Hook, kein Import, einfach nur cargo build genau das tut, wofür es entwickelt wurde.

In Rust gibt es nichts Vergleichbares npm install --ignore-scripts. Sie können den Quellcode einer Crate vor dem Kompilieren einsehen, und bei sensiblen Inhalten sollten Sie dies auch tun. Die stabile Version von Cargo führt jedoch keinen normalen Build durch, bei dem die Build-Skripte der Abhängigkeiten und die Proc-Makros übersprungen werden. Daher bleibt „Prüfen, dann kompilieren“ eher eine manuelle Aufgabe als eine Option, die über ein Flag gesteuert werden kann.

Die Überprüfung einer Crate, bevor sie einen Entwickler erreicht, und deren Kompilierung aus verifizierter Quelle in einer kontrollierten Umgebung gehören zu den wenigen Kontrollmaßnahmen, die bereits vor der Ausführung zur Kompilierungszeit stattfinden. Dieses zeitliche Problem steht im Mittelpunkt von SecureChain für Rust – und nicht das Hinzufügen eines weiteren Durchlaufs durch einen Baum, der bereits abgerufen wurde.

Die zweite Lücke besteht darin, dass niemand irgendetwas patcht

RustSec erfasst Sicherheitslücken. Es behebt sie jedoch nicht.

Diese Unterscheidung bleibt rein theoretisch – bis zu dem Zeitpunkt, an dem es für den vor Ihnen liegenden Sicherheitshinweis keine gepatchte Version gibt. Dann wird es zum eigentlichen Problem, und die Lösungsmöglichkeiten werden schnell immer weniger.

Auch das Volumen wächst weiter. RustSec verfügt über 170 Sicherheitshinweise mit Veröffentlichungsdaten aus dem Jahr 2025, und die Sicherheitshinweise aus dem Jahr 2026 haben diese Zahl bereits im Mai übertroffen und bis Mitte August 257 erreicht. Damit ist die Zahl bereits das vierte Jahr in Folge gestiegen, wobei etwa 160 der diesjährigen Einträge als Sicherheitslücken eingestuft wurden und sich der Rest auf nicht gepflegte und fehlerhafte Befunde verteilt. Diese Zahlen steigen zudem nachträglich weiter an, da Sicherheitshinweise zu älteren Offenlegungen noch Monate später eintreffen. Das ist gut für das Projekt. Es bedeutet aber auch eine wachsende operative Belastung für alle, die die Daten nutzen, denn mehr Befunde in einem Codezweig, den niemand stromaufwärts patcht, bedeuten einfach mehr Probleme, die man nicht durch eine Versionserhöhung beheben kann.

Rust sorgt auch bei seinen bestehenden Nutzern für Zufriedenheit. In der Stack-Overflow-Entwicklerumfrage 2025 wählten Entwickler die Sprache erneut mit 72 Prozent zur beliebtesten Sprache – wobei sich dieser Wert darauf bezieht, wie viele aktuelle Nutzer sie weiterhin verwenden möchten, und nicht darauf, wie schnell die Akzeptanz steigt. So oder so: Zahlreiche Unternehmen setzen Rust mittlerweile im Produktivbetrieb ein, ohne dass es eine festgelegte Vorgehensweise dafür gibt, wie mit einem Crate umgegangen werden soll, für den eine Sicherheitswarnung vorliegt, aber noch keine Lösung bereitgestellt wurde.

Wenn es keine gepatchte Version gibt, ist jede Option mit Nachteilen verbunden. Man kann das Crate forken, den Fix anwenden und es unter eigenem Namen weiterpflegen. Man kann die Abhängigkeit ersetzen, was in der Regel bedeutet, dass man alles neu schreiben muss, was darauf zugreift. Man kann es lokal patchen, indem man [patch.crates-io] und diesen Patch auf unbestimmte Zeit behalten. Sie können eine Ausgleichsmaßnahme dokumentieren und das Risiko in Kauf nehmen. Oder Sie können jemanden hinzuziehen, dessen eigentliche Aufgabe darin besteht, Korrekturen in den zurückgelassenen Upstream-Code zu integrieren.

Das Zurückportieren eines Sicherheitspatches auf eine Version, deren Betreuer das Projekt verlassen hat, ist eine ganz andere Disziplin als das Entwickeln neuer Funktionen. Es erfordert Regressionstests, Kompatibilitätsprüfungen und die bewusste Verpflichtung, das Verhalten nicht zu verändern – was in etwa das Gegenteil dessen ist, worauf die Upstream-Entwicklung ausgerichtet ist.

Die dritte Lücke sind Kisten, die nie offiziell ausgemustert werden

PHP veröffentlicht EOL-Termine. Das Gleiche gilt für Node, allerdings nach eigenem Zeitplan. Eine Crate, die 2019 von einer einzelnen Person veröffentlicht wurde, gibt keine EOL-Termine bekannt, da es von vornherein keine Zusage für eine Support-Laufzeit gab.

Das Register unter crates.io Das macht die Sache in einer bestimmten Hinsicht schwieriger. Veröffentlichte Versionen sind praktisch unveränderlich. Eine Löschung ist nur in einem engen Zeitfenster möglich – nämlich bei Crates, die fast keine Downloads verzeichnen und auf die sich nichts bezieht –, sodass das „Yanking“ der eigentliche Hebel ist. Diese Unveränderlichkeit ist ein echter Sicherheitsvorteil gegenüber Registern, die veränderbare Tags zulassen. Es bedeutet auch, dass ein aufgegebener Crate weiterhin installierbar bleibt, normal aufgelöst wird und keine Spuren hinterlässt in Cargo.lock was darauf hindeutet, dass der Betreuer das Projekt vor drei Jahren aufgegeben hat.

Es gibt kein Tool, das die entsprechenden Signale zusammenfasst, daher muss dieser Schritt manuell erfolgen. Vergleichen Sie das Datum der letzten Veröffentlichung mit der Anzahl der offenen Issues. Prüfen Sie, ob das GitHub-Repository archiviert ist – was Cargo niemals erwähnt. Zählen Sie die auf der crates.io-Seite aufgeführten Eigentümer, denn ein einziger Eigentümer entspricht einem „Bus-Faktor“ von eins. Achten Sie außerdem darauf, ob es sich bei der Crate um eine Build-Abhängigkeit oder ein Proc-Makro handelt, da diese unabhängig von ihrem Wartungszustand zur Kompilierungszeit ausgeführt werden.

ausführen. cargo owner --list <crate> in Bezug auf alles, was in Ihrem Projektbaum sicherheitsrelevant ist. Ein einziger Eigentümer einer Crate, die in Ihre Produktionsbinärdatei kompiliert wird, stellt ein Lieferkettenrisiko dar, das durch den Abgleich mit Sicherheitshinweisen allein nicht aufgedeckt wird.

Um zu wissen, welche Befunde tatsächlich von Bedeutung sind, braucht es eben diesen Kontext. Den Wartungsstatus, ob es eine Korrektur gibt, ob sich die Crate in Ihrem Build-Pfad befindet oder nur in den Entwicklungsabhängigkeiten. Die Abgleichfunktion für Sicherheitshinweise liefert Ihnen nichts davon, sodass Teams letztendlich anhand der RUSTSEC-ID statt anhand des tatsächlichen Risikos eine Priorisierung vornehmen.

Wo „Cargo Vet“ hilft und wo seine Grenzen liegen

cargo vet verfolgt einen anderen Ansatz und verdient es, häufiger eingesetzt zu werden, als dies bisher der Fall ist. Anstatt Warnmeldungen abzugleichen, wendet es Audit-Kriterien auf Ihren gesamten Abhängigkeitsgraphen an – dabei nutzt es sowohl Audits, die Ihr eigenes Team durchführt, als auch solche, die Sie von Organisationen importieren, die ihre eigenen veröffentlichen.

cargo vet init
cargo vet suggest

Was Sie vor dem Start wissen sollten: cargo vet init schließt bewusst alles aus, was sich bereits in Ihrem Baum befindet, damit die Übernahme nicht schon am ersten Tag zu einem CI-Fehler führt. Der Rückstand wird durch cargo vet suggest, und Sie tauschen Ausnahmeregelungen gegen echte Prüfungen ein – in dem Tempo, das Ihr Team bewältigen kann. Durch das Importieren von Prüfungen größerer Organisationen lässt sich ein beträchtlicher Teil des Rückstands abarbeiten, ohne dass jemand aus Ihrem Team diesen Code selbst überprüfen muss.

Die Einschränkungen sind struktureller Natur. Die Abdeckung hängt davon ab, dass jemand eine Version geprüft hat, auf die Sie tatsächlich angewiesen sind, und eine neue Version erfordert neue Nachweise, sofern sie nicht bereits durch eine importierte Prüfung oder eine Ausnahmegenehmigung abgedeckt ist. Delta-Prüfungen sorgen dafür, dass dies überschaubar bleibt, da Sie in der Regel den Unterschied zu einer bereits freigegebenen Version überprüfen, anstatt von vorne anzufangen. Eine manuelle Prüfung ist zudem eine Ermessensentscheidung hinsichtlich der Codequalität und der Absicht, keine Garantie. Prüfern entgehen Dinge, insbesondere in verschleierten Build-Skripten.

Delegiertes Vertrauen ist immer noch besser als gar kein Vertrauen. Es weist lediglich eine Abdeckungskurve auf, und diese Kurve ist genau dort am dünnsten, wo sich neue oder unbekannte Crates befinden – und genau dort tauchen feindliche Pakete nun einmal am liebsten auf.

Was sollte man in der CI eigentlich ausführen?

Entscheiden Sie sich je nach Stand Ihres Projekts, anstatt alles auf einmal zu installieren.

Da heute noch nichts eingerichtet ist, fangen Sie mit Folgendem an: cargo deny check advisories sources. Es deckt den Anwendungsbereich der RustSec-Hinweise ab, fügt in einem Schritt eine Whitelist für Quellcode hinzu und behandelt die zentralen Hinweis-Kategorien standardmäßig als Fehler, die den Build unterbrechen.

Falls die Frachtprüfung bereits läuft, fügen Sie Folgendes hinzu: --deny warnings Damit nicht gepflegte und fehlerhafte Befunde nicht mehr unbemerkt bleiben, sortiere die daraus resultierende Liste danach, ob sich die Crate in deinem Build-Pfad befindet.

Wenn Sie Binärdateien an Kunden oder in regulierte Umgebungen versenden, fügen Sie „cargo auditable“ hinzu, damit das von Ihnen versendete Artefakt seine eigene Abhängigkeitsliste enthält. Eine nachträgliche Rekonstruktion ist sowohl mühsam als auch unvollständig.

Falls Ihre Build-Agenten Cloud-Anmeldedaten oder Signaturschlüssel enthalten, sollten Sie die Ausführung zur Kompilierungszeit als das Hauptrisiko betrachten und die Gültigkeitsdauer dieser Anmeldedaten verkürzen, da nach dem Start eines Builds die Skripte zum Erstellen der Abhängigkeiten ausgeführt werden können, noch bevor Ihr eigener Code überhaupt ausgeführt wird.

Und wenn die Ausführung zur Kompilierungszeit in Ihrem Bedrohungsmodell nicht akzeptabel ist, kann Cargo allein diese Grenze nicht durchsetzen. Die Kontrolle muss vor die Auflösung verlagert werden – entweder in die Überprüfung und Neuerstellung von Crates, bevor diese in den Build gelangen, oder in eine isolierte Build-Umgebung, die davon ausgeht, dass der Code bösartig ist.

Die Ergebnisse variieren je nach Baumstruktur. Ein Projekt mit 40 direkten Abhängigkeiten und ohne Frameworks, die stark auf Proc-Makros setzen, lässt sich gut prüfen. Ein Dienst, der asynchrone Laufzeitumgebungen, Serialisierung und ein Web-Framework einbindet, kann leicht mehrere hundert transitive Crates mit zahlreichen Ausführungspunkten zur Kompilierungszeit erreichen – und ein Ratschlag, der diese beiden Fälle gleich behandelt, stammt von jemandem, der „cargo tree“ im zweiten Fall noch nicht ausgeführt hat.

Wo SecureChain für Rust zum Einsatz kommt

Bei all dem geht es darum, Lücken zu finden, nicht darum, sie zu schließen. „cargo audit“ zeigt Ihnen an, was bereits markiert wurde. „cargo vet“ zeigt Ihnen an, was bereits von jemandem überprüft wurde. Keines der beiden Tools befasst sich mit einer Crate, die bösartigen Code ausführt, bevor eines der beiden Tools sie überprüfen kann, und keines der beiden liefert eine Lösung für einen Sicherheitshinweis, für den es keinen Upstream-Patch gibt.

Genau dafür wurde SecureChain für Rust entwickelt. Es kompiliert Crates aus dem Quellcode in isolierten Umgebungen neu, überprüft sie bei der Installation auf Malware und verdächtige Muster und sorgt im Rahmen der SLA für Patches, sobald neue CVEs bekannt werden. Wenn die Wartung durch den Upstream-Entwickler endet, übernimmt „Endless Lifecycle Support“ diese Crate und liefert weiterhin Korrekturen, solange sie in Ihrem Stack verbleibt. So wird eine aufgegebene Abhängigkeit niemals unbemerkt zu einer ungepatchten Komponente in Ihrem Code-Baum.

Wenn Sie versuchen, den Überblick über die versteckten Risiken in Ihren transitiven Abhängigkeiten zu gewinnen, bietet das Webinar von TuxCare zum Thema „Dependency Iceberg“ einen tieferen Einblick darin, wie sich CVEs durch Abhängigkeitsketten ausbreiten, die selbst dann unsichtbar bleiben, wenn Ihr Dashboard auf den ersten Blick einwandfrei aussieht.

FAQ

Was bewirkt eine Frachtprüfung?

Es vergleicht die Kisten in Ihrem Cargo.lock gegen die RustSec-Advisory-Datenbank und meldet Sicherheitslücken, zurückgezogene Versionen sowie Informationshinweise zu nicht mehr gepflegten oder unsicheren Crates. Es liest weder den Quellcode der Crates noch fängt es Installationen ab, doch dank seines Exit-Status eignet es sich hervorragend als CI-Gate. Ein experimentelles cargo audit fix Der Unterbefehl kann einige anfällige Abhängigkeitsanforderungen aktualisieren, allerdings müssen Sie „cargo audit“ mit aktivierter „fix“-Funktion installieren, um diese Funktion nutzen zu können.

Schlägt die Frachtprüfung bei nicht gewarteten Transportkisten fehl?

Nicht standardmäßig. Informationshinweise, einschließlich solcher, die nicht mehr gepflegt werden, werden als Warnungen angezeigt, sofern Sie keine andere Konfiguration vornehmen. Führen Sie folgenden Befehl aus: cargo audit --deny warnings daran zu scheitern oder eine einzelne Kategorie wie „nicht gepflegt“ abzulehnen und dabei einen langen ersten Durchlauf bei einem etablierten Projekt zu erwarten.

Was ist der Unterschied zwischen „Cargo Audit“ und „Cargo Vet“?

„cargo audit“ prüft, ob für eine Kiste eine Warnmeldung vorliegt, was für Sie keinerlei Aufwand bedeutet. „cargo vet“ prüft, ob Ihr Abhängigkeitsgraph die von Ihnen konfigurierten Audit-Kriterien erfüllt, wobei Ihre eigenen Audits, importierte Audits, Delta-Audits und etwaige von Ihnen festgelegte Ausnahmen berücksichtigt werden. Für eine neue Version sind neue Nachweise erforderlich, sofern nicht bereits etwas Vorhandenes diese abdeckt, und ein Delta-Audit bedeutet in der Regel, dass nur die Unterschiede zu einer bereits geprüften Version überprüft werden.

Kann Cargo die Ausführung von Build-Skripten verhindern?

Nein. Stable Cargo verfügt über kein Flag, mit dem sich Build-Skripte oder prozedurale Makros deaktivieren lassen, da beide während der Kompilierung beliebigen Code ausführen und dabei Zugriff auf alle Elemente der Build-Umgebung haben.

Wie finde ich verlassene Kisten in meinem Abhängigkeitsbaum?

Dafür gibt es keinen einzelnen Befehl. Führen Sie Folgendes aus: cargo audit --deny warnings um nicht mehr gepflegte Sicherheitshinweise zu ermitteln, dann die Daten der letzten Veröffentlichung, den Status des Repositorys (ob es archiviert ist) und die Anzahl der Verantwortlichen zu überprüfen, und zwar über cargo owner --list für alles, was die Sicherheit betrifft.

Was passiert, wenn ein RustSec-Hinweis keine gepatchte Version enthält?

Das Problem wird nicht automatisch behoben. Man erstellt einen Fork, behebt den Fehler in der Crate, ersetzt die Abhängigkeit und wendet einen lokalen Patch über [patch.crates-io] und diese pflegen, eine Ausgleichskontrolle dokumentieren oder einen Anbieter hinzuziehen, der Korrekturen in Crates zurückportiert, deren Upstream-Betreuer die Pflege eingestellt haben.