Construction Constitution

Version: 0.1

This document contains the universal requirements of SCF. A product profile MAY make a requirement stricter, but MUST NOT weaken it without a registered exception and a risk assessment.

Normative words: MUST / MUST NOT state a requirement for SCF conformance; SHOULD / SHOULD NOT state the expected decision unless evidence justifies a registered exception; MAY states a permitted choice subordinate to stronger requirements.

Requirements are grouped by subject. Identifiers are stable and language-independent. A requirement that cannot be verified is incomplete. Evaluation and conformance defines the evidence levels, the baseline verification corpus and the release gate; where it does not yet name a method for a requirement, the product MUST supply one in its own verification corpus before claiming that requirement met.

1. Product and governance — SCF-GOV

SCF-GOV-001. Product definition

A system MUST be defined as a product with a stated purpose, an intended deployment context, a threat model, a support period, a data policy and an accountable owner. An image without these is a build artefact, not a system, and MUST NOT be presented as a released system.

SCF-GOV-002. Declared scope of responsibility

The producer MUST state which components it takes responsibility for, which it consumes from upstream, and which it explicitly excludes. The statement MUST be available to the recipient before installation.

SCF-GOV-003. Threat model

Every system MUST have a written threat model naming the assets, the adversary capabilities in scope, the trust boundaries and the risks accepted out of scope. Security requirements MUST be traceable to it.

SCF-GOV-004. Support period declared before acquisition

The end of the support period MUST be stated to at least month-and-year precision, and MUST be available at the moment the system is obtained, not only after installation.

SCF-GOV-005. Secure by default, not by configuration

The default configuration MUST be the secure configuration. A hardening guide MUST NOT be the mechanism by which a system meets its own security claims.

SCF-GOV-006. No claim without evidence

A published claim about security, privacy, compliance, reproducibility or certification MUST be bounded to the tested scope and supported by retained evidence. Marketing wording MUST NOT exceed the evidence.

SCF-GOV-007. Accountable exceptions

Every deviation from this Constitution MUST be registered with scope, reason, affected users, risk, mitigation, owner and review date. An expired exception blocks a new conformance statement until reviewed.

SCF-GOV-008. Jurisdiction and data residency

The product MUST declare the jurisdictions it is intended to be placed on the market in, the regulatory regimes that follow from that, and where the data it generates or transmits is expected to reside. A profile MAY make residency a hard constraint verified at build time.

2. Specification — SCF-SPC

SCF-SPC-001. Declarative specification

A system MUST be described by a declarative specification that is complete enough to construct it. Completeness is demonstrated by SCF-REP-001: if the system cannot be rebuilt from its specification and lock alone, the specification is incomplete.

SCF-SPC-002. Canonical form and stable identity

The specification MUST have a canonical serialisation, and its identity MUST be derived from that serialisation by a cryptographic digest. Two specifications with the same identity MUST describe the same system.

SCF-SPC-003. No hidden inputs

Anything that can change the output MUST appear in the specification or in the lock derived from it: sources, versions, architecture, locale, timestamps, trust anchors and verification keys, overlays, hooks and engine versions. Ambient host state MUST NOT influence the result. Signing keys are not inputs and MUST NOT appear (SCF-CRY-003).

SCF-SPC-004. Layered composition with visible precedence

Where a specification is composed from a base and overrides, the precedence order MUST be defined and the effective result MUST be inspectable before a build starts.

SCF-SPC-005. Validated input

Every field of a specification MUST be validated against a published schema with explicit types, ranges and permitted values. Free text MUST NOT reach a shell, a package resolver or a filesystem path without validation.

SCF-SPC-006. Portability of intent

A specification SHOULD express intent — "a hardened server with these services" — separately from platform mechanics. Where intent cannot be expressed portably, the platform-specific part MUST be explicitly marked.

SCF-SPC-007. Export without lock-in

