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.

• Portal und Homepage wechseln von Next.js 16.3.6 auf 16.4.0, das sechs Hinweise in Next selbst behebt: eine serverseitige Anfragefälschung (SSRF) in der Bildoptimierung (hoch); zwei Cache-Poisoning-Lücken in SSG- und ISR-Seiten selbst gehosteter Instanzen – so läuft Sentinello; Draft-Mode-Inhalte, die über ein ausstehendes <code>use cache</code>-Befüllen in normale Antworten gelangten; Metadaten-Bildrouten, die <code>dynamicParams</code> ignorierten; und ein Informationsleck am MCP-Endpunkt des Entwicklungsservers, den nur <code>pnpm dev</code> bereitstellt. 16.4.0 war älter als einen Tag, lag aber noch in der siebentägigen Quarantäne, die Sentinello auf neue Releases anwendet; die Quarantäne wurde deshalb nur für dieses eine Update gesenkt. <code>braces</code> 3.0.3 hat weiterhin kein korrigiertes Release und wird nur über Entwicklungswerkzeuge erreicht.

• Das Portal lag bei 7–17 % CPU, obwohl nichts geschah. Ursache war der MCP-Endpunkt: Ein Client wie Claude Code fordert mit <code>GET /api/mcp</code> einen Stream an; der Endpunkt – der keine Sitzungen führt – öffnete einen und schloss ihn nach wenigen Millisekunden, und der Client verband sich sofort neu. Das ergab etwa vier Anfragen pro Sekunde für jede offene Claude-Code-Sitzung mit eingerichtetem Sentinello, und jede prüfte das Token und baute einen vollständigen MCP-Server auf. <code>GET</code> und <code>DELETE</code> antworten jetzt mit <code>405 Method Not Allowed</code> – so teilt ein Server ohne Stream das laut MCP-Spezifikation mit –, und die Clients fragen nicht mehr. Auf einer laufenden Instanz gemessen: danach keine Neuverbindungen mehr, und das Portal liegt im Leerlauf wieder bei etwa 0,1 % CPU. Tool-Aufrufe funktionieren wie bisher.
• Die Projektseite kostete beim Rendern etwa 1,3 Sekunden CPU, und sie wird jede Minute neu gerendert, solange ein Tab offen ist, während eines Scans sogar alle fünf Sekunden. Fast alles davon war ein einziger Lesevorgang: Den jeweils neuesten Scan jeder Quelle für jedes Projekt zu finden, ging durch alle Scan-Zeilen, und auf einer Instanz mit 109.000 Scans hieß das, jedes Mal 445 MB gespeicherter Scan-Ausgaben zu durchlaufen. Ein neuer Index beantwortet das direkt – von etwa 1,1 Sekunden auf etwa 30 Millisekunden, mit denselben Ergebnissen –, und die ganze Seite kostet jetzt etwa eine Viertelsekunde. Der Index wird einmalig beim Update angelegt; auf der 2,3 GB großen Datenbank dieser Instanz dauerte das etwa drei Sekunden.
• Vier Sicherheitshinweise zu Sentinellos eigenen Abhängigkeiten sind behoben: <code>proxy-addr</code> 2.0.8 (kritisch, IP-Spoofing über ein vertrauenswürdiges IPv6-Subnetz mit IPv4-gemappten Adressen) und <code>@modelcontextprotocol/sdk</code> 1.31.0 (hoch, sein OAuth-Client konnte Zugangsdaten an einen vom MCP-Server gewählten Autorisierungsserver senden), beide hinter dem MCP-Endpunkt; <code>sharp</code> 0.35.5 (kritisch, in der mitgelieferten librsvg), das Next für Bilder nutzt; und <code>source-map-js</code> 1.2.2 (hoch, Denial of Service der Event-Loop) in den Build- und Testwerkzeugen. Jede dieser Versionen hatte die siebentägige Quarantäne durchlaufen, die Sentinello auf neue Veröffentlichungen anwendet. Ein Hinweis bleibt: Für <code>braces</code> 3.0.3 gibt es keine korrigierte Version, und es wird nur über Entwicklungswerkzeuge erreicht. Einer seiner beiden Pfade war <code>nodemon</code>, das nirgends genutzt wurde und entfernt ist; der andere führt über das Lint-Plugin von Next und entfällt, sobald dieses <code>fast-glob</code> 3 nicht mehr verwendet.
• Wer Sentinello aus dem Quellcode baute, konnte ein älteres Portal im neuen Build erhalten. Der Build-Cache berücksichtigte Änderungen in Sentinellos gemeinsamen Paketen nicht, sodass <code>pnpm build</code> bei einer Version, die nur diese änderte – etwa die Datenbankabfragen –, den vorherigen Portal-Build wiederherstellen konnte, statt einen neuen zu erzeugen. Eine Änderung in einem beliebigen gemeinsamen Paket macht jetzt den Build und die Typprüfung jeder App ungültig, die es verwendet. Die Docker-Images und die npm-CLI werden von Grund auf neu gebaut und waren nicht betroffen.

