Ein Frühwarnsystem für die Abhängigkeiten, die Sie nicht mehr im Blick haben.

Richte sie auf ein Verzeichnis, und sie findet jedes Projekt darunter – und hält an jeder Projektwurzel an, damit ein Monorepo einmal zählt statt fünfzigmal. .gitignore und .sentinelloignore werden beachtet.

Löst die exakt installierten Versionen aus der Lockfile auf und gleicht sie offline gegen einen lokalen Advisory-Cache ab. Kein Netzwerkaufruf pro Projekt, und nichts von deinem Code wird hochgeladen.

Eine datierte Markdown-Datei mit den Funden und einem angehängten Remediation-Prompt: erst triagieren, Parent-Upgrades gegenüber Overrides bevorzugen, Fixes in der Lockfile verifizieren.

• Die Spalte <strong>Status</strong> im Dashboard meldete eine einzige Quelle und verwarf den Rest. Jeder Scan schreibt eine Zeile pro Quelle, und sie enden im Abstand von Millisekunden — angezeigt wurde also die zuletzt fertige, in der Praxis immer OSV. Jedes Projekt las „OSV-Datenbank noch nicht heruntergeladen“, obwohl npm audit es einwandfrei gescannt und echte Schwachstellen gefunden hatte. Status trägt jetzt ein Abzeichen pro Quelle, die nicht antworten konnte, jeweils mit dem Namen der Quelle, und zeigt gar nichts, wenn alle aktivierten Quellen zufrieden sind. Der Scanverlauf hat aus demselben Grund eine Spalte <strong>Quelle</strong> bekommen: ein Durchlauf schrieb drei gleich aussehende Zeilen ohne jede Unterscheidungsmöglichkeit.
• Einstellungen → Quellen behauptete, ein Cache sei aktuell, während er neu aufgebaut wurde. Der vom Portal gelesene Status wurde erst nach Abschluss einer Synchronisierung geschrieben, also zeigte er während eines minutenlangen Neuaufbaus weiterhin den Zählerstand von davor — während jeder Scan den halb gelöschten Cache zu Recht verweigerte. Er trug außerdem nie die Normalisierer-Version, die der Scanner verlangt, sodass ein Versionssprung dieselbe falsche Aussage ganz ohne Neuaufbau erzeugte. Die Zeile liest sich jetzt <strong>Wird neu aufgebaut…</strong> mit abgeblendetem vorherigem Zählerstand, oder <strong>Neuaufbau ausstehend</strong>, wenn ein Cache unbrauchbar ist und sich gerade nichts darum kümmert.
• Ein fertig heruntergeladener Cache ließ jedes Projekt auf dem Urteil sitzen, das es während seines Fehlens bekommen hatte. Nichts scannte erneut, also blieb <code>osv_db_not_seeded</code> bis zum nächsten geplanten Durchlauf stehen — oder bis es jemandem auffiel und Scannen gedrückt wurde. Sentinello stellt jetzt einen vollständigen Neuscan in die Warteschlange, sobald ein Cache wieder brauchbar ist. Ein inkrementelles Update stellt nichts ein. Das Upgrade zählt mit: Landet diese Version auf einer Instanz, deren Projekte noch das Urteil von vor dem Abschluss des Caches tragen, bemerkt der Worker den Widerspruch beim ersten Start und räumt ihn für Sie auf — kein Scan, an den man denken müsste.