The producer MUST be able to export the canonical specification and the resolved lock in a documented format, and a recipient MUST be able to rebuild from them without the original service.

3. Sources and provenance — SCF-SRC

SCF-SRC-001. Named upstream

Every input MUST have a named origin recorded in the lock: project, archive, suite, component, version and cryptographic digest.

SCF-SRC-002. Authenticated acquisition

Every input MUST be authenticated by a signature or a digest anchored in a key the producer has deliberately trusted. Transport security MUST NOT be the only integrity mechanism.

SCF-SRC-003. Explicit trust anchors

Trust anchors MUST be enumerated, stored as files under producer control, and scoped to the sources they authenticate. Global or implicit trust of all configured keys MUST NOT be used.

SCF-SRC-004. Pinned archive state

A release build MUST resolve against a pinned archive state — a snapshot, an immutable index, a commit or a full digest list — so that the same lock yields the same inputs later. Where a platform provides no archive service, the producer MUST maintain its own immutable snapshot of the inputs it consumed.

SCF-SRC-005. Retention for the support period

The exact inputs of a release, or an immutable reference that resolves them, MUST remain available for at least the support period, and for as long as any licence or regulatory obligation requires.

SCF-SRC-006. Due diligence on third-party and open-source components

The producer MUST assess the components it integrates, including components it did not pay for, for maintenance status, known vulnerabilities, licence terms and provenance. Absence of a commercial relationship does not remove the duty. The assessment MUST be recorded per component with its source, its outcome and its date.

SCF-SRC-007. Upstream fix duty

When the producer finds a vulnerability in a component it did not write, it SHOULD report it to the upstream maintainer and, where it has produced one, share the fix in a form the maintainer can use.

4. Build execution — SCF-BLD

SCF-BLD-001. Code executed during a build is untrusted

Maintainer scripts, hooks, build systems and the kernel of the build environment MUST be treated as untrusted code. The isolation boundary of SCF-BLD-002 MUST hold under a test that executes arbitrary code inside it. Running a build tool as a non-privileged user MUST NOT be relied on as the boundary.

SCF-BLD-002. Isolation boundary

A build MUST execute inside an isolation boundary that survives arbitrary code execution within it. For multi-tenant or third-party specifications the boundary MUST be a virtual machine with its own kernel, created for the build and destroyed after it.

SCF-BLD-003. No shared build state

A build MUST NOT inherit mutable state from a previous build or from another tenant. Caches MAY be shared only if content-addressed and read-only to the build.

SCF-BLD-004. Controlled network

A build MUST run without network access, or with egress restricted to an explicit allowlist of producer-controlled mirrors. Metadata services of the hosting environment MUST be unreachable from the build.

SCF-BLD-005. Safe artefact extraction

Build outputs MUST be extracted in a way that does not require the host to parse or mount a filesystem produced inside the build.

SCF-BLD-006. Bounded resources

Every build MUST have enforced limits on CPU, memory, process count, disk and wall-clock time, and MUST fail deterministically when a limit is reached rather than degrading the host.

SCF-BLD-007. Least privilege inside the boundary

Within the isolation boundary, stages that do not require privilege MUST NOT run with it. Where a platform allows unprivileged construction of root filesystems and images, the unprivileged path SHOULD be preferred.

SCF-BLD-008. Complete, attributable log

Every build MUST produce a log that identifies the lock, the engine and its version, every resolved input, every stage, its result and its duration. The log MUST be retained with the release.

SCF-BLD-009. The construction platform is in scope

The build engines, adapters, worker base images and container images used to construct a system are inputs to it, and MUST be subject to the same requirements on origin, authentication, pinning and retention as any other input.

5. Reproducibility — SCF-REP

SCF-REP-001. Rebuildable from lock

Every release MUST be rebuildable from its lock alone, on a clean environment, for at least the support period.

SCF-REP-002. Honest reproducibility claim

