Section 24Platform and Delivery

Security and safety requirements

Defines trust, isolation, permissions, resource limits, integration arming, and safeguards for untrusted or physical interactions.

Section relationships
IDNamePriorityRequirementVerification
SEC-001No implicit network accessMVPThe portable product SHALL make no outbound network connection unless the user enables a networked capability.Test
SEC-002Untrusted asset parsingMVPAsset parsers SHALL enforce configured limits for size, nesting, references, decompression, geometry counts, and processing time.Test
SEC-003Path traversal protectionMVPProject, archive, cache, and importer paths SHALL not escape authorized roots through traversal, links, or crafted archive entries.Test
SEC-004No asset code executionMVPData import SHALL not execute asset-provided code, plugins, macros, or commands by default.Test
SEC-005Secret redactionMVPLogs, manifests, reproduction bundles, and diagnostics SHALL redact configured secrets and credentials.Test
SEC-006Dependency inventoryMVPEvery release SHALL publish or embed a software bill of materials with versions and licenses.Inspection
SEC-007Vulnerability policyMVPRelease candidates SHALL pass the approved dependency vulnerability policy with documented exceptions.Inspection
SEC-008Unsafe-code policyMVPFirst-party core crates SHALL forbid unsafe Rust unless an exception is isolated, documented, reviewed, and tested.Inspection
SEC-009External permission manifestBetaEvery external extension SHALL declare requested filesystem, network, process, environment, shared-memory, GPU, and physical-device access.Test
SEC-010Sandbox defaultBetaUntrusted extensions SHALL run in a Wasm sandbox or restricted process rather than in the host address space.Test
SEC-011HIL safe defaultExternalHIL integrations SHALL default to disarmed physical outputs and SHALL require explicit user action to arm.Demonstration
SEC-012Physical limitsExternalHIL output SHALL enforce configured command, rate, energy, temperature, and communication-watchdog limits where applicable.Test
SEC-013Signed releasesBetaOfficial release artifacts and official extension packages SHALL be cryptographically signed.Inspection
SEC-014Network authenticationBetaA remotely accessible gateway SHALL authenticate peers and protect message integrity using an approved configuration.Test
SEC-015External executable policyBetaExtensions, adapters, FMU hosts, controller processes, firmware emulators, and external solvers SHALL be governed by one default-deny executable policy.Inspection
SEC-016Explicit permission grantsBetaAn external executable SHALL receive only permissions explicitly granted by the user or administrator, and grants SHALL be stored outside project-controlled data.Test
SEC-017Permission expansion approvalBetaInstalling or upgrading an external executable SHALL require renewed approval before any filesystem, network, process, environment, shared-memory, GPU, or device permission expands.Test
SEC-018Sandbox fail-closedBetaAn untrusted external executable requiring unavailable sandbox enforcement SHALL remain inactive unless the user makes a separately recorded trust decision permitted by policy.Test
SEC-019Hostile protocol inputsBetaEvery external message, shared-memory descriptor, archive, and handle SHALL be treated as untrusted and validated against negotiated type, size, count, depth, lifetime, ownership, and capacity limits.Test
SEC-020No remote listener by defaultMVPThe portable product SHALL not open a non-loopback listening socket unless the user explicitly enables a remote capability.Test

Generated from the canonical specification. Edit section metadata or prose in docs/requirements.md; the website rebuilds this page and its relationships automatically.