• gemnasium schreibt einige wenige Hinweise mit einem Leerzeichen zwischen dem Vergleichsoperator und seiner Version — <code>&lt; 0.5.2</code> statt <code>&lt;0.5.2</code> — und der Parser las dieses Paar als zwei getrennte Token. Das verwaiste <code>&lt;</code> erhielt eine leere Grenze, und die allein stehende Version wurde als exakte Version zwischengespeichert. Der <code>fresh</code>-Hinweis meldete deshalb Version 0.5.2 als verwundbar, obwohl 0.5.2 genau die Version ist, die ihn behoben hat — und meldete sie ohne verfügbare Lösung, denn eine festgepinnte Version trägt überhaupt kein Aktualisierungsziel. 19 Hinweise sind so geschrieben, und jeder einzelne wurde falsch gelesen: 15 verloren ihren Bereich vollständig, und 7 pinnten eine Version fest, die der Datensatz selbst als Behebung nennt — <code>pg</code> pinnte elf.
• Sentinello interpretiert die Bereichssyntax von npm nicht mehr selbst, sondern übergibt jeden Bereich zuerst an npms eigene Implementierung — was eine ganze Familie von Fehldeutungen auf einen Schlag erledigt. Für npm bedeutet <code>&lt;=3.3</code> „bis zum Ende der 3.3er-Reihe“ — wörtlich gelesen endete es bei 3.3.0 und verfehlte 3.3.1, was einem echten <code>converse.js</code>-Hinweis entspricht — und <code>=103</code> meint die gesamte 103er-Reihe statt eines einzelnen Punktes, was <code>binaryen</code> achtmal so angibt. Auch Bereiche mit Zirkumflex, Tilde, <code>1.x</code> und Bindestrich werden nun gelesen, während ein so geschriebener Datensatz zuvor kommentarlos verworfen wurde. Geprüft über alle 4.696 eigenständigen Versionsbereiche, die gemnasium für npm veröffentlicht: sie selbst zu deuten wich bei 9 von npm ab, die Delegation weicht bei keinem ab. Betroffen ist nur npm — in Python ist <code>==1.0</code> eine exakte Version und kein Platzhalter, npms Regel dort anzuwenden würde Befunde erfinden.
• Drei Dinge, die npms Lesart beim Installieren eines Pakets richtig und bei einem Hinweis falsch macht, werden zurückgehalten. Ein Bereich, der gar keine Version nennt — <code>*</code>, <code>x</code>, ein leeres Feld —, bedeutet beim Installieren „jede Version“ und in einem Hinweis „das hat niemand ausgefüllt“, wird also abgelehnt statt in einen Befund gegen jede je veröffentlichte Version verwandelt. Ein verirrtes abschließendes <code>||</code> kann den davorstehenden Bereich nicht mehr auf alles ausweiten. Und <code>&gt;0</code> bedeutet weiterhin jede Version, denn <code>pandora-doomsday</code> gibt sein bösartiges Paket so an, und npms Lesart würde ganz 0.x freisprechen. Davon getrennt: Ein Hinweis, dessen angegebene Behebung auf oder unter dem Anfang seines eigenen betroffenen Bereichs liegt, bekommt diese Grenze nicht mehr eingesetzt — das ergab ein Intervall, das nichts trifft, also einen Befund, der stillschweigend aufhört zu melden — und die Regel zum Verwerfen eines solchen Intervalls wird nun mit der OSV-Quelle geteilt, statt je Quelle einmal geschrieben zu werden, was überhaupt erst dazu führte, dass beide sich uneinig wurden.
• Die Tests, die das alles immer wieder übersahen, erzeugen ihre Eingaben jetzt, statt sie aufzuzählen. Jeder eigenständige Versionsbereich, den gemnasium für npm veröffentlicht, wird bei jedem Build gegen npms eigene Implementierung geprüft, zusammen mit dem vollständigen Kreuzprodukt der Bereichsgrammatik und jeder Reihenfolge der Bereichsereignisse von OSV. Gegen die vorige Version ausgeführt, scheitert dieser Durchlauf an 28 Bereichen, während die zehn handgeschriebenen Beispiele, die er ersetzt, sämtlich bestanden. Eine Schreibweise, die stromaufwärts von nun an erfunden wird, lässt den Build beim ersten Import scheitern statt erst dann, wenn jemand den daraus entstandenen Befund bemerkt.
• Jede Zeile des Codes hinter diesen Befunden wird jetzt von der Testsuite ausgeführt – Anweisungen, Verzweigungen, Funktionen und Zeilen zu 100 %, ohne jede Ausnahme im gesamten Repository. Das ist die unmittelbare Antwort darauf, wie die Fehler der letzten Versionen durchkamen: Jeder war ein Zweig, den nichts ausführte und der Erfolg meldete, ohne etwas zu tun. Beim Schließen der letzten 109 zeigte sich, dass mehrere davon als unerreichbare Schutzabfragen geführt wurden und schlicht ungetestet waren – dazu eine Coverage-Regel, die seit dem Verschieben der von ihr genannten Datei monatelang nichts mehr geprüft hatte. Sie und die 500 Zeilen Ausnahmen ringsherum weichen einer einzigen Regel, sodass ungetesteter Code den Build nun scheitern lässt, statt einen Durchschnitt zu senken.
• Auch die letzten defensiven Lücken sind geschlossen: Eine unlesbare OSV-Obergrenze lässt das gültige Intervall offen, Ersatzgrenzen werden nach dem Einsetzen geprüft und eine explizite npm-Prerelease-Grenze wie <code>&lt;1.2.3-0</code> behält ihre genaue Bedeutung.

• Ein Hinweis, dessen betroffener Bereich kein Ende hat, trifft auf jede Version zu — für immer: ein Befund, den kein Upgrade auflösen kann und der auf der Seite nicht von einer tatsächlich ungepatchten Schwachstelle zu unterscheiden ist. Zwei <code>xlsx</code>-Hinweise kamen so herein und meldeten ein vollständig gepatchtes 0.20.3 als hoch eingestuft und ohne verfügbare Behebung, auf 11 Projekten gleichzeitig, während <code>npm audit</code> dieselben beiden korrekt als behoben in 0.19.3 und 0.20.2 auswies. Die Ursache liegt vorgelagert und ist gewollt: GitHub nennt keine behobene Version, die die Registry unter diesem Paketnamen nicht ausliefert — SheetJS veröffentlicht 0.19.3 und neuer nur über das eigene CDN —, schreibt den Bereich deshalb als „alles ab 0“ und hinterlegt die echte Grenze in einem separaten Feld, das Sentinello nie gelesen hat. Jetzt liest es dieses Feld. Betroffen waren 15 npm-Hinweise, darunter <code>babel-traverse</code> und <code>sandbox</code>. Die 480, die wirklich ohne Behebung sind, sagen das weiterhin, und ein Datensatz, der seine eigene Grenze bereits angibt, wird nie überschrieben
• Ein gemnasium-Hinweis, der seinen Bereich offen ließ und zugleich die behebenden Versionen auflistete, wird nun durch die höchste davon begrenzt. Ein Bereich ohne Ende behauptet, auch jede künftige Version sei verwundbar — das kann kein Datensatz meinen, der eine Behebung nennt
• gemnasium schreibt Python-Versionsbereiche als PEP-440-Schnittmengen — <code>&gt;=5.0,&lt;5.8</code> — und der Parser trennte Token nur an Leerzeichen, sodass alles zu einem einzigen wurde: eine unlesbare untere Grenze und überhaupt keine obere. Solche Bereiche treffen auf nichts zu, und auf nichts zuzutreffen heißt, nichts zu melden. Betroffen waren 2.830 von 7.159 zwischengespeicherten PyPI-Datensätzen. Das war einer der drei Gründe, aus denen Python, Go und Rust in 3.3.0 zurückgezogen wurden; die beiden anderen bestehen fort, sie bleiben daher zurückgezogen