A bit-for-bit claim MUST be bounded to the profile, platform and architecture where it has been demonstrated by an independent rebuild. Where inputs are not reproducible, the honest claim is "rebuildable from lock", and the difference MUST be stated.

SCF-REP-003. Determinism controls

Where the platform supports them, builds MUST set a deterministic build timestamp, normalise file ownership, permissions and ordering, and remove non-deterministic caches generated during installation.

SCF-REP-004. Rebuild verification in the pipeline

At least one reference profile per platform family MUST be rebuilt independently and compared, and the comparison MUST be part of the release evidence.

6. Artefacts and attestation — SCF-ART

SCF-ART-001. Manifest

Every release MUST carry a manifest that names the specification identity, the lock identity, the engine, the build environment, every artefact with its digest and role, and the date.

SCF-ART-002. Machine-readable bill of materials

Every release MUST include a bill of materials in a widely used machine- readable format, covering every component present in the delivered artefact, with component identity, version, digest, licence and supplier. Where a regulatory regime sets a lower minimum, the higher requirement applies.

SCF-ART-003. Provenance attestation

Every release MUST carry a signed provenance attestation describing the build platform, the lock and the inputs. It MUST be generated by the control plane from the build record rather than asserted by a human, and MUST NOT be generated inside the build environment.

SCF-ART-004. Signed artefacts and digests

Every distributed artefact MUST be covered by a producer signature over its digest. Digest files MUST themselves be signed, and the verification key fingerprint MUST be published through an independent channel.

SCF-ART-005. Immutable releases

A release MUST be immutable. A correction is a new release. Channels are movable pointers to releases; releases are not movable.

SCF-ART-006. Verification instructions travel with the artefact

Instructions to verify a signature and a digest MUST be published together with the download, in a form a recipient can follow without contacting the producer.

SCF-ART-007. Source availability of the release

The release delivery surface MUST satisfy SCF-LGL-003: where a licence requires corresponding source, it is obtainable from the same place as the binary, for the period the licence requires.

7. Boot integrity — SCF-BOOT

SCF-BOOT-001. Declared boot trust model

Every system MUST declare its boot trust model: which components are signed, by whom, which keys the firmware must trust, and what the system does when verification fails.

SCF-BOOT-002. Honest Secure Boot status

A system MUST state whether it boots with firmware verification enabled in its default configuration. A system that requires the user to disable firmware verification MUST say so before installation, and MUST NOT describe itself as secure-boot capable.

SCF-BOOT-003. Do not break an inherited chain

Where a system inherits a signed boot chain from an upstream distribution, it MUST NOT replace or rebuild a component of that chain unless it can sign the replacement with a key the chain trusts. Where a component is replaced, the system MUST declare that the inherited chain no longer applies.

SCF-BOOT-004. Revocation currency

Boot components MUST NOT be shipped at a generation that current revocation policy rejects. Revocation metadata MUST be checked automatically before each release, and the check MUST be part of the release gate.

SCF-BOOT-005. Signing-authority dependencies are product risks

Dependence on an external signing authority — its certificate validity, its review process and its timelines — MUST be recorded as a product risk with a named contingency. A product plan MUST NOT assume that a signing request will be granted.

SCF-BOOT-006. Measurement where the platform supports it

Where the platform provides a measurement facility, the boot chain SHOULD be measured, the measured values SHOULD be documented, and anything sealed against those values MUST have a documented recovery path for when they legitimately change.

SCF-BOOT-007. Verified system volume for immutable profiles

A system that presents itself as immutable MUST verify the integrity of its system volume at run time, and the verification root MUST be anchored in the boot chain rather than in the volume itself.

SCF-BOOT-008. Anti-rollback

Where the update mechanism supports it, the system MUST refuse to boot a version below a recorded minimum, and the minimum MUST advance only through a controlled process.

8. Cryptography and keys — SCF-CRY

SCF-CRY-001. Written algorithm policy

The system MUST have a written algorithm policy naming permitted algorithms, key sizes and protocol versions for each purpose, with a review date. Defaults MUST comply with it.

