Secure development and supply chain
The public repository treats documentation, legal data, connector packages, application code and deployment artefacts as separately reviewed supply-chain inputs.
Change path
Section titled “Change path”Threat/privacy review at design → issue with control/abuse mapping → branch protection → peer review and domain-owner review → unit/property/integration/security tests → SAST/SCA/secret/IaC/container/ licence scan → ephemeral environment → signed release candidate → independent approval → progressive rollout → monitoring/rollback.
Legal-status changes additionally require primary source, exact diff, legal reviewer and signed configuration bundle. A code maintainer cannot self-approve law.
Required gates
Section titled “Required gates”- formatter, type/schema, unit and integration tests;
- tenant isolation and authorization negative tests;
- OpenAPI/event compatibility;
- migration forward/rollback compatibility;
- dependency and licence review;
- secret and high-entropy scan;
- SAST, connector injection/fuzz and DAST for public routes;
- IaC/Kubernetes policy and container scan;
- SBOM in CycloneDX/SPDX, provenance and signature;
- documentation link/frontmatter/source/control validation;
- accessibility checks for critical journeys.
Dependency policy
Section titled “Dependency policy”Pin direct versions and commit the lockfile. Renovation creates reviewed updates with changelog and test evidence. Remove unmaintained/high-risk dependencies or isolate them. Runtime critical/high known exploitable issues block release unless an accountable, time-bound exception includes reachability and compensating controls.
At the initial documentation scaffold, upgrading Mermaid to 11.16.0 and YAML to 2.9.0 removed the
reported dependency advisories; npm audit --omit=dev returned zero. Audit status is a point-in-time
signal, not proof of safety.
Build and release
Section titled “Build and release”Use ephemeral isolated runners, minimal scoped tokens, protected environments and two-person release. Produce immutable image digests, source commit, build parameters, SBOM, vulnerability report, provenance, signatures and migration notes. Verify at deployment; air-gapped bundles carry the same metadata and offline public keys/revocation information.
Target reproducible builds; document nondeterministic exceptions. Signed release tags are recommended. Connector packages are signed independently and declare capabilities.
Vulnerability handling
Section titled “Vulnerability handling”Private report route in SECURITY.md; acknowledge within two business days; triage severity and
affected supported versions; coordinate fix/advisory/CVE where appropriate; credit reporter;
publish remediation without exposing customer data. Indicative patch objectives:
| Severity | Triage | Fix/mitigation target |
|---|---|---|
| critical exploited | immediate | 24–72 hours |
| critical/high | 1 business day | 7/14 days |
| medium | 3 business days | 30 days |
| low | next planned release | 90 days |
Targets can shorten under sector/customer contracts. Self-hosted customers receive signed notices and mitigations; telemetry is not required to learn affected installs.
Security testing
Section titled “Security testing”OWASP ASVS/API controls guide application tests; connector agents additionally receive parser, command, filesystem/network capability, update and local privilege tests. Annual independent penetration testing plus material-change tests. Findings include owner, severity, exploitability, affected versions, remediation, retest and disclosure decision.
Maintainer security
Section titled “Maintainer security”Phishing-resistant MFA, least repository/package permissions, protected default/release branches, review ownership for security/legal/deployment, no long-lived personal release token, contributor provenance via DCO, and offboarding within one business day.