Frequently Asked Question

This document provides comprehensive information regarding the security architecture, software supply chain, data privacy, and vulnerability management lifecycle for Pdfium.Net SDK. It is designed to assist enterprise cybersecurity, compliance, and procurement teams during their vendor due diligence reviews.

1. Supply Chain & Binary Security

• Does the SDK track Google's Chromium/Pdfium release branches directly?
  No. Patagames maintains a proprietary independent fork of the core Pdfium engine. We do not rely on upstream Google Chromium stable branches for hotfixes. Instead, all performance optimizations, memory leak remediations, and security patches are engineered and implemented internally and independently by the Patagames development team.
• Are the distributed binaries digitally signed?
  No, distributed DLL assemblies (both managed .NET wrappers and native C++ engine binaries) are unsigned to remain compatible with standard open-source and independent deployment pipelines.
• How can we verify binary integrity?
  To prevent tampering, the definitive SHA-256 fingerprints for every build are automatically generated and published inside the validation report of each runtime package. For instance, you can audit the cryptographically verified SHA-256 hashes for our native runtime packages directly on the official distribution portal (e.g., NuGet Gallery | PtgPdfCore.runtime.win Specification).
• How do you ensure that distribution packages (NuGet/Website) remain free of malware?
  We implement strict isolation inside our CI/CD pipeline rather than relying on legacy runtime antivirus scanning:
  • Isolated Environments: All builds are executed on dedicated, locked-down build servers.
  • Ephemeral Environments: The Windows compilation environment is completely immutable; it is instantiated dynamically from a clean, pristine gold-image snapshot for every single build execution and destroyed immediately afterward.
  • Integrity Auditing: Automated pipelines calculate SHA-256 fingerprints at the compile step to block any unauthorized code modification prior to distribution pipeline deployment.

2. Software Composition & Data Privacy

• Does the SDK perform remote licensing validation or telemetry tracking at runtime?
  No. The current codebase of the SDK (v5.x and newer) contains zero outbound network triggers. The SDK does not transmit telemetry data, track application usage, or perform runtime "phone home" license validation calls.
• Can the SDK run safely inside a strict air-gapped network with no internet access?
  Yes. Because there are no runtime license checks or telemetry features built into the code, compiled client applications utilizing the SDK will run flawlessly in strictly isolated, air-gapped production environments without throwing licensing exceptions or network timeouts.
  (Note: Future license activation workflows might utilize an internet connection exclusively on the developer's workstation or CI/CD build machine during compilation, but never within the distributed end-user application).
• Does the SDK store or transmit PDF contents externally?
  No. The SDK never transmits PDF documents, text, or metadata to external servers, nor does it copy files to temporary system directories.
• Is processing entirely in-memory?
  Processing is handled strictly within the local boundaries of your application's process. However, to handle massive engineering/enterprise blueprints and high-volume files without exhausting RAM, the SDK uses an on-demand stream processor. If a document is opened directly from the disk, the file must remain accessible at its local path until execution terminates, as the SDK reads chunks dynamically from the local storage.
• Is the SDK compliant with global privacy regulations?
  Yes. Because the SDK operates exclusively within your local runtime infrastructure and does not collect, store, or transmit any personal data or document content to Patagames or any third party, it does not act as a Data Processor or Data Controller. Integrating this SDK into your stack will not impact your compliance with GDPR, HIPAA, or CCPA regulations

3. Vulnerability Management & Lifecycles

• Where should we report discovered security defects?
  Security research groups, corporate clients, and developers should route discovered vulnerabilities or regression findings directly to our primary response engineering queue at: support@patagames.com.
• What is your SLA for releasing security hotfixes?
  Patagames does not enforce a rigid, single-hour SLA, as fix timelines depend entirely on the root cause complexity. Deficiencies contained within our managed .NET wrapper layer are typically remediated rapidly. However, anomalies tied to environmental constraints (such as historical WPF hardware-rendering defects caused by out-of-date display drivers on specific OEM hardware) require external coordination.
• How do you handle security if our app runs on an older .NET version?
  Our SDK supports a wide range of platforms—from legacy .NET Framework 2.0 up to modern .NET 8, 9, and 10. When we patch a bug or a security issue, the fix is applied across all versions. This ensures your application remains secure regardless of the underlying .NET framework version you use.
  
• Where can we track update history?
  We maintain a highly transparent release cadence. You can audit our active version updates, patch logs, and version rollout history at any time on our public portal: Patagames Version History Forum.