SCF-CRY-002. No deprecated primitives in trust decisions

Deprecated hash and signature primitives MUST NOT be used in any decision that grants trust: archive signatures, artefact signatures, update verification or authentication.

SCF-CRY-003. Key custody

Every signing key MUST have a documented custodian, a storage medium, an access-control procedure and an audit trail. Release signing keys MUST NOT be present on build workers or in a build environment.

SCF-CRY-004. Separate keys for separate purposes

Archive signing, artefact signing, boot-component signing, module signing and transport identity MUST use distinct keys with distinct lifetimes.

SCF-CRY-005. Designed rotation and revocation

Key rotation and revocation MUST be designed before first use, including how existing installations learn the new key and what happens to artefacts signed with the old one.

SCF-CRY-006. Randomness at first boot

The system MUST establish a properly seeded random source before generating any long-lived secret. Secrets that must be unique per installation are governed by SCF-IDN-001.

SCF-CRY-007. Cryptographic claims are bounded

A claim of compliance with a cryptographic validation scheme MUST name the validated module, its certificate and its version. A system that merely uses a library from a validated project MUST NOT claim the validation.

9. Isolation and attack surface — SCF-ISO

SCF-ISO-001. Minimal installed surface

A system MUST install only what its stated purpose requires. Components present "in case they are needed" are attack surface and MUST be justified in the profile.

SCF-ISO-002. No listening services by default

After first boot and before an administrator acts, the system MUST NOT expose a network-listening service that its profile does not require. Every exposed service MUST be enumerated in the release documentation.

SCF-ISO-003. Mandatory access control enforced

Where the platform provides a mandatory access control or capability confinement facility, it MUST be enabled and enforcing in the default configuration, with no unresolved denials in the first-boot path.

SCF-ISO-004. Service confinement

Services reachable from the network or processing untrusted input MUST run with reduced privileges, a restricted filesystem view and a restricted system-call surface, using the mechanisms the platform provides.

SCF-ISO-005. Kernel hardening baseline

The kernel configuration and boot parameters MUST meet a stated hardening baseline, and the baseline MUST be verified mechanically against the shipped configuration rather than assumed from the upstream default.

SCF-ISO-006. Unsigned code does not enter the kernel

Loadable kernel code MUST be signed by a key the running kernel trusts. Where the profile permits third-party modules, the enrolment procedure MUST be documented, including its manual steps and their consequences.

SCF-ISO-007. Enumerated privilege escalation paths

The mechanisms by which an unprivileged user can obtain administrative privilege MUST be enumerated, justified and configured explicitly. The enumeration MUST cover at least set-user-identity and set-group-identity executables, file capabilities, the privilege-escalation policy, the authorisation framework, privileged system-bus services and installer helpers.

SCF-ISO-008. Isolation defaults are not weakened for convenience

A default that disables a platform isolation facility to make an application work MUST be registered as an exception under SCF-GOV-007 and MUST NOT be applied silently.

SCF-ISO-009. Virtualisation host defaults

Where the system can host virtual machines, the exposed device model, device pass-through, nested virtualisation and guest agents MUST be treated as attack surface: disabled by default unless the profile requires them, and enumerated when enabled.

SCF-ISO-010. Container runtime defaults

Where the system ships a container runtime, it MUST default to unprivileged operation, MUST NOT expose a privileged control socket to unprivileged users, and MUST verify signatures of images it pulls according to a documented trust policy.

10. Identity and credentials — SCF-IDN

SCF-IDN-001. No shipped credentials

An image MUST NOT contain a default password, a default private key, a default API token or any other pre-set credential shared between installations.

SCF-IDN-002. Credential quality and lockout

The default authentication configuration MUST use a current password-hashing scheme and MUST resist online guessing through rate limiting or lockout.

SCF-IDN-003. Automatic login is a declared exception

