Secure Development & Supply Chain
Security isn't only about how OWL runs — it's about how we build and deliver it. This page documents our secure-development and software-supply-chain practices, aligned with the NIST Secure Software Development Framework (SSDF, SP 800-218) and the secure-by-design and vulnerability-handling requirements of the EU Cyber Resilience Act.
1. Software Bill of Materials (SBOM)
We maintain a CycloneDX SBOM of OWL's third-party components and track it as part of each release, so we can identify and respond to vulnerabilities in dependencies. The SBOM is available to users on request via security@ndevr.org, and to market-surveillance authorities as part of the technical documentation.
2. Signed updates & download integrity
Software updates are protected end to end against tampering:
- Signed update manifests: the client verifies an Ed25519 signature on the update-check response using a public key pinned in the client. The signing private key is held operator-side and is never in our source.
- Download integrity: the signed manifest binds the SHA-256 hash of the installer. The client computes the hash of what it downloads and refuses a tampered download before it is written to disk.
Together these mean a network attacker cannot substitute a malicious update for a legitimate one.
3. Coordinated vulnerability disclosure
We run a published coordinated vulnerability disclosure program — see our disclosure policy and machine-readable security.txt — acknowledge reports within 3 business days, and publish security advisories with remediation when fixes ship. Vulnerability submissions and decisions are retained with our technical documentation.
4. Secure defaults & hardening
- Parameterized data access: database queries use prepared statements with bound parameters throughout, rather than string-built SQL.
- Secure transport by default: TLS is enforced and there is no anonymous access; the web client also sends a baseline of HTTP security response headers (HSTS, nosniff, frame and referrer policies).
- Minimal external surface: the web client makes no third-party network calls by default — no analytics, trackers, or third-party CDNs — so the only external contact is one you initiate (a connected cloud account or a payment). See the privacy policy and sub-processors.
5. Standards posture
These practices map to the NIST SSDF practice groups — Protect the Software (signed releases, integrity), Produce Well-Secured Software (secure defaults, dependency management), and Respond to Vulnerabilities (CVD, advisories, SBOM-driven response). We document alignment with these practices; we do not claim a third-party SSDF attestation.