• 3.3.0 wurde auf npm und GitHub veröffentlicht, doch sein Container-Image ließ sich nicht bauen — zum Zeitpunkt der Veröffentlichung gab es auf GHCR und Docker Hub kein 3.3.0. Das Dockerfile listet jedes Workspace-Paket auf, das es installiert, und eines davon — das Paket für den Versionsvergleich — fehlte dort seit jeher. Bis zu dieser Version importierte es nichts im Image, deshalb fiel es nie auf. Inzwischen wurde ein korrigiertes 3.3.0-Image veröffentlicht, gebaut aus dem Anwendungscode von 3.3.0 selbst, sodass <code>docker pull sentinello:3.3.0</code> wieder funktioniert. 3.3.1 trägt dieselbe Korrektur im Quellbaum. Für die CLI war 3.3.0 bereits korrekt.

• Eine Benachrichtigung konnte leer ankommen. Ein Operator erhielt eine Telegram-Nachricht, die Schwachstellen in einem Projekt ankündigte und keine einzige auflistete. Der Versand ist auf das Projekt begrenzt, lief aber einmal pro Scanner: Der Durchlauf von npm audit bekam zwei offene OSV-Ereignisse, fand für keines eine Entsprechung und rendered die Überschrift trotzdem über einer leeren Liste. Danach markierte er beide Ereignisse als zugestellt — die zwei nie genannten Funde galten damit als benachrichtigt, und ein zugestelltes Ereignis wird nie erneut betrachtet. Ein Ereignis wird jetzt nur noch versendet, wenn es beschrieben werden kann; andernfalls bleibt es offen und wird beim nächsten Scan erneut geprüft
• Ein Fund wird mit der schlechtesten Bewertung gemeldet, die ihm irgendeine Quelle gegeben hat, und diese Eskalation erreichte das Dashboard, die Projektsummen und das <code>--fail-on</code>-Tor der CLI — nur nicht die Benachrichtigungsschwellen. Die Benachrichtigung lief vor der Bestätigung, sodass das Ereignis die Bewertung der überlebenden Quelle trug und nie überschrieben wurde. Auf einer echten Instanz trugen 135 offene Funde eine Ereignis-Schwere unterhalb der tatsächlichen, <strong>41 davon führten ein Kritisch als Niedrig, Hoch oder Mittel</strong>. Ein auf Kritisch und Hoch gefiltertes Ziel wäre für keinen von ihnen jemals alarmiert worden, dauerhaft
• Geplante Scans hörten um Mitternacht auf, statt weiterzulaufen. „Alle 3 Stunden ab 07:00“ lief um 07, 10, 13, 16, 19 und 22 und danach erst wieder um 07:00 — sechs Scans pro Tag statt acht, mit einem neunstündigen blinden Fenster jede Nacht — während die Einstellungen weiterhin das gewählte Intervall anzeigten. „Alle 6 Stunden ab 20:00“ schaffte einen Scan pro Tag. Die Zeitfenster laufen jetzt über den Tageswechsel hinweg
• <strong>Python, Go und Rust wurden zurückgezogen.</strong> Das ist keine Vorsicht wegen rauer Kanten: Ihre Fehler meldeten sich als sauber. Fix-Ableitung und Versionsordnung sind ausschließlich semver, weshalb ein OSV-Advisory zu Django gegen ein installiertes 4.2 „auf 3.2.23 aktualisieren“ empfahl; OSVs PyPI-Paketnamen sind nicht nach PEP 503 kanonisiert und trafen daher nie auf die des Resolvers; und gemnasiums Bereichsparser kann PEP-440-Komma-Schnittmengen nicht lesen. Eine Quelle, die aus den falschen Gründen „keine Schwachstellen“ antwortet, ist schlechter als eine, die gar nicht angeboten wird — sie sind daher vollständig aus der Produktoberfläche verschwunden: kein Schalter, keine Erkennung, kein Download. <strong>Bereits gesammelte Funde bleiben sichtbar und stummschaltbar; nichts wird gelöscht.</strong> Das npm-Ökosystem heißt jetzt <strong>Node.js</strong> und benennt damit das tatsächlich gescannte Paket-Ökosystem statt einer Sprache
• <strong>Einstellungen → Quellen</strong> wurde darum herum neu gebaut. Jede Quelle wiederholte ihre eigene Erklärung neben ihrem eigenen Schalter, und jede cache-gestützte trug ein fünfzeiliges Statuspanel mit eigenem „Jetzt aktualisieren“-Button in voller Größe — obwohl dieser Button pro Quelle genau ein gemeinsames Signal einreiht, egal wie oft er erscheint. Die Schalter sagen jetzt nur noch, ob eine Quelle aktiv ist; was jede beiträgt, was sie woher herunterlädt und wann sie läuft, ist in eine einzige Referenztabelle darunter gewandert, und der Sync-Status passt in eine Zeile
• Pakete, die npms eigenes Lockfile als aus der Produktion erreichbar ausweist, wurden auf reines Dev herabgestuft. Ein Lockfile ohne <code>dev: true</code> ist npms Aussage, dass das Paket aus der Produktion erreichbar IST — eine stärkere Aussage, als das Wurzelmanifest treffen kann — doch der Resolver überschrieb sie, sobald der Name auch unter <code>devDependencies</code> auftauchte, also genau dann, wenn npm recht hatte. Gemessen über 130 echte Projekte: 142 Pakete in 97 davon herabgestuft — lodash, semver, postcss, tailwindcss, @babel/runtime — wodurch auf einer Instanz sieben offene Funde aus dem Nur-Produktion-Filter verschwanden
• Jedes Paket, das auf eine Version wie <code>0.0.0-20180523222229-09b5706aa936</code> festgelegt ist, traf auf <strong>gar kein Advisory</strong>, nicht einmal auf ein offenes, und der Scan meldete ok mit null Funden. Eine Advisory-Grenze <code>introduced: 0</code> wurde als Release 0.0.0 verglichen, und unter semver sortiert eine Vorabversion unter ihrem Release. 330 der 19.085 vergleichbaren Bereiche eines echten Caches waren als Intervalle gespeichert, die nichts erfüllen konnte
• Ein unterbrochener OSV-Sync konnte ein Advisory dauerhaft löschen. Der inkrementelle Pfad entfernte die Zeilen eines Advisories und holte den Ersatz erst danach innerhalb eines try/catch — jeder Timeout, 5xx oder Shutdown löschte es damit ganz — und schob den Cursor trotzdem weiter, sodass die ID dauerhaft dahinter lag. Der Verlust war stumm, überlebte bis zum nächsten vollständigen Neuaufbau und geschah bei einem Sync, der Erfolg meldete. Der Cache von <code>npx sentinello</code> erodierte bei jedem instabilen Lauf auf dieselbe Weise. Beide holen jetzt zuerst und ersetzen danach
• Das <code>--dep-type dev</code> der CLI bedeutete „überhaupt aus dev erreichbar“, während das Portal „<em>nur</em> aus dev erreichbar“ meint — ein aus beidem erreichbares Paket erschien in der einen Ansicht und in der anderen nicht: 177 offene Funde unterscheiden sich auf einer Instanz zwischen beiden Lesarten. Die CLI verwendet jetzt die Regel des Portals und beachtet OSVs <code>withdrawn</code>-Feld, das sie zuvor strukturell nicht lesen konnte: 585 Zeilen eines echten npm-Caches tragen eines, und alle wurden als aktive Funde gemeldet
• Ein gemnasium-Advisory, das besagt, eine Schwachstelle beginne <em>nach</em> einer Version — <code>&gt;1.2.8</code> statt <code>&gt;=1.2.8</code> —, wurde gelesen, als sei die Grenzversion selbst betroffen. Die Übernahme des Pakets <code>rc</code> im Jahr 2021 ist genau so formuliert, und 1.2.8 ist dessen letzte saubere Version: genau jene, die der Behebungshinweis des Advisories selbst empfiehlt. Jedes Projekt mit installiertem <code>rc</code> bekam einen kritischen Malware-Befund ohne verfügbare Korrektur — gegen eine Version, die nie kompromittiert war. Grenzen werden jetzt exakt so übernommen, wie das Advisory sie angibt, und falsche Kritische dieser Form verschwinden
• Dieselbe Rundung wirkte auch in die andere Richtung und verbarg echte Befunde. Ein durch <code>&lt;=2.0.0</code> begrenztes Advisory wurde als „unterhalb von 2.0.0“ gespeichert, sodass 2.0.0 — die Version, zu der es sich am deutlichsten äußert — nicht gemeldet wurde; ein Advisory, das genau eine betroffene Version nennt, wurde zu einem leeren Intervall und ganz verworfen. Rechnen Sie mit einigen neuen Befunden, die immer schon vorhanden, aber unsichtbar waren
• Bereiche mit Syntax, die Sentinello nicht implementiert — <code>^1.0.0</code>, <code>~1.0.0</code> —, wurden als exakte Version auf den wörtlichen Text festgelegt und konnten daher nie etwas treffen, solange sie im Cache lagen: ein aktiv wirkendes Advisory, das gar nicht auslösen konnte. Solche Datensätze werden nun abgelehnt statt in einer nicht funktionsfähigen Form gespeichert, und Advisories, deren Obergrenze keine saubere Fix-Version trägt, erhalten endlich einen Upgrade-Vorschlag
• Die Hilfsfunktion, die eine Webhook-URL oder ein Bot-Token maskiert, bevor es in eine Logzeile gelangt, gab kurze vollständig aus. Sie wies Werte mit sechs Zeichen oder weniger ab, behielt dann aber einen achtstelligen Kopf und einen vierstelligen Schwanz, und nichts prüfte, ob sich diese beiden Hälften berühren — jedes Geheimnis zwischen 7 und 12 Zeichen kam damit vollständig zurück. Sie verbirgt jetzt mindestens acht Zeichen oder schwärzt den Wert ganz