Automatic login and passwordless administrative access MUST be off by default. Where a profile requires them, they MUST be declared, scoped and paired with a compensating control.

SCF-IDN-004. Strong authentication is supported

The system SHOULD support hardware-backed authenticators for interactive login and for privilege escalation, and MUST document how to enable them.

SCF-IDN-005. Administrative actions are attributable

Administrative actions MUST be attributable to an identity, and the attribution MUST survive privilege escalation.

SCF-IDN-006. Declared network and directory authentication

The system MUST declare which network authentication and directory integration mechanisms it supports, and MUST NOT enable any of them by default without a configured trust anchor.

SCF-IDN-007. Isolation between local accounts

Local accounts MUST be isolated from one another by default: home directories are not readable across accounts, and per-account resource limits are available where the profile requires them.

11. Data protection — SCF-DAT

SCF-DAT-001. Data inventory

The producer MUST know and document what categories of data the system stores, processes and transmits by default, and where each is written.

SCF-DAT-002. Encryption at rest is available and prominent

The system MUST support full-disk or equivalent encryption of user data. Where the product delivers an installer, encryption MUST be offered there as a first-class choice rather than an advanced option; where the product is image-first, the equivalent provisioning surface MUST offer it.

SCF-DAT-003. Sound encryption defaults

Where encryption is enabled, the default parameters MUST meet the algorithm policy, and any binding of a key to platform state MUST be bound to a meaningful state, not to an empty policy.

SCF-DAT-004. Encryption in transit

Data leaving the system MUST be protected in transit using current protocol versions, with certificate validation enabled and no silent downgrade.

SCF-DAT-005. Integrity reporting

The system MUST be able to detect and report corruption or unauthorised modification of data, commands, programs and configuration that it is responsible for.

SCF-DAT-006. Erasure and reset

The system MUST provide a documented way to erase all user data and configuration and to return to its as-delivered state, and MUST state what the procedure does not erase.

SCF-DAT-007. Consistency and repair

The default storage configuration MUST survive sudden power loss without corrupting the system volume, and the system MUST provide a documented way to check and repair its filesystems from the recovery path.

SCF-DAT-008. Backup and restore

The system MUST document how the data it holds can be backed up and restored, including what a restore does not recover. A profile MAY require the mechanism to be shipped and enabled rather than only documented.

12. Privacy and telemetry — SCF-PRV

SCF-PRV-001. Network silence by default

After installation and before the user acts, the system MUST NOT contact any network endpoint other than those strictly required for its stated function. Every such endpoint MUST be listed in the release documentation.

SCF-PRV-002. Telemetry is opt-in

Collection of usage, diagnostic or measurement data MUST be off until the user or the operator turns it on, through a surface that states what is collected, why, where it goes and for how long it is kept.

SCF-PRV-003. No stable device identifier without necessity

The system MUST NOT transmit a stable identifier that links separate observations to the same installation unless the stated purpose requires it and the user has been informed.

SCF-PRV-004. Minimisation

Data that is not necessary for the stated purpose MUST NOT be collected, and collected data MUST be retained only for as long as that purpose requires.

SCF-PRV-005. Crash and diagnostic reports are consented per event

A report that may contain user content MUST be reviewable and MUST require an explicit decision, either per event or through a clearly stated standing choice that can be withdrawn.

SCF-PRV-006. Behavioural logging can be turned off

Where the system monitors or logs behavioural, usage or diagnostic activity, the user or operator MUST be able to turn it off, and the consequences MUST be stated. This does not extend to the records required by SCF-IDN-005, SCF-OPS-002 and SCF-OPS-006, which a profile MAY make mandatory.

13. Network and time — SCF-NET

SCF-NET-001. Default-deny ingress

A host firewall MUST be active in the default configuration with a default-deny policy for inbound traffic, and every opened port MUST be justified by the profile.

SCF-NET-002. Name resolution integrity

