Supply Chain Security

• Last Updated: 28 Feb 2026
• Next Review: 1 Jul 2026

---

This document describes how Enprivacy manages supply chain security for our self-hosted software products. We take a defence-in-depth approach to securing the components, dependencies, and build processes that make up our software so that customers deploying in their own environments can have confidence in what they are running.

Software Bill of Materials (SBOM)

We produce and maintain a Software Bill of Materials for every release of Invisiq. The SBOM enumerates all first-party code, open-source dependencies, and third-party libraries included in each release artefact.

Format: We publish SBOMs in CycloneDX format.

Availability: SBOMs are available to customers on request and are attached to each release in our GitHub Container Registry.

Scope: The SBOM covers all components in the container images, binaries, and dependencies shipped in each release.

Dependency Management

Open Source Dependencies

• All dependencies are declared explicitly in their respective package definition files and locked to specific versions via the package manager’s lock file, such as but not limited to the following:
  • JavaScript / Typescript: package.json;
  • Ruby: Gemfile; and
  • Python: requirements.txt.
• We use Dependabot to monitor dependencies for newly published CVEs continuously.
• Critical and high-severity vulnerabilities are triaged within 3 business days and remediated within 14 business days.
• We do not vendor unmodified copies of dependencies without a documented rationale.

Dependency Pinning

All dependencies in our build pipeline — including base container images, build tools, and third-party actions — are pinned to:

• A specific version tag, and
• A cryptographic digest (SHA-256) where the upstream registry supports it.

This prevents unexpected changes to our build inputs even if an upstream tag is mutated.

Secure Build Pipeline

Build Environment

• Builds run in isolated, ephemeral CI environments (GitHub Actions).
• Build runners do not have persistent access to production systems.
• Build secrets (signing keys, registry credentials) are stored in GitHub Secrets and are injected at build time with least-privilege access.

Reproducible Builds

Where technically feasible, our builds are designed to be reproducible: the same source inputs produce bit-identical output artefacts. Reproducibility status is noted in our release notes.

Artefact Signing

All release artefacts (container images, binaries, Helm charts, checksums) are signed using Cosign.

Verification: Customers can verify the signature of any artefact before deploying. Instructions are provided in our Deployment Guide.

Public key / certificate: Public key to be provided.

Container Image Security

• Base images are sourced from official upstream images.
• Images are scanned for vulnerabilities on every build using Trivy.
• We follow a minimal-image philosophy: only components required at runtime are included.
• Images run as non-root by default. The UID used is documented in our Deployment Guide.
• We publish an updated image with patched base layers within 3 business days of a critical OS-level CVE being published.

Source Code Security

• All source code is hosted in GitHub with access controls enforced via SSO and MFA.
• Branch protection rules require at least 1 approving reviews before merging to the default branch.
• No force-pushes are permitted on protected branches.
• Automated SAST (static analysis) runs on every pull request via CodeQL.
• Secret scanning is enabled across all repositories to detect accidental credential commits.

Release Process

1. Changelog and versioning — Releases follow semantic versioning. A changelog is published for every release.
2. Security review — Changes that touch authentication, authorisation, cryptography, or external inputs are subject to mandatory security review before merging.
3. Release signing — Release artefacts are signed (see Artefact Signing above).
4. CVE tracking — We maintain a private CVE Database available for clients where known vulnerabilities in released versions are disclosed.

Third-Party Audits and Penetration Testing

Assessment type	Frequency	Scope	Last completed	Report available
Penetration test	Annual	Focused on frontend interface and backend services	Not yet started	On request with NDA
SAST / DAST review	Per release	Full codebase	Continuous	Summary on request with NDA
Dependency audit	Continuous	All dependencies	Continuous	Via SBOM

Customer Verification Capabilities

Because Invisiq is deployed in your environment, you can independently verify the integrity of what you are running:

• Signature verification — Verify container image and binary signatures before deployment using instructions in our Deployment Guide.
• Checksum verification — SHA-256 checksums are published for all release artefacts at our GitHub Container Registry.
• SBOM inspection — The SBOM for your installed version can be imported into your preferred software composition analysis tooling.
• Network egress — The product is designed to operate fully air-gapped with the sole exception of the user management and entitlement server. No customer data is transmitted back to Enprivacy. See our Data Flow Guide documentation.

Contact

To report a suspected vulnerability or ask questions about supply chain security:

• Security email: security@enprivacy.com
• PGP key: (Public Key to be provided)
• Response SLA: We acknowledge all reports within 3 business days.