• Sentinello empfahl, <code>braces</code> auf 3.0.4 und <code>node-forge</code> auf 1.4.1 zu aktualisieren. Keine der beiden Versionen wurde je veröffentlicht, und kein Advisory nannte sie: Wenn ein Advisory „3.0.3 und alles davor ist betroffen“ sagte und keinen Fix angab, riet Sentinello das nächste Patch-Release. Außerdem übernahm es die Version, die npm audit für ein <em>übergeordnetes</em> Paket vorschlägt, als Fix für das Kindpaket – <code>minimatch</code> 12.0.1 für eine Lücke, die in 3.0.5 behoben ist. Auf der Instanz, auf der das auffiel, standen 35 nicht existierende Versionen an 296 Befunden, darunter <code>qs</code> 6.15.4 an 113 Befunden, für die es die ganze Zeit einen echten Fix gab, 6.16.0. Agenten, die diese Fixes einspielen sollten, verloren ganze Läufe mit der Suche nach Releases, die es nie gab.
• Jeder npm-Fix wird jetzt nach jedem Scan gegen die npm-Registry geprüft. Angezeigt wird das niedrigste veröffentlichte Release, das neuer ist als jede installierte Kopie und außerhalb des betroffenen Bereichs jeder Quelle liegt, die das Advisory gemeldet hat – sind sich npm audit und OSV uneinig, erfüllt der Fix beide. Jeder Befund trägt eine von drei Antworten: eine Version, auf die aktualisiert werden kann; <strong>Keine korrigierte Version veröffentlicht</strong>, wenn kein veröffentlichtes Release infrage kommt; oder „nicht gegen die Registry geprüft“, mit dem Fix, den das Advisory selbst nennt, falls vorhanden, und dem Grund, warum nicht geprüft werden konnte (Registry nicht erreichbar, Paket nicht auf npm, ein Bereich, der nicht gelesen werden konnte). Eine nicht erreichbare Registry wird nie von sich aus zu „kein Fix“: Sentinello verwendet früher abgerufene Paketmetadaten wieder, sofern sie noch brauchbar sind, bewertet die aktuellen Befunde danach und versieht die Antwort mit dem Datum dieses Abrufs; ohne brauchbare zwischengespeicherte Metadaten erscheint der Fix als ungeprüft. Der Befund selbst wird immer gemeldet, mit seinem üblichen Schweregrad – ein fehlender Fix ist kein Grund, ihn zu verbergen.
• Ist keine korrigierte Version veröffentlicht, zeigt der Befund jetzt den Ausweg statt einer Version, der man hinterherjagt. Er sagt, ob das Paket veraltet oder nicht mehr gepflegt ist (seit sechs Monaten oder länger nichts veröffentlicht), mit seinem letzten Release, seinen Maintainern und seinen wöchentlichen Downloads. Für jeden Abhängigkeitspfad sagt er, ob ein Upgrade von etwas oberhalb des Pakets es loswird – und behauptet das erst, nachdem der gesamte Abhängigkeitsbaum dieses Releases geprüft wurde, nicht nur seine direkten Abhängigkeiten – oder dass der Weg versperrt ist: Bei <code>nodemon</code> › <code>chokidar</code> › <code>braces</code> verzichtet chokidar 4 auf braces, aber kein veröffentlichtes nodemon akzeptiert chokidar 4. Hilft nichts auf dem Pfad, bietet er bewährte Alternativen aus der module-replacements-Liste von e18e an, jeweils geprüft, dass sie das verwundbare Paket nicht zurückbringen (<code>tinyglobby</code> statt <code>fast-glob</code>), oder als „nicht verifiziert“ markiert, wenn diese Prüfung nicht abgeschlossen werden konnte, und er sagt, wenn nur Entwicklungswerkzeuge das Paket erreichen. Der Ausweg erscheint in der Befundtabelle, im Advisory-Export, in <code>list_findings</code> von MCP und in den Benachrichtigungen.
• Befunde, die vor diesem Release erfasst wurden, zeigen bis zum nächsten Scan ihres Projekts „Fix noch nicht erneut geprüft — erneuter Scan ausstehend“ statt der alten geratenen Version. Der Standard-Prompt für die Behebung hat einen neuen Abschnitt, der den Agenten anweist, nicht nach einem Fix des verwundbaren Pakets zu suchen, den Sentinello nicht verifizieren konnte, ihn nicht zu pinnen oder per Override zu erzwingen, sondern dem Ausweg zu folgen und eine als „nicht verifiziert“ markierte Alternative selbst zu prüfen, bevor er sie empfiehlt; wer den Prompt in den Einstellungen angepasst hat, behält seinen Text unverändert und sollte ihn mit dem neuen Standard vergleichen. <code>list_findings</code> von MCP erhält <code>fixStatus</code>, <code>fixCheck</code> und <code>remediation</code>, und der Webhook ergänzt <code>fixStatus</code> und <code>remediation</code>; sein <code>recommendedVersion</code> ist jetzt immer nur eine veröffentlichte Version. Der Kommandozeilen-Scanner, <code>npx sentinello</code>, prüft npm genau wie der Worker, mit demselben Code: dieselben drei Antworten und derselbe Ausweg, in seiner Zusammenfassung, seinem Markdown und seinem JSON. Dafür kontaktiert jetzt auch er <code>registry.npmjs.org</code> und <code>api.npmjs.org</code>, sendet dabei nur Paketnamen und bewahrt die Antworten 24 Stunden neben seinen Advisory-Datenbanken auf; <code>--offline</code> stellt keinerlei Netzwerkanfrage, und seine Fixes lauten dann „nicht gegen die Registry geprüft (offline)“.
• Dafür kontaktiert der Worker jetzt <code>registry.npmjs.org</code> für Paketmetadaten und <code>api.npmjs.org</code> für Downloadzahlen – für Pakete mit Befunden und die Pakete oberhalb davon und, wenn kein Fix veröffentlicht ist, für die Kandidaten-Releases und Alternativen, die der Ausweg abwägt, samt ihren Abhängigkeitsbäumen. Es gibt keine Obergrenze für Abfragen: Jedes Paket, das der Ausweg braucht, wird gelesen, sodass ein Ausweg nie halb fertig bleibt, weil ein Budget aufgebraucht war. Die Abfragen laufen parallel, und eine Antwort, die älter als 24 Stunden ist, wird mit ihrem ETag erneut angefragt, sodass ein unverändertes Paket als leeres <code>304</code> zurückkommt. Eine erfolgreiche Antwort wird 24 Stunden lang wiederverwendet; eine fehlgeschlagene Anfrage wird nicht gespeichert und kann daher früher wiederholt werden. Beide stehen auf der Seite „Über“ unter „Was Sentinello nach außen sendet“. <code>SENTINELLO_NPM_REGISTRY_URL</code> und <code>SENTINELLO_NPM_DOWNLOADS_URL</code> leiten sie auf einen Mirror um.
• Ein Projekt, das Sentinello nicht scannen kann, sagt das jetzt – und warum. ddns, ein Projekt, dessen <code>package.json</code> seine Lockfile verloren hatte, zeigte seine früheren Befunde für immer mit „erneuter Scan ausstehend“: Kein Scan konnte sie je klären. Ein solches Projekt zeigt jetzt <strong>Projekt kann nicht gescannt werden</strong> mit seinem Grund – „Keine Lockfile“ – und wessen Sache die Behebung ist: die des Projekts oder die dieser Sentinello-Installation, etwa bei einer noch nicht heruntergeladenen Advisory-Datenbank. Eines, das nur einige Quellen lesen konnten, zeigt <strong>Projekt kann nicht vollständig gescannt werden</strong>. Beides erscheint auf der Projektseite, in der Projektliste, im Dashboard, in <code>list_projects</code>, <code>get_project</code> und <code>get_dashboard_summary</code> von MCP, im Kommandozeilen-Scanner, im Advisory-Export und in den Benachrichtigungen, in denen ein Fehler, den das Projekt beheben muss, den Titel <code>[CANNOT BE SCANNED]</code> trägt und der Webhook <code>scanState</code> mitliefert. Keines von beiden wird je als alles in Ordnung angezeigt: Null Befunde bedeuten dort unbekannt, nicht sicher. Die Befunde, die ein früherer Scan erfasst hat, bleiben mit ihrem Schweregrad gelistet, markiert mit „nicht erneut geprüft — das Projekt kann nicht gescannt werden: Keine Lockfile“ und dem Datum des letzten erfolgreichen Scans, bis ein Scan wieder gelingt.