The default resolver configuration MUST be documented, and the system SHOULD protect name resolution against passive observation and tampering. A decision not to do so MUST be explicit.

SCF-NET-003. Authenticated time

Time synchronisation SHOULD be authenticated. Where the shipped client cannot authenticate, this MUST be recorded as a known limitation, because certificate validation, update freshness and log integrity depend on time.

SCF-NET-004. No unsolicited discovery

Discovery, announcement and pairing protocols MUST be off by default unless the profile requires them.

SCF-NET-005. Link-layer privacy

On profiles with wireless interfaces, address randomisation SHOULD be enabled for scanning and for association, and the shipped default MUST be documented.

SCF-NET-006. Declared enterprise network support

The system MUST declare which managed-network mechanisms it supports — port-based authentication, proxies, virtual private networks and certificate enrolment — and none of them may be enabled by default without configuration.

14. Update and rollback — SCF-UPD

SCF-UPD-001. An update mechanism exists and is named

Every system MUST ship with a defined mechanism to receive security updates, and the mechanism MUST be part of the product definition rather than an afterthought.

SCF-UPD-002. Security updates are automatic by default

Security updates MUST be applied automatically in the default configuration. The user or operator MUST be able to postpone them through a clearly described control, and the consequences MUST be stated. A configuration that disables security updates entirely MAY be offered; where a profile permits it, it MUST be registered under SCF-GOV-007 and MUST NOT be the default.

SCF-UPD-003. Security updates are separable

Security fixes MUST be deliverable without forcing unrelated functional change.

SCF-UPD-004. Verified before applied

An update MUST be verified against a trusted key before it is applied. Verification MUST NOT be disabled by default anywhere in the delivery path.

SCF-UPD-005. Interruption safety

An interrupted update MUST leave a bootable system. Where the platform allows it, updates SHOULD be atomic with an explicit activation step.

SCF-UPD-006. Rollback is designed and tested

The system MUST provide a documented way to return to the previous known-good state, and the procedure MUST be tested for every release, not only described.

SCF-UPD-007. Update availability outlives the release

Every security update MUST remain obtainable for the period the product policy and applicable regulation require, independently of whether the release is still current.

SCF-UPD-008. Offline and constrained updates

Profiles that operate without continuous connectivity MUST have a documented offline update path with the same verification guarantees as the online one.

SCF-UPD-009. Bounded activation attempts

Where the platform supports staged activation, a newly activated version MUST be subject to a bounded number of boot attempts, after which the system automatically returns to the previous known-good state without human intervention.

15. Vulnerability handling — SCF-VUL

SCF-VUL-001. A published way to report

The producer MUST publish a contact point for vulnerability reports and a coordinated disclosure policy stating expected response times and the disclosure process.

SCF-VUL-002. Defined handling process

Reports MUST enter a defined process with intake, triage, severity assessment, remediation, verification and publication, with an owner at each step.

SCF-VUL-003. Known exploited vulnerabilities block release

A release MUST NOT ship with a known-exploited vulnerability in a component it delivers, unless the exposure is eliminated by configuration and that reasoning is recorded. A release SHOULD NOT ship with a known exploitable vulnerability; where it does, the residual risk MUST be recorded and, where the recipient can act on it, published under SCF-VUL-004.

SCF-VUL-004. Exploitability statements are machine-readable

Where a scanner finding is not exploitable in the delivered configuration, the producer SHOULD publish a machine-readable exploitability statement rather than leaving the recipient to guess.

SCF-VUL-005. Advisories accompany fixes

A security update MUST be accompanied by an advisory identifying the affected versions, the impact, the fixed version and any required user action.

SCF-VUL-006. Reporting duties are operationalised

Where regulation imposes deadlines for reporting actively exploited vulnerabilities or severe incidents, the producer MUST maintain the capability to meet them: an identified reporting endpoint, a duty roster, templates and a rehearsed procedure.

16. Observability, diagnostics and recovery — SCF-OPS

SCF-OPS-001. The system explains its own state