• Wenn mehrere Advisory-Datenbanken dieselbe Schwachstelle melden, hat Sentinello immer nur EINEN Befund behalten — dieselbe Lücke dreimal zu melden, weil drei Datenbanken sie kennen, ist Rauschen. Verworfen wurde bislang aber auch alles über die zusammengeführten Quellen, sodass eine von npm audit, OSV und GitLab gemnasium unabhängig bestätigte Schwachstelle genauso aussah wie eine, die nur eine einzige Datenbank je gemeldet hat. Auf einer realen Instanz sind das zwei Drittel aller Befunde. Jeder Befund führt nun die weiteren Quellen mit, die ihn gemeldet haben, und ihre Badges erscheinen neben der verbliebenen
• Ein Befund wird mit der HÖCHSTEN Schwere gemeldet, die ihm irgendeine Quelle gegeben hat. Die Datenbanken widersprechen sich tatsächlich — gemnasium berechnet die Schwere aus dem CVSS-Vektor, npm audit übernimmt GitHubs Einstufung — und für einen Scanner ist die vorsichtige Lesart die maßgebliche. Das ist nicht kosmetisch: Ein hochgestufter Befund wechselt die Kategorie im Dashboard, in den Projektsummen, im <code>--fail-on</code>-Gate der CLI und in den Benachrichtigungsschwellen. Beim ersten Scan nach dem Update werden sich einige Zahlen verschieben; es wurde nichts Neues gefunden, dieselben Befunde werden nur vorsichtiger bewertet
• Wo die Quellen sich widersprechen, zeigt der Befund neben seiner Schwere ein Bedienelement, das öffnet, was jede Quelle tatsächlich gesagt hat — ihre eigene Advisory-Kennung und ihre eigene Einstufung. Es erscheint nur, wenn es einen Widerspruch zu erklären gibt, sodass ein einhellig bewerteter Befund unaufgeräumt bleibt
• OSV vermerkt einen Rückzug in einem eigenen Feld, und GitHub entfernt zurückgezogene Advisories, bevor <code>npm audit</code> sie überhaupt sieht — GitLab gemnasium hat ein solches Feld in seinem Schema jedoch nicht. Es zieht ein Advisory zurück, indem es den Eintrag umschreibt: Der Titel wird zu „False Positive“, „Withdrawn Advisory: …“ oder „Duplicate Advisory: …“, während die zuvor genannten Versionen unverändert stehen bleiben. Sentinello las diese Versionen und meldete Befunde, die GitLab ausdrücklich zurückgenommen hatte: 383 Einträge über JavaScript, Python, Go und Rust hinweg, darunter einer, der <code>express</code> unter dem Titel „False Positive“ meldete. Alle werden nun verworfen, was zugleich eine ganze Klasse doppelter Befunde beseitigt — 278 der 383 sind Advisories, die als Duplikat eines anderen zurückgezogen wurden
• Die Prüfung vergleicht die Rückzugsmarker exakt, statt die Wörter irgendwo im Text zu suchen. Ein echtes Advisory, das *von* einem False Positive handelt, wird daher weiterhin gemeldet: Cosigns CVE-2026-39395 mit dem Titel „Cosign’s verify-blob-attestation reports false positive when payload parsing fails“ bleibt unberührt
• Der gemnasium-Cache baut sich bei der ersten Synchronisierung nach diesem Update selbst neu auf; dann verschwinden die zurückgezogenen Advisories. Es ist nichts zu tun: Es geschieht im täglichen Lauf oder sofort über Einstellungen → Quellen → Aktualisieren

