> For the complete documentation index, see [llms.txt](https://docs.solcis.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.solcis.ai/legal-centre/secure-development.md). # Secure development How we build, release and maintain Solcis, and what you can check for yourself. Solcis governs what AI systems are allowed to do, so the software itself has to meet a higher bar than the systems it governs. This page sets out how we build, release and maintain Compliance Studio, the Solcis Policy Engine, the gateways and the SDKs, and what you can check for yourself. Our secure development programme is structured on the **NIST Secure Software Development Framework (SSDF), SP 800-218 v1.1**, and its community profile for AI models, **SP 800-218A**. It also supports our alignment with ISO/IEC 27001:2022 secure development controls (A.8.25–A.8.34), ISO/IEC 42001 AI lifecycle controls, and the essential requirements of the EU Cyber Resilience Act. This statement describes our practices. It is not a certification or an independent attestation. ## 1. Preparing the organisation * **Named security ownership.** The Solcis Head of Security and a nominated deputy are accountable for vulnerability handling and security incidents. * **Documented lifecycle.** A secure development lifecycle policy and a secure coding standard set the security requirements every change must meet. Both are reviewed at least annually. * **Secured toolchain.** Build tools and CI actions are pinned to exact versions or commit hashes and verified by checksum before use. Dependencies are resolved from lockfiles. * **Separated environments.** Development, test and production environments are separated, and production or customer data is not used in development or testing. ## 2. Protecting the software * **Controlled access.** Access to source code requires single sign-on with multi-factor authentication. * **Reviewed changes.** Every change to the main branch passes automated checks with designated code owners reviewing security-sensitive areas. All releases are human reviewed before release. * **Signed releases.** Each release manifest is signed (Ed25519). It pins every container image by digest and covers the deployment packages, standalone binaries and model files. You can verify it against our published public key. * **Signed container images.** Container images are signed with Sigstore cosign, so you can verify each image independently of the manifest. * **Build provenance.** Release builds produce signed provenance attestations meeting SLSA Build Level 2. * **Software bill of materials.** Every release ships a CycloneDX SBOM for each first-party and third-party container image. * **Licence compliance.** Third-party licences are checked automatically on every change. The boundary between open-source, source-available and proprietary code is enforced in CI. ## 3. Producing well-secured software * **Threat modelling.** We maintain a STRIDE threat model covering each trust boundary in the product, with a named owner. It is reviewed on significant architectural change and at least annually. * **Memory-safe core.** The policy evaluator, policy compiler and protected kernel are written in Rust. Unsafe code is blocked by default and needs a documented justification. * **Automated checks on every change.** Linting, static analysis, dependency vulnerability scanning across every language we ship, secret scanning and licence checks run on every pull request and block the merge on failure. * **Release vulnerability gate.** Every release is scanned against its SBOMs. A release with an unresolved critical or high-severity vulnerability is blocked unless a dated, reviewed exception is recorded. * **Secret protection.** Secret scanning blocks every change, and the full repository history is re-scanned daily. * **Fuzz testing.** Parsers and the policy evaluator are fuzz-tested. * **Independent testing.** Independent penetration testing is performed at least annually against OWASP ASVS 5.0 Level 2. A letter of attestation is available under NDA. * **Secure defaults.** Solcis ships in a secure configuration. Weakening a security setting requires an explicit, logged change. ## 4. AI-specific practices (SP 800-218A) Solcis uses AI models inside the Policy Engine, so we apply the SSDF profile for AI models alongside the core practices. * **Model integrity.** Model files are signed in the release manifest and verified before deployment. * **Controlled policy change.** Policies move through a human-approved, signed lifecycle (draft, staging, shadow, production) before they enforce. * **Adversarial testing.** The decision path is tested against an adversarial probe suite covering prompt injection, evasion and policy bypass across every trust boundary. * **Evaluation before release.** Model and inference changes must pass defined evaluation thresholds for decision accuracy and robustness before release. * **Training data.** Customer data is not used to train, fine-tune or evaluate Solcis models. ## 5. Responding to vulnerabilities * **Coordinated disclosure.** Report vulnerabilities to `security@solcis.ai` or through GitHub private vulnerability reporting. We acknowledge reports within three business days and offer safe harbour to good-faith researchers. See our [Vulnerability disclosure policy](/legal-centre/vulnerability-disclosure-policy.md). * **Remediation targets.** We aim to release fixes for critical vulnerabilities within **7** days and high-severity vulnerabilities within **28** days of confirmation. * **Security advisories.** Fixed vulnerabilities are published as security advisories with CVE identifiers and CWE classification, alongside the release changelog. * **Update notification.** Customers are notified when a security update is available, including for air-gapped deployments. * **Support periods.** Each release has a published security support period. * **Regulatory reporting.** We maintain a process for reporting actively exploited vulnerabilities and severe incidents under Article 14 of the EU Cyber Resilience Act. * **Root cause.** Confirmed vulnerabilities are analysed for root cause, and the class of issue is fed back into our checks. ## What you can check yourself * Verify the release manifest signature against our published public key. * Review the SBOM shipped with each release. * Verify container image signatures and build provenance. * Report a vulnerability and see how we handle it. * Under NDA, request our SSDF practice mapping, threat model summary and penetration test attestation. ## Shared responsibility Solcis is self-hosted. We are responsible for the security of the software we ship and how we build it. You are responsible for how it is deployed, configured and operated in your environment. See [Security and integrity](/legal-centre/security-and-integrity.md). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.solcis.ai/legal-centre/secure-development.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.