• Sentinello scannt seinen eigenen Quellbaum wie jedes andere Projekt — und meldete 33 Schwachstellen gegen sich selbst: 3 kritische, 17 hohe, 10 mittlere und 3 niedrige nach Sentinellos Einstufung, oder 1 kritische, 13 hohe, 16 mittlere und 3 niedrige nach der Einstufung von npm audit für dieselben 33. Die eine, die beide als kritisch einstufen, ist eine Remote-Code-Ausführung im Bild-Renderer <code>next/og</code> von Next.js, und beide Anwendungen wechseln auf Next 16.3.6, das Release, das sie behebt. Sentinello nutzt <code>next/og</code> nur für das Social-Media-Vorschaubild der Homepage, das ausschließlich den eigenen übersetzten Slogan und die Beschreibung zeichnet; das verringert die Angriffsfläche, aber das Update hängt nicht davon ab.
• <code>axios</code> wechselt im Worker und im Benachrichtigungspaket von 1.18.1 auf 1.20.0, wegen zwölf Schwachstellen — zwei davon kritisch nach Sentinellos Einstufung, keine über „hoch“ nach der von npm audit. Sentinello erreicht axios nur über den HTTP-Adapter von Node, um Benachrichtigungen an Slack, Telegram und Webhooks zuzustellen. Mehrere der zwölf stecken in den Fetch- und HTTP/2-Adaptern, die es nie verwendet, aber nicht alle: ein Socket-Hijacking über einen verunreinigten Prototyp und ein ReDoS beim Abgleich der Proxy-Ausnahmen liegen auf dem Pfad, den es nutzt. Weil die Benachrichtigungstests axios durch eine Attrappe ersetzen, wurde die neue Version zusätzlich gegen einen lokalen Empfänger mit genau den Aufrufen der Benachrichtigungsmodule durchgespielt: Zustellung, ein Webhook, der Weiterleitungen weiterhin verweigert, Fehler- und Timeout-Behandlung sowie das Routing über einen Proxy und an ihm vorbei.
• Drei von Sentinellos eigenen Versionsfixierungen waren selbst zu den verwundbaren Versionen geworden. <code>brace-expansion</code>, <code>ip-address</code> und <code>fast-uri</code> standen jeweils auf dem Release, das eine frühere Schwachstelle geschlossen hatte, und heute decken zehn Schwachstellen genau diese Releases ab — eine bei <code>fast-uri</code> betrifft ausschließlich 3.1.6, also genau die Version, die die Fixierung nannte. Die Fixierungen anzuheben hätte die Uhr nur neu gestartet, also wurden sie entfernt: Das Elternpaket verlangt jeweils schon einen Bereich, der ein korrigiertes Release auflöst, und die Lockfile hat sie innerhalb dieser Bereiche auf brace-expansion 5.0.12, ip-address 10.7.2 und fast-uri 3.1.8 bewegt, ohne etwas zu erzwingen. <code>brace-expansion</code> hängt am Linter und wird nie ausgeliefert; die anderen beiden hängen am MCP-SDK hinter dem MCP-Endpunkt des Portals.
• Das war der Anlass, jede Fixierung zu prüfen, und aus siebzehn wurden zwei. Die übrigen hatten ihren Zweck erfüllt — nach den Updates von Next.js, dem MCP-SDK und postcss löst der Bereich jedes Elternpakets von sich aus eine sichere Version auf — oder waren befristete Obergrenzen, die bei der nächsten Abhängigkeitsprüfung entfernt werden sollten. Beide verbliebenen schützen Build-Werkzeuge, nicht Code, den Sentinello ausführt: ein gepatchtes <code>esbuild</code> unter <code>drizzle-kit</code>, dessen neuestes Release noch einen veralteten Loader mit einer verwundbaren Kopie mitzieht, und <code>esbuild</code> 0.28.1 unter <code>tsup</code>, das die CLI baut. Die Notiz zu Letzterer behauptete bisher, 0.28.1 liege im Bereich jedes Konsumenten; das stimmt nicht — tsup verlangt 0.27, wofür es kein gepatchtes Release gibt —, und die Notiz sagt das jetzt.
• Die letzten zehn stecken in <code>undici</code>, das nur die Browser-Emulation der Testsuite verwendet, und verschwinden mit dessen Wechsel auf 7.29.1; ein ausgeliefertes Build haben sie nie erreicht. <code>pnpm audit</code> meldet keine bekannten Schwachstellen mehr. Jede übernommene Version war seit mindestens acht Tagen veröffentlicht und hat damit ausnahmslos die Sieben-Tage-Quarantäne bestanden, die Sentinello neuen Releases auferlegt — neuere Patches, die nichts auf dieser Liste beheben, blieben außen vor.