An administrator MUST be able to determine, from the running system, its version, its channel, its update status, its boot integrity state and its active security policies.

SCF-OPS-002. Logs are useful and bounded

The default logging configuration MUST record security-relevant events, MUST have bounded retention and size, and MUST NOT record secrets or unnecessary personal data.

SCF-OPS-003. Recovery path exists and is reachable

Every system MUST have a documented recovery path that works when the primary system does not boot, and the path MUST be reachable without network access.

SCF-OPS-004. Failure is legible

Boot, update and integrity failures MUST produce a message that identifies what failed and what the operator can do, rather than a bare error code or a silent loop.

SCF-OPS-005. Diagnostic and service modes

A diagnostic, service or manufacturing mode MUST NOT bypass authentication, encryption or verification in a shipped system, and MUST NOT be enabled by default.

SCF-OPS-006. Tamper-evident audit record

Where a profile requires records to be retained for an operator, a regulator or an investigation, the record MUST be append-only from the perspective of the running system, MUST be exportable, and its integrity MUST be verifiable.

SCF-OPS-007. Power-loss resilience

The system MUST reach a consistent, bootable state after a sudden loss of power at any point of normal operation, not only during an update.

17. Hardware and firmware — SCF-HWE

SCF-HWE-001. Declared hardware matrix

The producer MUST publish the architectures, platforms and reference devices the system is supported on, and MUST distinguish supported, tested and untested.

SCF-HWE-002. Non-free firmware is declared

Where the system includes firmware or drivers under non-free terms, the terms MUST permit the intended redistribution, the licence text MUST travel with the image, and the component MUST NOT be modified where the licence forbids it.

SCF-HWE-003. Firmware updates are addressed

The producer MUST state whether the system can deliver device-firmware updates, and where it cannot, MUST say so.

SCF-HWE-004. Cross-architecture builds are verified natively

An artefact for an architecture other than the build host's MUST be verified by booting on that architecture: in emulation for any release, and on reference hardware before a general-availability release.

SCF-HWE-005. Power management and suspend

The system MUST document its supported sleep and hibernation states per reference device, MUST require authentication on resume by default, and MUST state what happens to storage-encryption keys in each state.

SCF-HWE-006. Clock and time zone data

The system MUST ship current time zone data and MUST be able to update it within the support period. It MUST establish a plausible time before making any decision that depends on it, including certificate validation and update freshness, and MUST behave correctly on devices without a battery-backed clock.

18. Human surfaces — SCF-HUM

SCF-HUM-001. HIF applies in full

Every human-facing surface produced by a system — shell, installer, first-run, recovery, updater, consent dialogs, error messages, documentation and the construction service itself — is governed by the applicable HIF profile. SCF MUST NOT be cited to weaken it.

SCF-HUM-002. Truthful installation

Where the product delivers an installer, it MUST state what it will erase, which disks it will touch and what is irreversible, before it acts, and MUST reflect the actual effect.

SCF-HUM-003. Visible security posture at first use

Where the product has a first-run or first-provisioning surface, it MUST make the meaningful security and privacy choices visible and decidable: storage encryption, account credentials, automatic updates and telemetry. An image-first product MUST expose the same choices through its provisioning contract.

SCF-HUM-004. Consent surfaces are honest

A consent surface MUST NOT use pre-ticked acceptance, unequal prominence, ambiguous wording or repetition to obtain a decision.

SCF-HUM-005. Unattended installation is still accountable

An unattended or scripted installation MUST record the effective configuration it applied, so that the resulting system can be audited against the intent.

SCF-HUM-006. Accessibility before authentication

Where the system has an interactive surface, accessibility settings and assistive technologies MUST be reachable before authentication and during installation and recovery, together with language and keyboard selection.

SCF-HUM-007. Documentation is delivered, not linked

Administration, update, recovery and decommissioning documentation MUST be delivered with the release and MUST be usable without network access.

