Trust center

At a glance

This is the trust center for the NextPDF core engine. Start here for four documents: the engine threat model, the signature and encryption security model, the data-handling and personally identifiable information (PII) behavior, and the vulnerability-disclosure policy. Each page describes a specific part of how the library behaves, and where the library’s responsibility ends and your deployment’s responsibility begins.

Boundary. This page and the pages it links to describe engineering posture: the design choices, defaults, and mitigations built into the core engine and verified by its test suite. They are not a certification, audit report, or legal warranty. No statement here asserts that the library is “secure” in your deployment. Security is a property of the whole system: your key custody, your verifier policy, your network, and your operational practices, not of one dependency.

Install

The trust posture described here applies to the core engine:

composer require nextpdf/core:^3

No additional package is required to read these pages. The core test suite that ships in the same package exercises the behaviors they describe.

Conceptual overview

The trust center is organized around a simple principle: a documentation page must state what the engine does and what it does not promise. The four sub-pages divide that surface:

Threat model — the attack classes the engine considers (server-side request forgery (SSRF), XML external entity (XXE) processing, decompression bombs, path traversal, and content injection), the default-deny posture, and the in-code guards that mitigate each class. It documents considered threats. It does not claim the absence of vulnerabilities.
Security model — the cryptographic surface: 256-bit Advanced Encryption Standard (AES-256) document encryption, the reader-cooperative nature of Portable Document Format (PDF) permission bits, and the Cryptographic Message Syntax (CMS)/PDF Advanced Electronic Signatures (PAdES) B-B and B-T signing path. It explains why support for a mechanism is not the same as security in your deployment.
Data handling — what data the library reads, holds in memory, and writes; the PII-scrubbing transform applied to audit bundles; and the opt-in, zero-overhead telemetry path. It describes library behavior, not deployment-level data residency.
Disclosure — the coordinated vulnerability disclosure process: private intake channels, response timeline targets, and the embargo model. It is a process commitment, not a guarantee of outcome.

Every page renders its normative claims as a claim → clause-id + reference_id table sourced from its front-matter citations: block. You can trace the standards basis for each statement.

API surface

Not applicable. The trust center is documentation. The application programming interfaces (APIs) that back the described behavior are covered in the module reference pages (/modules/core/security/, /modules/core/audit/) and are not re-listed here. This page links to the trust facets, not to symbols.

Code sample — Quick start

Not applicable. This is an index page. It asserts no runnable behavior. The sub-pages that describe runtime behavior include code samples where core can demonstrate the behavior.

Code sample — Production

Not applicable. See the sub-pages.

Edge cases & gotchas

A trust page is not a contract. Reading these pages does not grant a warranty. The license (Apache-2.0) governs, and its warranty disclaimer applies in full.
Posture is versioned. The defaults and guards described here are those of the current stable major. An older major may have a weaker default. The security policy records which majors receive fixes.
“Support” is a recurring trap. Throughout the trust center, support for a profile or mechanism is never the same as conformance to that profile or security in your deployment. Each page restates this boundary in its own terms.

Performance

Not applicable. Documentation has no runtime cost. The relevant module pages document the performance envelope of the underlying security operations.

Security notes

The trust center makes security boundaries explicit rather than implied. Two cross-cutting boundaries apply to every page:

Defaults are fail-closed, not foolproof. Every policy object in the engine ships with the strictest position the public API permits. Relaxing it requires explicit caller opt-in. A fail-closed default reduces the chance of an accidental exposure. It does not remove your responsibility to review the configuration you choose. This mirrors the baseline-configuration principle in National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53 Rev. 5 CM-7 (nist_sp_800_53r5#x4.x182.p14): a minimized baseline is a starting point. Any relaxation is an explicit, recorded decision.
Documented requirements, not blanket assurance. The trust center verifies behavior against documented security requirements, in the spirit of Open Worldwide Application Security Project (OWASP) Application Security Verification Standard (ASVS) 5 (owasp_asvs_5#x165): a verification standard measures conformance to enumerated requirements. It does not certify that nothing was missed.

Conformance

Not applicable as a profile. This index does not implement a conformance profile. Where a sub-page touches a standard (International Organization for Standardization (ISO) 32000-2 for encryption and signatures, ISO/IEC 29147/30111 with the International Electrotechnical Commission (IEC) for disclosure, European Union (EU) General Data Protection Regulation (GDPR) / ISO/IEC 29100 for data handling), it cites the specific clause and reference_id in its own front-matter. It renders the claim → clause table itself.