• Manche GitLab-gemnasium-Advisories enthalten überhaupt keinen maschinenlesbaren Versionsbereich — 698 der 10.777 JavaScript-Einträge. Sentinello füllte diese Lücke mit der Annahme, alle Versionen unterhalb der ersten aufgeführten Korrektur seien betroffen. Diese Liste ist jedoch unsortiert und enthält eine Korrektur pro Release-Zweig, sodass die Annahme regelmäßig den falschen Zweig traf. protobufjs 7.6.5 wurde als kritische Remote-Code-Ausführung gemeldet, obwohl dieser Zweig in 7.5.5 behoben wurde, und drei verschiedene Advisories behaupteten jeweils, jede vite-Version unterhalb von 8.0.5 sei verwundbar. Sentinello erfindet keine Bereiche mehr: Es rekonstruiert den echten aus demselben Advisory unter seiner anderen Kennung, aus der Beschreibung des Advisories oder — nur wenn OSV aktiviert ist — aus der bereits lokal vorhandenen OSV-Kopie, und verwirft den Eintrag, statt zu raten, wenn nichts davon greift. Einige kritische Befunde werden verschwinden
• OSV beschreibt ein über mehrere Release-Zweige behobenes Advisory als je einen Eintrag pro Zweig, und Sentinello behielt den ersten und verwarf den Rest — allein für JavaScript 1.927 verwundbare Versionsbereiche, jeder davon eine echte Schwachstelle, die dadurch unsichtbar wurde. Das minimatch-Advisory umfasst acht Zweige, von denen nur einer überlebte: ein installiertes minimatch 3.0.4 oder 9.0.0 wurde nicht gemeldet; next und ua-parser-js verloren Zweige auf dieselbe Weise. Jetzt bleiben alle Zweige erhalten. Es werden neue Befunde auftauchen — diese Schwachstellen waren immer da, nur unsichtbar
• Beide Advisory-Caches bauen sich bei der ersten Synchronisierung nach diesem Update selbst neu auf, weil ihre gespeicherten Bereiche vom alten Code stammen. Es ist nichts zu tun: Es geschieht im täglichen Lauf oder sofort über Einstellungen → Quellen → Aktualisieren, wenn Sie nicht warten möchten