SCF-HUM-008. Operator handover

Where a system is delivered to an operator who did not build it, the release MUST include what that operator needs to run it: the security posture, the update contract, the recovery procedure, the reporting contact and the end-of-support date.

SCF-HUM-009. Language and text input

The system MUST support the declared languages and keyboard layouts in every surface that can block use, including authentication. Entering a credential MUST NOT depend on a layout the user cannot select at that point, and text input MUST handle non-Latin scripts in the declared languages.

19. Legal, licensing and trademarks — SCF-LGL

SCF-LGL-001. Licence inventory

Every distributed component MUST have an identified licence, and the set of licences MUST be reviewed for conflicts with the intended distribution model before release.

SCF-LGL-002. Licence texts travel with the product

Required notices, licence texts and attributions MUST be delivered with the system in a location the recipient can find without network access.

SCF-LGL-003. Copyleft obligations are discharged at the same place

Where a copyleft licence applies, the corresponding source MUST be offered from the same place as the binary, for the period required, and MUST correspond exactly to the delivered binary.

SCF-LGL-004. Upstream trademarks are respected

Names, logos and visual identity of upstream projects MUST NOT be used in a way their published terms forbid. Where a project requires removal or replacement of its marks in a modified distribution, this MUST be done mechanically as part of the build, not left to manual discipline.

SCF-LGL-005. Derivation is disclosed truthfully

The system MUST state which upstream it derives from, and MUST NOT imply affiliation, endorsement or certification that does not exist.

SCF-LGL-006. Regulatory obligations are engineered, not documented

Where product-security regulation applies to the market the system is placed on, its obligations MUST be reflected in the pipeline — bill of materials, support period, update policy, disclosure policy, reporting capability, technical documentation and retention — rather than described in a policy document alone.

SCF-LGL-007. Export and distribution restrictions are enforced at delivery

Where the system contains components subject to export control or distribution restrictions, the restriction MUST be enforced at the point of delivery and recorded, not only stated in terms of use.

SCF-LGL-008. Design assets are cleared

Fonts, icons, wallpapers, sounds, illustrations and other design assets shipped with the system MUST have documented rights for the intended distribution, including any attribution the licence requires, and MUST be tracked as inputs like any other component.

20. Lifecycle — SCF-LCM

SCF-LCM-001. Versions are meaningful

Version identity MUST distinguish the specification, the release and the channel, and MUST allow a recipient to determine what changed.

SCF-LCM-002. Channels have rules

Every channel MUST have documented promotion criteria, an owner, an audit trail and a defined demotion or rollback path.

SCF-LCM-003. Freshness is monitored

The producer MUST detect when the inputs of a released system have changed upstream, and MUST be able to state, for any release, how far behind it is.

SCF-LCM-004. End of life is announced, not discovered

Approaching end of support MUST be announced through the product's own channels, on the system itself where possible, with enough notice to migrate.

SCF-LCM-005. Migration is provided

At end of life the producer MUST document a migration path, including what happens to data, configuration and the update channel.

21. Evidence and release — SCF-EVD

SCF-EVD-001. Verification is designed with the requirement

Every requirement in scope MUST have a named verification method and an evidence level before implementation begins.

SCF-EVD-002. Automated checks run on every build

Checks that can be performed offline against the produced artefacts MUST run on every build and MUST be capable of failing it.

SCF-EVD-003. Boot-dependent checks run on real firmware

Properties that depend on firmware, secure boot, measurement, storage encryption or hardware MUST be verified in an environment with those facilities, and on reference hardware before general availability.

SCF-EVD-004. Evidence is retained with the release

The release record MUST contain the lock, the manifest, the bill of materials, the logs, the verification results, the exceptions and the approvals, and MUST be retained for the support period.

SCF-EVD-005. Named release approval

A release MUST be approved by a named person against the gate defined in Evaluation and conformance. Visual inspection, a green pipeline or an absence of complaints is not a gate.