Vertrauenszentrum
Zuletzt aktualisiert: 2. August 2026
Jede Aussage auf dieser Seite wird aus dem Quellcode gemessen und von einem Build-Gate erneut geprüft. Wo der Nachweis noch nicht existiert, schweigt diese Seite nicht, sondern sagt es.
Speichersicherheit
Jede Codezeile, die nicht vertrauenswürdige PDF-Bytes liest, ist speichersicheres Rust. Im Parsing-Pfad gibt es kein C und kein C++, und in dessen Abhängigkeitsschluss ebenfalls nicht. Das ist keine Absichtserklärung für die Zukunft, sondern der heutige Stand des Codes, und durchgesetzt wird er vom Compiler.
- 19 von 30 Rust-Crates werden unter #![forbid(unsafe_code)] übersetzt, einer Einstellung, die kein Untermodul wieder aufheben kann.
- In jeder von uns erzeugten Build-Konfiguration sind über die 21 Crates der PDF-Engine hinweg 0 unsichere Operationen erreichbar.
- 71 Crates im Abhängigkeitsschluss des Parsers, davon 0 eingebundene C- oder C++-Bibliotheken.
- 0 unsichere Operationen in 3 Browser-Paketen (WebAssembly).
- 11 Fuzzing-Ziele laufen fortlaufend gegen den Parsing-Pfad, jedes mit einem Startkorpus.
Der gesamte Workspace enthält 21 unsichere Operationen, sämtlich außerhalb des PDF-Pfads: Windows-Anmeldespeicher- und TPM-Aufrufe, ein Kiosk-Tastaturhaken und zwei Testhelfer. Jede ist mit ihrer Begründung in der vollständigen Erklärung aufgeführt.
Die PDFium-Grenze
PDFium ist C++, und wir verbergen das nicht. Es erzeugt Rasterpixel als visuellen Nachweis und sonst nichts. Preflight-Urteile, die Regel-Registry und Konformitätsentscheidungen entstehen in unserem eigenen Rust-Kern, ohne PDFium jemals zu berühren. PDFium kann eine Datei weder freigeben noch ablehnen.
- Läuft als eigener Betriebssystemprozess und wird nie als Bibliothek eingebunden.
- Kein Netzwerkzugriff, Ausführung ohne Root-Rechte, schreibgeschütztes Wurzeldateisystem, alle Capabilities entzogen.
- Nur eine Seite gleichzeitig, mit Grenzen für CPU, Speicher, Prozesse und temporären Speicher, die der Kernel durchsetzt.
- JavaScript (V8) und XFA sind aus dem Build entfernt; der größte Teil der historischen Angriffsfläche von PDFium fehlt damit.
- Isolationsbelege signiert ein unabhängiger Supervisor; der Worker kann seine eigene Isolation nicht bezeugen.
Noch nicht nachgewiesen: Der reproduzierbare PDFium-Build, der die festgeschriebene Binärprüfsumme liefern würde, wurde noch nicht erzeugt. Unser Lieferketten-Validator lehnt das derzeit im Repository liegende Build-Manifest daher ab, und das Render-Backend gilt nicht als produktionstauglich. Das Gate ist fail-closed: Fehlender Nachweis bedeutet, dass der Pfad gar nicht läuft, und nicht, dass er ungeprüft läuft. Die obige Aussage zur Speichersicherheit ist davon unabhängig, denn der Parsing-Pfad erreicht PDFium nie.
Was wir behaupten und was nicht
Ein Preflight-Bericht ist ein diagnostischer Nachweis. Er misst eine Datei und sagt Ihnen, was darin steht; er verändert die Datei nicht und ist kein Produktionsnachweis. Diese Grenze sichtbar zu halten, ist der Zweck dieses Abschnitts.
Wir behaupten
- Wir messen Ihre PDF-Datei und berichten das Gefundene, jeweils mit der Regel und dem Schwellenwert dahinter.
- Wir verändern Ihre Datei nie: keine Farbkonvertierung, keine Reduzierung, kein Schriftersatz, kein Trapping.
- Jeder Befund trägt die Version der Engine und der Regel-Registry, die ihn erzeugt haben.
- Der Parsing-Pfad ist speichersicheres Rust, und ein Build-Gate prüft diese Aussage bei jeder Änderung erneut.
Wir behaupten nicht
- Ein diagnostischer Bericht ist kein zertifizierter Proof und keine Garantie für Druckreife.
- Gerenderte Pixel sind nicht RIP-äquivalent und tragen keine Separationsautorität.
- Eine SBOM listet Komponenten auf; über bekannte Schwachstellen sagt sie nichts.
- Nichts hier behauptet Fehlerfreiheit, sondern nur, dass eine ganze Fehlerklasse konstruktiv ausgeschlossen ist.
Softwarestückliste (SBOM)
CycloneDX 1.6, erzeugt aus den eingecheckten Lockfiles. Das Repository speichert die Prüfsumme jeder SBOM statt der SBOM selbst, denn eine SBOM ist eine reine Funktion eines bereits eingecheckten Lockfiles. Die CI prüft bei jedem Lauf, dass die Prüfsumme weiterhin zu diesen Lockfiles passt.
| SBOM | Komponenten | SHA-256-Prüfsumme |
|---|---|---|
| sbom-rust.cdx.json | 871 | f9e3f4531eda6cc2… |
| sbom-npm.cdx.json | 2452 | d944df1f6a65a671… |
Die vollständigen SBOMs werden als Release-Artefakte veröffentlicht. Für eine Anforderung oder eine Kopie für Ihre Beschaffungsakte schreiben Sie an security@nowtoprint.com.
Koordinierte Offenlegung von Schwachstellen
Melden Sie über den Security-Advisory-Kanal des Repositorys oder per E-Mail. Wir bestätigen den Eingang innerhalb von 3 Werktagen und geben innerhalb von 10 Werktagen eine erste Einschätzung. Das sind Obergrenzen, die sich aus der Teamgröße ergeben, keine Zielwerte. Den Zeitpunkt der Offenlegung stimmen wir mit Ihnen ab; erscheint innerhalb von 90 Tagen kein Fix, liegt die Entscheidung zur Veröffentlichung bei Ihnen.
Nach dem EU Cyber Resilience Act (2024/2847) müssen ab dem 11. September 2026 eine aktiv ausgenutzte Schwachstelle oder ein schwerwiegender Vorfall die ENISA und das zuständige CSIRT binnen 24 Stunden als Frühwarnung und binnen 72 Stunden als Meldung erreichen. Diese Pflicht besteht gegenüber der Aufsicht, nicht gegenüber der meldenden Person: Sie speist sich aus demselben Prozess, ist aber nicht dieselbe Zusage.
Sicherheitskontakt: security@nowtoprint.com
Nachweise
Die obigen Aussagen werden aus den folgenden Dateien erzeugt. Das Repository ist privat, daher sind sie als Pfade aufgeführt: Eine Prüferin kann jede davon im Beschaffungsverfahren namentlich anfordern.
- docs/security/MEMORY_SAFETY_STATEMENT_2026.md
- docs/security/MEMORY_SAFETY_STATEMENT_2026_TR.md
- docs/api/generated/sbom-manifest.v1.json
- docs/api/generated/repo-facts.v1.json
- deploy/pdf-workers/pdf-worker-isolation-policy.v1.json
- scripts/ci/memory-safety-claim-check.mjs
- SECURITY.md