• Ein stummgeschalteter Fund ist eine Entscheidung, die Sie bereits getroffen haben. Deshalb verschwindet er nun vollständig von der Projektseite, statt dort ausgegraut stehen zu bleiben. Das ist nicht nur aufgeräumter: Jede Zahl auf der Seite — die Überschrift, beide Tab-Badges, die Seitennummerierung, die Summen je Bibliothek, der Export-Button — wird aus denselben Zeilen berechnet. Damit stimmt die Seite endlich mit dem Dashboard, den MCP-Tools und dem Advisory-Export überein, die stummgeschaltete Funde ohnehin schon ausließen. Ein Schalter „Stummgeschaltete anzeigen“ holt sie jederzeit zurück, auch bei einem Projekt, dessen Funde *alle* stummgeschaltet sind
• Beim Tippen in einem Dialog geht der Fokus nicht mehr nach einem einzigen Zeichen verloren. Dieser Fehler machte das Feld „Begründung“ im Stummschalt-Dialog praktisch unausfüllbar — obwohl es Pflicht ist und als Einziges eine Stummschaltung Monate später nachvollziehbar macht. Derselbe Dialog übernimmt außerdem nicht mehr die Ausrichtung der Tabellenzeile, aus der er geöffnet wurde: Deshalb war der Dialog beim Stummschalten eines Fundes rechtsbündig, beim Stummschalten eines Projekts dagegen nicht
• Der Scan-Verlauf wächst nicht mehr unbegrenzt. Bislang hat nichts jemals eine Scan-Zeile nach Alter gelöscht, sodass ein Projekt, das auf der Platte blieb, unbegrenzt eine Zeile pro Quelle und Durchlauf ansammelte — eine reale Instanz erreichte in weniger als drei Monaten 2,2 GB. Einstellungen → Erweitert bietet nun einen Aufbewahrungszeitraum, standardmäßig 90 Tage; der Worker räumt stündlich alles Ältere ab und behält dabei immer die 100 neuesten Scans jedes Projekts. Funde, Stummschaltungen und der Benachrichtigungsverlauf bleiben unangetastet — nur das Scan-Protokoll nicht. Bei 90 Tagen löscht eine Instanz beim Update im ersten Durchlauf nichts: Bereinigt wird erst, wenn der Verlauf tatsächlich älter ist als der Zeitraum, oder wenn Sie ihn selbst verkürzen
• Der Großteil dieses Wachstums war die Rohausgabe von `npm audit`, bei jedem erfolgreichen Scan vollständig gespeichert und von nichts gelesen — 98,7 % der Datenbank jener Instanz. Scans speichern nun stattdessen eine kurze Zusammenfassung, was eine Zeile von rund 79 KB auf etwa 100 Byte bringt, mit einer harten Obergrenze, damit kein Scanner das wiederholen kann
• Über MCP sagt `get_dashboard_summary` jetzt, dass ein von Ihnen stummgeschaltetes Projekt aus seinen Summen herausfällt, während `list_projects` es weiterhin zurückgibt. Beide zählen absichtlich unterschiedliche Grundgesamtheiten, und ein Agent, der sie verglich, hielt das für einen Fehler. `list_scans` gibt zudem nicht mehr die Rohausgabe des Scanners je Scan zurück, die in einer einzigen Antwort rund 16 MB erreichen konnte

• Der Download von GitLab gemnasium schlug in 3.0.0 bei allen mit `HTTP 406` fehl. Das eingebaute fetch von Node setzt einen Header `Sec-Fetch-Mode: cors`, den ein Programm nicht entfernen darf, und GitLab weist jede Repository-Archivanfrage damit ab — es lag also nie an Ihrem Netzwerk, Ihrer IP oder der Zahl der Wiederholungen. Der Download nutzt jetzt eine einfache HTTPS-Anfrage und gelingt
• Das Archiv wird über die Commit-ID statt über den Branch-Namen geholt. Alle, die vom selben Upstream-Commit aktualisieren, teilen sich damit eine zwischengespeicherte Kopie, statt dass jeder GitLab ein frisches 60-MB-Archiv bauen lässt. Ein erster Download, der fast sieben Minuten dauerte, ist jetzt in Sekunden fertig
• Die CLI beendete ihren gesamten Lauf — Bericht geschrieben, Zusammenfassung ausgegeben — und gab das Terminal danach nie zurück. Die Verbindung des Downloads blieb dahinter offen und hielt den Prozess am Leben; sie wird jetzt geschlossen, sobald das Archiv gelesen ist
• Eine Quelle, die einen Download verweigert, blockiert nicht mehr drei Minuten, bevor sie es meldet. Sie meldet es in Sekunden und bietet im Terminal einen erneuten Versuch an — und wiederholt nur die Quelle, die tatsächlich fehlgeschlagen ist
• `--fail-on` ist in beide Richtungen ehrlich. Es verweigert einen Lauf, dessen Advisory-Quelle nicht abgefragt werden konnte, statt einen sauberen Scan zu melden, den es nie durchgeführt hat; und es lässt einen Lauf nicht mehr an einer Quelle scheitern, die Sie selbst mit `SENTINELLO_OSV_FEED_URL=off` oder `SENTINELLO_GEMNASIUM_FEED_URL=off` abgeschaltet und nie heruntergeladen haben

