We take security seriously. We appreciate your efforts to responsibly disclose vulnerabilities and will make every effort to acknowledge your contributions.
The preferred method for reporting security vulnerabilities is through GitHub’s Security Advisory feature:
-
Navigate to Report a Vulnerability
-
Click “Report a vulnerability”
-
Complete the form with as much detail as possible
-
Submit — we’ll receive a private notification
This method ensures:
-
A private advisory workspace hosted by GitHub (not end-to-end encrypted)
-
Private discussion space for collaboration
-
Coordinated disclosure tooling
-
Automatic credit when the advisory is published
If you cannot use GitHub Security Advisories, you may email us directly:
Important: Do not report security vulnerabilities through public GitHub issues, pull requests, discussions, or social media.
A good vulnerability report helps us understand and reproduce the issue quickly.
-
Description: Clear explanation of the vulnerability
-
Impact: What an attacker could achieve (confidentiality, integrity, availability)
-
Affected versions: Which versions/commits are affected
-
Reproduction steps: Detailed steps to reproduce the issue
-
Proof of concept: Code, scripts, or screenshots demonstrating the vulnerability
-
Attack scenario: Realistic attack scenario showing exploitability
-
CVSS score: Your assessment of severity (use CVSS 3.1 Calculator)
-
CWE ID: Common Weakness Enumeration identifier if known
-
Suggested fix: If you have ideas for remediation
-
References: Links to related vulnerabilities, research, or advisories
We commit to the following response times:
| Stage | Timeframe | Description |
|---|---|---|
Initial Response |
48 hours |
We acknowledge receipt and confirm we’re investigating |
Triage |
7 days |
We assess severity, confirm the vulnerability, and estimate timeline |
Status Update |
Every 7 days |
Regular updates on remediation progress |
Resolution |
90 days |
Target for fix development and release (complex issues may take longer) |
Disclosure |
90 days |
Public disclosure after fix is available (coordinated with you) |
Note: These are targets, not guarantees. Complex vulnerabilities may require more time. We’ll communicate openly about any delays.
We follow coordinated disclosure (also known as responsible disclosure):
-
You report the vulnerability privately
-
We acknowledge and begin investigation
-
We develop a fix and prepare a release
-
We coordinate disclosure timing with you
-
We publish security advisory and fix simultaneously
-
You may publish your research after disclosure
-
We will not take legal action against researchers who follow this policy
-
We will work with you to understand and resolve the issue
-
We will credit you in the security advisory (unless you prefer anonymity)
-
We will notify you before public disclosure
-
We will publish advisories with sufficient detail for users to assess risk
-
Report vulnerabilities promptly after discovery
-
Give us reasonable time to address the issue before disclosure
-
Do not access, modify, or delete data beyond what’s necessary to demonstrate the vulnerability
-
Do not degrade service availability (no DoS testing on production)
-
Do not share vulnerability details with others until coordinated disclosure
The following are within scope for security research:
-
This repository (
hyperpolymath/docudactyl) and all its code -
The Zig FFI layer (
ffi/zig/) — memory safety, buffer handling, null-pointer dereferences -
The C ABI boundary — struct layout correctness, pointer handling
-
Chapel HPC orchestration — fault isolation, input validation
-
Container images built from
deploy/Containerfile -
Official releases and packages published from this repository
-
Dependencies (report here, we’ll coordinate with upstream)
The following are not in scope:
-
Third-party C libraries (Poppler, Tesseract, FFmpeg, etc.) — report directly to them
-
Social engineering attacks against maintainers
-
Physical security
-
Denial of service attacks against production infrastructure
-
Issues already reported or publicly known
-
Theoretical vulnerabilities without proof of concept
We’re particularly interested in:
-
Memory safety issues in the Zig FFI layer (buffer overflows, use-after-free, etc.)
-
ABI mismatches between Idris2 proofs and actual struct layouts
-
Command injection via manifest file paths or configuration
-
Unsafe dlopen/dlsym handling (ONNX Runtime, PaddleOCR, CUDA)
-
Path traversal in document output paths
-
Information disclosure through error messages
-
Cryptographic weaknesses in SHA-256 hardware acceleration paths
We support security research conducted in good faith.
If you conduct security research in accordance with this policy:
-
We will not initiate legal action against you
-
We will not report your activity to law enforcement
-
We will work with you in good faith to resolve issues
-
We consider your research authorised under the Computer Fraud and Abuse Act (CFAA), UK Computer Misuse Act, and similar laws
-
We waive any potential claim against you for circumvention of security controls
Researchers who report valid vulnerabilities will be acknowledged in our security advisories (unless they prefer anonymity).
To stay informed about security updates:
-
Watch this repository: Click “Watch” → “Custom” → Select “Security alerts”
-
GitHub Security Advisories: Published at Security Advisories
When using Docudactyl, we recommend:
-
Keep dependencies up to date
-
Use the latest stable release
-
Validate manifest files before processing untrusted inputs
-
Run in containers with minimal privileges
-
Review Slurm job scripts before submission
-
Never commit secrets, credentials, or API keys
-
No
@panicin Zig release builds — return error codes via C ABI -
No
believe_me,assert_total, orAdmittedin Idris2 proofs -
No
unsafeblocks in Zig without documented safety justification -
Review dependencies before adding them
-
Run
just test-hpcbefore pushing
| Purpose | Contact |
|---|---|
Security issues |
|
General questions |
Thank you for helping keep Docudactyl and its users safe.
Last updated: 2026 | Policy version: 1.0.0