Draft. This document is an operational placeholder pending counsel review. It is published so users and regulators can see the structure of our data-protection and contractual commitments; the finalised wording will be issued before any production-grade rollout.

Security Artefacts

Version 0.2-draft · Effective 2026-08-08

Regulation (EU) 2024/2847 (the Cyber Resilience Act) expects manufacturers of products with digital elements to be able to hand competent authorities a clear trail of how the product was built, what it depends on, and how its security posture evolves. This page names the artefacts DefenceOS produces, how they are generated, and how to request them. DefenceOS ships as two container images — a frontend SSR image (defenceos-pilot) and the backend MTT engine (skansar-engine). Each artefact below is produced separately for each repository; scope is called out where it differs.

Software Bill of Materials (SBOM)

Every production build produces two SBOMs:

Dependency-graph SBOM (CycloneDX 1.6 JSON): lists every production dependency, its resolved version, and its licence. Emitted by cyclonedx-npm on the frontend and by the CycloneDX Maven plugin on the engine. Development-only dependencies are excluded, so the document represents what actually runs.
Image SBOM (attached to the OCI manifest): BuildKit produces a CycloneDX SBOM as part of docker buildx build (sbom: true) and attaches it to the ECR image manifest as an attestation. Retrievable via docker buildx imagetools inspect or cosign download attestation.
Validation: the CycloneDX generator runs with --validate so a build whose SBOM does not match the schema fails fast.
Retention: each build's SBOM is kept as a build artefact and, via the image-manifest attestation, is discoverable from the ECR image itself.

Build provenance (SLSA)

Every production image is built with provenance: mode=max in docker/build-push-action. The generated in-toto attestation records the source repository and commit, the workflow file and ref that ran, the build materials (with their digests), and the build environment. The attestation is attached to the ECR image manifest, verifiable via cosign verify-attestation.

Image signing (Sigstore cosign)

Every production image pushed to ECR is signed by the deploy workflow using cosign keyless mode. The workflow requests an ephemeral certificate from Sigstore's Fulcio, bound to the workflow's OIDC identity (repository, workflow, and ref), and logs the signature to the Rekor transparency log. Verifiers use cosign verify with the same OIDC identity claims — a signature by any other identity, or an image not signed at all, is detectable. No signing key is stored in AWS, GitHub, or the repository.

Dependency-vulnerability gate

Every CI run executes scripts/audit-check.mjs, which runs npm audit --json --omit=dev and fails on any high- or critical-severity finding that is not documented in .audit-allowlist.json. Every allowlist entry must carry a written rationale, a link to the issue tracking the follow-up, and a review-by date; expired entries also fail the gate. Osv-Scanner and Trivy run alongside as second-opinion scanners.

Supporting artefacts

Vulnerability disclosure: see security.txt (RFC 9116) for how to report a vulnerability; coordinated disclosure is our preferred path. Reports go to security@skansar.com.
Security hardening log: the repository's docs/SECURITY.md tracks every hardening pass, including transport headers, supply-chain upgrades, CSP posture, and build-time guardrails.
Compliance log: docs/COMPLIANCE.md tracks the regulatory-compliance posture across GDPR, ePrivacy, WCAG / EAA, AI Act, dual-use, and NIS2.
Deployment-security review: docs/DEPLOYMENT_SECURITY_REVIEW.md tracks the infrastructure hardening passes (topology, ingress, secrets, runner) separately from application-layer work.

Requesting artefacts

Competent authorities, customers under NDA, and security researchers can request the current-release SBOM, build provenance, or supporting artefacts by emailing security@skansar.com. Requests are handled within five (5) business days. Include the version and build date you are asking about — both are visible in the DefenceOS footer and on each release tag.

Changes

2026-08-08 (v0.2-draft) — documented the two-SBOM setup (dependency-graph + image-attestation), added the SLSA build-provenance (mode=max) and cosign keyless-signing sections, and rewrote the dependency-vulnerability gate description to reflect the current audit-check.mjs plus .audit-allowlist.json mechanism (which replaced the earlier raw npm audit --audit-level=high gate). Broadened scope to both repositories.
2026-04-22 (v0.1-draft) — initial description.