• Sentinello scannt seinen eigenen Quellbaum wie jedes andere Projekt — und meldete drei kritische Schwachstellen gegen sich selbst. Zwei davon sind unauthentifizierte Remote-Code-Ausführung in Next.js: eine auf Windows-gehosteten Servern erreichbar, die andere über die Image-Optimization-API, sobald eine AVIF-Datei ausgeliefert wird. Auf der 16.2er-Linie gibt es für keine von beiden eine Korrektur, also wechseln beide Anwendungen auf Next 16.3.4. Die dritte steckt in <code>sharp</code>, das Next zum Skalieren von Bildern verwendet, und festgehalten wurde sie von Sentinellos eigener Versionsfixierung: Die war einst gesetzt worden, um eine ältere sharp-Schwachstelle zu schließen, als noch kein stabiles Next eine gepatchte Kopie auflöste — Next 16.3 verlangt sie inzwischen von sich aus. Die Fixierung zu entfernen war die Korrektur.
• Zwei weitere Fixierungen waren denselben Weg gegangen: geschrieben, um eine Schwachstelle zu schließen, stehen gelassen und still zu dem geworden, was die nächste festhielt. <code>fast-uri</code> stand auf der Version, die eine Host-Verwechslung behob; seitdem sind vier weitere hohe Meldungen dazugekommen, drei davon Server-Side Request Forgery. <code>hono</code> stand auf der Version, die einen ReDoS in seiner CORS-Middleware behob, und hat seither drei mittlere angesammelt, darunter einen Pfaddurchlauf in <code>toSSG()</code>, der selbst die unvollständige Korrektur eines früheren war. Beide Fixierungen nennen jetzt eine aktuelle Version, und jede trägt eine Notiz dazu, was sie schließt und wann sie entfernt gehört.
• Die übrigen Meldungen werden durch schlichte Versionswechsel erledigt: <code>js-yaml</code> auf 4.3.2 gegen eine hohe Schwachstelle, bei der ein präparierter Merge-Key unbegrenzt CPU verbraucht — was für einen Scanner zählt, der fremdes YAML liest —, <code>qs</code> auf 6.16.0 gegen zwei Denial-of-Service-Pfade im Query-Parser hinter dem MCP-Endpunkt, und <code>vitest</code> auf 4.1.11 gegen ein beliebiges Dateilesen, das immer nur den Testrunner erreichte. Eine sechzehnte, in einem von Next mitgezogenen Paket mit Browser-Kompatibilitätsdaten, erledigte sich von selbst, sobald der Baum auf die von Sentinello ohnehin fixierte Kopie zusammenfiel. <code>pnpm audit</code> meldet über alle 741 Abhängigkeiten hinweg keine bekannten Schwachstellen mehr, und jede beteiligte Version war lange genug veröffentlicht, um die Sieben-Tage-Quarantäne zu bestehen, die Sentinello neuen Releases auferlegt — eine Ausnahme war nicht nötig.

• 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.