Centre de confiance
Dernière mise à jour : 2 août 2026
Chaque affirmation de cette page est mesurée depuis le code source et revérifiée par une barrière de compilation. Là où la preuve n existe pas encore, cette page le dit au lieu de se taire.
Sûreté mémoire
Chaque ligne de code qui lit des octets PDF non fiables est écrite en Rust à sûreté mémoire. Il n y a ni C ni C++ dans le chemin d analyse, ni dans sa fermeture de dépendances. Ce n est pas un engagement de feuille de route : c est l état actuel du code, et c est le compilateur qui l impose.
- 19 des 30 crates Rust sont compilées sous #![forbid(unsafe_code)], un réglage qu aucun sous-module ne peut rouvrir.
- Dans chaque configuration de compilation que nous produisons, 0 opérations non sûres sont atteignables sur l ensemble des 21 crates du moteur PDF.
- 71 crates dans la fermeture de dépendances de l analyseur, dont 0 bibliothèques C ou C++ liées.
- 0 opérations non sûres sur 3 paquets navigateur (WebAssembly).
- 11 cibles de fuzzing tournent en continu contre le chemin d analyse, chacune avec un corpus initial.
L espace de travail contient 21 opérations non sûres au total, toutes hors du chemin PDF : appels au coffre d identifiants Windows et au TPM, un crochet clavier en mode kiosque, et deux utilitaires de test. Chacune est listée avec sa justification dans la déclaration complète.
La frontière PDFium
PDFium est écrit en C++, et nous ne le cachons pas. Il produit des pixels matriciels comme preuve visuelle, rien d autre. Les verdicts de contrôle en amont, le registre de règles et les décisions de conformité sortent de notre propre noyau Rust sans jamais passer par lui. PDFium ne peut ni approuver ni refuser un fichier.
- S exécute comme un processus système distinct ; il n est jamais lié comme bibliothèque.
- Aucun accès réseau, utilisateur non privilégié, racine du système de fichiers en lecture seule, toutes les capacités retirées.
- Une page à la fois, avec des limites de processeur, de mémoire, de processus et de stockage temporaire imposées par le noyau.
- JavaScript (V8) et XFA sont retirés de la compilation, ce qui supprime la plus grande part de la surface de vulnérabilité historique de PDFium.
- Les reçus d isolation sont signés par un superviseur indépendant ; le worker ne peut pas attester de sa propre isolation.
Ce qui n est pas encore prouvé : la compilation reproductible de PDFium qui fournirait l empreinte binaire épinglée n a pas encore été produite. Notre validateur de chaîne d approvisionnement rejette donc le manifeste de compilation présent dans le dépôt, et le moteur de rendu n est pas éligible à la production. La barrière est en échec fermé : une preuve manquante signifie que le chemin ne s exécute pas, et non qu il s exécute sans vérification. L affirmation de sûreté mémoire ci-dessus en est indépendante, car le chemin d analyse n atteint jamais PDFium.
Ce que nous affirmons et ce que nous n affirmons pas
Un rapport de contrôle en amont est une preuve diagnostique. Il mesure un fichier et vous dit ce qu il contient ; il ne modifie pas le fichier et ne constitue pas une preuve de production. Garder cette limite visible est tout l objet de cette section.
Nous affirmons
- Nous mesurons votre PDF et rapportons nos constats, en nommant la règle et le seuil derrière chacun.
- Nous ne modifions jamais votre fichier : pas de conversion colorimétrique, pas d aplatissement, pas de substitution de polices, pas de recouvrement.
- Chaque constat porte la version du moteur et celle du registre de règles qui l ont produit.
- Le chemin d analyse est en Rust à sûreté mémoire, et une barrière de compilation revérifie cette affirmation à chaque changement.
Nous n affirmons pas
- Un rapport diagnostique n est pas une épreuve certifiée ni une garantie d aptitude à l impression.
- Les pixels rendus ne sont pas équivalents à un RIP et ne portent aucune autorité de séparation.
- Une SBOM énumère des composants ; elle ne dit rien des vulnérabilités connues.
- Rien ici n affirme l absence de bogues, seulement qu une classe entière d entre eux est exclue par construction.
Nomenclature logicielle (SBOM)
CycloneDX 1.6, générée depuis les fichiers de verrouillage versionnés. Le dépôt conserve l empreinte de chaque SBOM plutôt que la SBOM elle-même, car une SBOM est une fonction pure d un fichier de verrouillage déjà versionné. L intégration continue vérifie à chaque exécution que l empreinte correspond toujours à ces fichiers.
| SBOM | Composants | Empreinte SHA-256 |
|---|---|---|
| sbom-rust.cdx.json | 871 | f9e3f4531eda6cc2… |
| sbom-npm.cdx.json | 2452 | d944df1f6a65a671… |
Les SBOM complètes sont publiées comme artefacts de version. Pour les demander, ou en obtenir une copie pour un dossier d achat, écrivez à security@nowtoprint.com.
Divulgation coordonnée des vulnérabilités
Signalez via le canal d avis de sécurité du dépôt ou par courriel. Nous accusons réception sous 3 jours ouvrés et donnons une première évaluation sous 10 jours ouvrés. Ce sont des bornes supérieures fixées par la taille de l équipe, pas des objectifs. Nous coordonnons le calendrier de divulgation avec vous ; si aucun correctif n est publié sous 90 jours, la décision de publier vous appartient.
En vertu du règlement européen sur la cyberrésilience (2024/2847), à partir du 11 septembre 2026, une vulnérabilité activement exploitée ou un incident grave doit parvenir à l ENISA et au CSIRT compétent sous forme d alerte précoce sous 24 heures et de notification sous 72 heures. Cette obligation vise le régulateur, pas la personne qui signale : elle est alimentée par le même processus, mais ce n est pas la même promesse.
Contact sécurité : security@nowtoprint.com
Preuves
Les affirmations ci-dessus sont générées à partir des fichiers suivants. Le dépôt est privé, ils sont donc listés par chemin : un auditeur peut demander chacun d eux par son nom lors d une revue d achat.
- 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