This document describes the security philosophy and principles that guide how we build DocSpec. It is not a threat model, vulnerability policy, or security audit. It is how we think about security.

DocSpec is written in Rust with unsafe_code forbidden. Memory safety is not a feature we added. It is the default. Buffer overflows, use-after-free, data races: these entire categories of vulnerability are eliminated by construction.

This matters for a document conversion library. Document formats are complex. Parsers for complex formats have historically been fertile ground for memory corruption vulnerabilities. We eliminate this risk at the language level.

The manifesto says: "The compiler is our ally. We do not bypass it." This applies doubly to security. Every bounds check is enforced. Every lifetime is verified. Every pointer is valid or it does not compile.

Memory safety is our first line of defense. It is not perfect — logic errors still exist — but it removes the most common and most dangerous class of security bugs entirely. An attacker cannot exploit a buffer overflow in our code because the language makes buffer overflows impossible.

This is why we forbid unsafe code completely. There are no exceptions. No special cases. If you cannot do it safely, you do not do it. Period.

The choice of Rust is a security decision. Other languages could work. Rust works best because it gives us safety without sacrificing performance. We do not need to choose between fast and safe. We get both.

How errors are reported depends on the context. The principle: do not leak internal details to untrusted surfaces.

For CLI tools: the user is a developer or administrator. More detail is appropriate. Full error messages including context help diagnose problems. Stack traces can be enabled with flags. File paths are shown because the user needs to know which file failed.

For library users: the caller receives typed error values. They decide what to show to their users. The library does not make this decision for them. A library user might be building a web service, a desktop app, or an embedded system. Each has different security requirements. We provide the error; they handle the disclosure.

The general rule: the closer to an untrusted surface, the less detail the error contains. Information leakage is a vulnerability. Error messages that reveal internal structure help attackers craft better attacks. We do not help attackers.

All input is untrusted. Every byte of every document comes from outside the process — from a user, a network, a filesystem. We parse defensively.

Parsers fail fast on malformed input rather than attempting recovery. A malformed ZIP structure in a DOCX file returns an error immediately. No attempt to "guess" at the correct structure. No partial parsing that could produce wrong output that looks correct.

This is the "fail fast" principle from our manifesto applied to security. A failed conversion is better than a wrong conversion. Wrong conversions propagate. They corrupt databases. They break trust. When the input is broken, we say so immediately.

Parsers are hardened against malicious input through continuous fuzzing. Fuzz tests send random and adversarial byte sequences at every parser. The goal: no input causes a crash, a panic, or undefined behavior. The fuzz corpus grows as new edge cases are discovered.

Fuzzing runs in CI on every commit. It runs for hours, not minutes. We use coverage-guided fuzzing to find inputs that exercise new code paths. We track the corpus over time. A crash in fuzzing is treated as a security bug, even if it seems hard to exploit. We fix it.

Document formats are attack surfaces. A malicious DOCX could try to exploit a ZIP parser. A malformed HTML document could try to cause excessive memory use. Our parsers are designed to handle these cases gracefully. They validate. They limit. They fail safely.

Parsers and converters enforce resource bounds. Memory caps prevent a single large document from exhausting the process. Time limits prevent denial of service through documents designed to be slow to process.

Specific bounds depend on the integration surface:

• Inline assets (embedded images) are capped at a maximum size before streaming to output
• Nested structure depth is limited (e.g., maximum table nesting, list nesting) to prevent stack exhaustion
• Integrators can configure per-conversion timeouts and maximum input sizes

These limits exist in the implementation. They are not suggestions. They are enforced at the appropriate layer. The parser enforces nesting limits during processing. The converter tracks resource usage.

Resource limits protect against denial of service. A malicious user could upload a document designed to consume excessive memory or CPU. The limits prevent this. A document that exceeds limits fails fast with a clear error message. The server remains stable. Other requests are not affected.

The streaming architecture helps here. Because we process documents as streams rather than loading them whole, we can handle documents larger than available memory. But we still enforce limits. A document with a billion nested tables will hit the nesting limit and fail. This protects the stack and prevents infinite loops.

Every dependency is a potential attack surface. We minimize the dependency count deliberately. We audit dependencies with cargo-deny, checking for known security advisories. Dependencies from unknown registries or unverified git sources are blocked.

When a security advisory is published for a dependency we use, we update within 24 hours. Non-critical advisories are tracked and resolved in the next scheduled release.

The manifesto says: "Dependencies are not free. They are liabilities." This is especially true for security. Each dependency is code we did not write but must trust. We keep that trust surface small.

Our cargo-deny configuration:

• Blocks dependencies with known security advisories
• Blocks dependencies from unknown registries
• Blocks git dependencies that are not explicitly allowed
• Requires license verification for all dependencies

We review dependencies before adding them. We ask: what is the security track record? How quickly do they fix vulnerabilities? How many transitive dependencies do they bring? A dependency with 50 sub-dependencies is 50 times more attack surface. We avoid such dependencies when possible.

Vendoring is our friend. When a dependency is small and critical, we consider vendoring it. This means copying the code into our repository. We trade update convenience for control. We can review the code. We can fix issues ourselves. We are not dependent on upstream responsiveness.

If you find a security vulnerability, do not open a public issue. Contact the maintainers privately at security@docspec.dev.

We will work with you to understand the vulnerability, develop a fix, and coordinate disclosure. Our goal is to protect users while giving you credit for the discovery.

We commit to:

• Acknowledging receipt within 48 hours
• Providing a timeline for the fix within 7 days
• Keeping you informed of progress
• Coordinating disclosure when the fix is released

Public disclosure before a fix is available helps attackers, not users. Please give us time to do this right.

When you report a vulnerability, please include:

• A description of the vulnerability
• Steps to reproduce (if possible)
• The impact you believe it has
• Whether you have found it in the wild or through analysis

We appreciate security researchers. We will not take legal action against researchers who follow responsible disclosure. We will not blame you for finding our mistakes. We will thank you and fix the issue.

Security researchers who report valid vulnerabilities will be acknowledged in our release notes and security advisories, unless they prefer to remain anonymous. We believe in giving credit where credit is due.

Security in DocSpec is not a separate concern. It flows from our core values:

• Memory safety through Rust's type system
• Defensive parsing through fail-fast validation
• Least-privilege error handling through context-aware reporting
• Resource protection through enforced limits
• Supply chain security through minimal, audited dependencies

We build secure software by building correct software. The two are the same. Every principle in our manifesto — fail fast, no unsafe code, strict quality — contributes to security.

We do not claim to be perfect. Vulnerabilities may exist. When they are found, we fix them quickly. We learn from them. We improve.

This is our commitment to our users: we take security seriously. We design for it. We test for it. We respond to it. You can trust DocSpec with your documents because we have built it to be trustworthy.

• MANIFESTO.md — Our core philosophy and values
• ARCHITECTURE.md — Technical design and streaming pipeline
• CODING_STANDARDS.md — Code quality and review standards

These documents work together. The manifesto explains why we care about security. The architecture explains how we implement it. The standards explain how we maintain it.