• Die Scanner erscheinen als CLI auf npm. `npx sentinello` durchläuft einen Ordner, findet jedes Projekt darunter, prüft sie gegen npm audit, OSV und GitLab gemnasium und schreibt ein Markdown-Advisory mit angehängtem Remediation-Prompt — ohne Installation, ohne Konto, ohne Datenbank, und nichts von deinem Code verlässt die Maschine
• In einer Pipe ist das Advisory das Einzige auf stdout, sodass `npx sentinello | claude -p "$(cat -)"` einem Agenten eine vollständige Arbeitsliste übergibt, ohne dass irgendetwas das Dokument beschädigt
• Ein erster Lauf verliert die Quelle gemnasium nicht mehr an einen abgelehnten Download. GitLab verweigert sein Archiv ein bis zwei Minuten am Stück, und der alte Retry gab nach dreizehn Sekunden auf; die CLI wartet es nun aus, sagt warum sie wartet, und nimmt `--feed-wait`, falls die drei Minuten Standard für dich falsch sind
• Beide Download-Schätzungen wurden gemessen statt geraten: der npm-Export von OSV wird mit 204 MB statt 196 angegeben, das gemnasium-Archiv mit 52 MB statt 80. Die Zustimmungsabfrage kennzeichnet eine Schätzung mit einer Tilde, damit sie nie mit einer vom Server gemeldeten Größe verwechselt wird
• Ein Wert, der wie eine Option aussieht, wird jetzt abgelehnt statt wörtlich genommen — `--out --` schrieb ein Advisory in eine Datei namens `--` in deinem Projekt und meldete Erfolg
• Das Neuigkeiten-Panel läuft nicht mehr unten aus dem Fenster, wenn ein Release viel zu erzählen hat

• get_project_advisory liefert jetzt das Dokument selbst. Verbundene Clients erhielten bisher nur dessen Metadaten — einen Dateinamen und eine Anzahl — und nie das Dokument, obwohl das Werkzeug es als vollständige Arbeitsliste beschrieb
• Der Advisory-Export enthält jetzt einen Eintrag je eindeutigem Advisory mit zusammengeführten Quellen statt einen je Scanner-Zeile: Eine Schwachstelle, die npm audit und OSV beide melden, ist ein einziger Arbeitspunkt mit beiden Advisory-IDs statt zwei fast identischen. Das gilt auch für „.md herunterladen“ im Portal, und die Anzahl stimmt nun mit dem Dashboard überein
• Ein Projekt, das nicht in eine einzelne MCP-Antwort passt, wird jetzt paginiert: Das Dokument weist darauf hin, dass es unvollständig ist, und nennt den genauen Folgeaufruf für den Rest — statt still abgeschnitten zu werden, wo ein Agent den Rest für sauber hielte
• Jeder Parameter jedes MCP-Werkzeugs ist jetzt beschrieben, und das neue Werkzeug list_mutes liefert die Stummschaltungs-IDs, die unmute benötigt — bisher nur erhältlich, wenn man die Stummschaltung in derselben Sitzung angelegt hatte
• Eine Lücke in den Schweregrad-Zählungen behoben: Ein Fund, dessen Schweregrad keiner der fünf bekannten Werte war, wurde als Fund gezählt, aber keiner Kategorie zugeordnet — ein Projekt mit genau diesem einen Fund wirkte dadurch völlig sauber

• Verbundene MCP-Clients können das vollständige Markdown-Advisory eines Projekts über das neue Tool get_project_advisory abrufen — dasselbe Dokument wie der Portal-Button „.md herunterladen“, ohne es aus dem Browser zu kopieren
• Stummgeschaltete Funde werden nicht mehr in den Advisory-Export des Projekts aufgenommen, sodass ein Agent nie Arbeit erhält, deren Risiko Sie bereits akzeptiert haben
• Hinweis: Da das Advisory Ihren Export-Prompt enthält, kann ein MCP-Client jetzt lesen, was Sie unter Einstellungen → Export hinterlegt haben

• Dropdowns, das Abhängigkeitspfad-Popover und das Advisory-Export-Menü werden nicht mehr von der Tabelle oder dem Dialog abgeschnitten, in dem sie sitzen — sie werden über der Seite gerendert und klappen nach oben, wenn darunter kein Platz ist
• Der Standard-Prompt für den Advisory-Export verlangt jetzt, dass der Agent plant, bevor er etwas ändert, Funde mit gemeinsamem Fix gruppiert und die Code-Auswirkung jedes Versionssprungs benennt; er zielt auf null Funde und schließt dabei die Abkürzungen zu einer geschönten Null aus — Stummschalten, Ranges aufweiten oder den Scan-Umfang verkleinern —, während wirklich Offenes in einer datierten Restposten-Tabelle landet

• Der git-Branch, auf dem ein Projekt gescannt wurde, hat jetzt eine eigene Spalte in der Projektliste — reiner Text, kein Icon — statt unter dem Projektnamen zu stehen

• Ein Neustart des Containers bricht keinen Scan mehr mitten im Schreibvorgang ab, und der Worker startet sofort, statt es zuerst ~30 Sekunden lang erneut zu versuchen
• Setze stop_grace_period: 60s (oder --stop-timeout 60) in deiner Compose-Datei, damit er den nötigen Spielraum hat — README und Docker-Doku beschreiben das jetzt

