Engineering integration · Continuous

Bring the evidence chain into your release pipeline.

Upload a release snapshot, supply its SBOM, wait for an assessment, and evaluate an explicit engineering gate. Keep accountable decisions with the people who own them.

One setup, then a repeatable release flow

Create a product with Continuous coverage. An Owner or Admin creates a product-scoped, expiring credential in Product settings > CI/CD.
Store the token as a masked CI secret. Choose only the evidence, assessment, result or event permissions the job needs.
Run the CLI against an immutable build directory and a named release. An optional CycloneDX JSON or SPDX JSON SBOM is supplied before the source upload is sealed.
Poll the exact run or receive a signed completion event. Preserve its run ID, snapshot, input hash, policy version and evaluation time with the build.
Let the release step continue only when the gate returns passed. If human approval is pending, an authorized person records it in ConformOps and the pipeline checks again.

The CLI never executes repository code. Uploaded source is sanitized before storage. Supplied SBOMs are retained evidence, not validated statements of completeness.

A small API with explicit scope

The versioned API under /api/v1/projects/{productId} supports source uploads, release-bound supplied SBOMs, assessment starts, complete machine-readable requirement states and an ordered event feed. It can also reassess a snapshot already held by ConformOps.

Credentials are shown once, stored hashed and revocable. Every request checks current workspace authority and Continuous coverage. A pipeline cannot approve a risk, choose a final legal route, sign a declaration, change its gate policy or manage billing.

Creation keys recover the same resource after a lost response. Assessment deduplication follows the server's content identity, so changing a request key cannot force duplicate assessment work.

Every gate state has a defined meaning

State	What the pipeline does
Passed	Continue only for the recorded policy evaluation. This is not a CRA compliance verdict.
Blocked	Stop. A policy threshold failed, the baseline is superseded, or assessment failed.
Degraded	Stop. Source coverage or vulnerability intelligence is incomplete.
Unknown	Stop. Required facts, inventory coverage or sufficiently recent intelligence are unavailable.
Pending	Wait for processing or required human decisions, then evaluate again.

Owner/Admin policy controls maximum unresolved requirements, vulnerability matches, evidence age, human-approval checks and a usable supplied-SBOM requirement. Stale baselines and unknown or degraded coverage cannot be configured into a pass. All refusal reasons remain visible.

Events without evidence disclosure

Signed webhooks cover assessment completion, changed gaps, refreshed vulnerability intelligence and observed gate outcomes. Payloads contain identifiers, time and state, without source paths, excerpts, component details or credentials.

Receivers verify HMAC signatures and deduplicate event IDs. Deliveries have durable retries and visible failure status. Outbound destination hosts need operator configuration; the authenticated event feed and result polling work without it.

Install and connect

Download the self-contained CLI and verify its SHA-256 checksum. It needs Node 22.23.2 or later and no package installation. Review and pin the downloaded file, then run node conformops.mjs --help. Keep it outside the source directory you submit.

Download CLI SHA-256 checksums

Read the full CLI and API contract

The reference includes commands, payloads, permissions, idempotency recovery, every gate condition, exit codes and webhook signature verification.

What CRA work can be automated? · How this fits existing SBOM and vulnerability tools · Continuous coverage