Open integration software supply-chain assurance
This page covers the public synapse-cdm package and its release process. It does not describe or make assurance claims about the proprietary SynapseCommand decision runtime.
The controls expose risk and make release evidence inspectable. They do not make software secure by definition and do not constitute certification or third-party audit.
From commit to verifiable artefact
Each stage contributes evidence about a defined part of the release. No single stage guarantees all stages before it.
- 1. Source commitThe reviewed source and workflow definitions at a named revision.
- 2. Tests and conformanceThe package suite, adapter conformance sweep and evidence generation must pass.
- 3. Static and dependency checksCodeQL, dependency auditing and secret-history checks expose defined classes of risk.
- 4. Package buildThe wheel and source distribution are built once from the gated tree.
- 5. SBOMsSPDX and CycloneDX documents describe the clean installation and its runtime closure.
- 6. Hashes and attestationsSHA-256 digests and build provenance bind named artefacts to the release workflow.
- 7. Trusted publicationA short-lived OIDC identity publishes the package without a stored package-registry token.
- 8. Independent verificationRelease assets let an evaluator check digests, attestations, conformance and evidence.
What each control checks, and what it does not prove
- CodeQL security-extended
- Checks: Python and JavaScript or TypeScript source with the security-extended query suite. Findings rated high or critical block the gate.
- Does not prove: Static analysis does not inspect dependency advisories and does not prove the absence of defects.
- GitHub dependency review
- Checks: New dependencies introduced through a pull request, with high-severity findings configured to fail.
- Does not prove: It applies to pull requests. The separate strict package audit covers the dependency set on pushes and releases.
- pip-audit --strict
- Checks: The development environment and the built wheel's frozen third-party closure in a clean environment.
- Does not prove: It reports known published advisories. It is not a source-code audit of those dependencies.
- Gitleaks full-history scan
- Checks: The full Git history reachable from the run, using a versioned Gitleaks binary whose download is hash-checked.
- Does not prove: A clean scan means no configured pattern matched. It cannot establish that no secret exists under every possible encoding or pattern.
- Dependabot
- Checks: Python package, workflow-action and documentation dependencies on a weekly update cadence.
- Does not prove: Update automation identifies available changes. Review, tests and release gates still decide what is accepted.
Two machine-readable inventories
Release 2.1.2 includes SPDX 2.3 JSON and CycloneDX JSON software bills of materials. The release also includes one SHA256SUMS file covering the wheel, source distribution, SBOMs, conformance report and evidence bundle. Evaluators can download the assets, recalculate each SHA-256 digest and compare it with the published table.
Short-lived identities, verifiable artefacts
The release workflow uses GitHub build provenance attestation backed by Sigstore and OIDC for the wheel, source distribution, both SBOMs and the evidence bundle, then verifies those attestations in the same run. PyPI Trusted Publishing over OIDC uploads the distribution without a stored registry token. This is build provenance and authenticated publication, not code signing, package certification or an independent security audit.
Minimal runtime dependency surface
The synapse-cdm 2.1.2 package declares 2 runtime dependencies: pydantic and jsonschema. A smaller declared set makes the runtime closure easier to inspect and audit. It does not make the package or its dependencies secure automatically.
Offline by design
The public integration package does not implement its own network client, telemetry, licence check, update ping or remote registry. It can perform translation and conformance work without requiring a service connection. This statement describes the package implementation, not every possible transitive dependency or host environment.
Three separate evidence domains
Public package supply chain
This page owns build controls, SBOMs, digests, attestations, publication and offline implementation scope.
Adapter conformance
Interoperability evidence owns direction, fixtures, loss accounting and conformance for each public adapter.
Private runtime assurance
Decision-quality evidence owns proprietary runtime TEVV, model-bearing runs and decision assurance.
Exceptions and limitations
Documented security exceptions are schema-validated, assigned an owner and expiry, and consumed from one repository directory by the relevant gates. An expired exception fails the suite.
Automated controls reduce, expose and record risk. They do not eliminate vulnerability risk, prove the absence of unknown defects or certify the package.
The release is built once and hashed. The repository does not claim that separate builds are byte-for-byte reproducible.