• Sentinello analysiert jetzt neben npm auch Python-, Go- und Rust-Projekte — Lockfiles werden vollständig offline aufgelöst, und jedes Projekt meldet seine Analyseabdeckung (vollständig, teilweise oder nicht prüfbar), sodass Lücken sichtbar statt stillschweigend sind
• GitLabs gemnasium-Datenbank ergänzt npm audit und OSV als Offline-Advisory-Quelle, dedupliziert über CVE-/GHSA-Aliase; Einstellungen → Quellen ist jetzt eine Sprachen-×-Quellen-Matrix mit Benachrichtigungsbereich pro Zelle, und npm audit selbst lässt sich abschalten, solange eine Quelle aktiv bleibt
• Funde halten jetzt den git-Branch fest, aus dem sie stammen — sichtbar in der Projektliste, im Projektkopf und in jeder Benachrichtigung
• Projektzeilen haben eigene Aktionen — jetzt scannen, Advisory kopieren oder herunterladen, stummschalten oder reaktivieren und Tags bearbeiten — ein Triage-Durchgang erfordert also keinen Abstecher in jedes Projekt mehr
• Das Projekt-Dashboard ging von ~3,3 s auf ~0,03 s zurück, und die Navigation zeigt jetzt Ladezustände, statt eingefroren zu wirken
• Sicherheit: 25 Abhängigkeits-Advisories behoben, darunter libvips-CVEs, die im Bildoptimierer des Portals aktiv waren, und neun Next.js-Advisories, die das ausgelieferte Portal betrafen
• Der Standard-Prompt für den Advisory-Export deckt jetzt Mindestveröffentlichungsalter, Lockfile-Prüfung und veraltete Overrides ab

• MCP wird jetzt vollständig unter Einstellungen → MCP eingerichtet: Token generieren, um den Endpunkt /api/mcp einzuschalten, löschen, um ihn auszuschalten — die Umgebungsvariablen SENTINELLO_MCP_ENABLED und SENTINELLO_MCP_API_TOKEN entfallen (ein vorhandenes Umgebungs-Token wird beim Upgrade einmalig importiert)
• Fertige Verbindungs-Snippets zum Einfügen für Claude Code, Codex, Cursor und Claude Desktop, bereits mit deinem Token ausgefüllt
• Wenn SENTINELLO_PORTAL_BASE_URL in der Umgebung gesetzt ist, wird sie unter Einstellungen → Erweitert schreibgeschützt angezeigt, da sie maßgeblich bleibt und bei jedem Start erneut angewendet wird

• Malware-Hinweise stimmen jetzt mit der genau betroffenen Version überein — eine saubere oder bereits behobene Version eines einst kompromittierten Pakets wird nicht mehr markiert
• Doppelte Funde lösen sich jetzt beim nächsten Scan von selbst auf, sodass alte oder verwaiste Einträge automatisch verschwinden
• Produktions- und Entwicklungs-Kennzeichnungen werden jetzt über alle Quellen (npm und OSV) auf eine einheitliche Weise berechnet

• Verschlankter Projekt-Header — Umbenennen direkt neben dem Titel, Stummschalten und Tags als Icon-Buttons
• Funde nach Quelle filtern (npm / OSV) über ein neues Dropdown neben dem Abhängigkeitstyp-Filter
• Einheitliche Dropdowns in der gesamten App, mit Tippsuche für lange Listen wie Zeitzonen

• Erweiterte Upgrade-Schritte für die Breaking Changes von 2.0
• Die README weist auf die nur-localhost-Portbindung hin

• OSV als optionale zweite Quelle (Einstellungen → Quellen, standardmäßig aus) mit Erkennung schädlicher Pakete, abgeglichen mit der öffentlichen OSV-Datenbank in einem lokalen Cache
• Funde werden jetzt quellenübergreifend zusammengeführt — eine Zeile pro Schwachstelle, jede Quelle markiert, der beste verfügbare Fix und die Vereinigung der Abhängigkeitspfade, mit Quellenfilter und einem Abhängigkeitspfad-Popover
• Sicherheitshärtung: der MCP-Endpunkt ist standardmäßig aus und erfordert ein Token, die Webhook-Zustellung ist gegen SSRF abgesichert, ein optionales Portal-Login, und der Container läuft als unprivilegierter Benutzer
• Einstellungen sind jetzt ein Bereich der obersten Ebene mit Seitenleiste und einer Profilseite

• MCP-Server unter /api/mcp für Claude Desktop, Cursor und andere Clients
• Neuer Bereich Einstellungen → MCP mit Server-URL und Token-Verwaltung
• Neuigkeiten-Symbol und ein Verlauf der Versionshinweise

• Die laufende Version wird in der Fußzeile sauber dargestellt

• Benachrichtigungen nach Umgebung filtern
• Einfacheres Formular zum Bearbeiten von Zielen
• Ein vorhandenes Benachrichtigungsziel duplizieren

• Die Startansicht ist in eigene Seiten für Projekte und Bibliotheken aufgeteilt

• Der Worker lädt den Scan-Zeitplan neu, sobald du Änderungen im Portal speicherst

• Bestätigung vor dem Löschen von Roots und Benachrichtigungszielen
• Update-Hinweis als schließbares Banner oben
• Der Worker entfernt veraltete Roots, wenn ihr Host-Mount verschwindet

• Verwirft Funde, deren installierte Version nicht wirklich im verwundbaren Bereich liegt
• Ermöglicht das Löschen eines Benachrichtigungsziels mit Versandverlauf

• Die erste öffentliche Veröffentlichung von Sentinello

Funde nach Ausnutzbarkeit ordnen und danach, ob der verwundbare Code tatsächlich erreichbar ist — zuerst das Wichtige triagieren.

Mehr Benachrichtigungskanäle und Wege, Sentinello an die Tools anzubinden, die Ihr Team bereits nutzt.

Erkennen Sie riskante Muster in Ihrem eigenen Code, nicht nur bekannte CVEs in Ihren Abhängigkeiten.

Markieren Sie committete Secrets und Lizenzprobleme im selben Portfolio, in derselben Warteschlange.