ShipGate is a release-readiness engine. Point it at a GitHub repository, describe what you ship, and it determines which release obligations matter, checks what repository evidence can establish, asks for what it cannot, and produces a commit-specific go/no-go gate. The first rule pack covers the EU Cyber Resilience Act (Regulation (EU) 2024/2847).
ShipGate never produces a compliance percentage. Every requirement lands in one of four statuses:
| Status | Meaning |
|---|---|
| BLOCKER | Something materially missing that ShipGate could verify is absent |
| REVIEW | Compliance cannot be established from repository evidence alone |
| PASS | Sufficient evidence exists for this gate — evidence found, not "compliant" |
| N/A | Requirement does not apply to this product context |
Every unresolved item is exactly one of three actions: FIX (mechanical, ShipGate drafts the change), PROVE (you have it, show the evidence), or ANSWER (a business fact source code cannot reveal).
Every finding carries a provenance label, so it is always visible where a conclusion came from — no verdict is an improvised judgment:
| Label | Meaning |
|---|---|
| Observed | ShipGate found it in the repository |
| Derived | A deterministic rule interpreted observed and declared facts |
| Declared | The manufacturer supplied it as an explicit answer |
| Reviewed | A human explicitly accepted the evidence or decision |
Automatic checks are Observed · Derived; onboarding answers are Declared; evidence you attach to PROVE items becomes Reviewed. The same labels are preserved in the gate receipt.
Results state what ShipGate could and could not inspect, so a future auditor can distinguish "REVIEW because evidence is absent" from "REVIEW because ShipGate deliberately stopped looking." Each receipt carries a structural coverage record — for example a repository with 34 workflow files of which 30 were inspected reports workflows: partial (30/34), and every affected non-passing finding carries an explicit coverage note. When coverage is limited, verdicts stay conservative (REVIEW); ShipGate never converts uninspected evidence into a PASS.
A repository alone cannot tell you whether a regulation applies. Onboarding asks eight questions (product type, commercial activity, EU market, open-source status, connectivity, completeness, category) and derives whether the CRA gate applies, whether the product may be an important product (Class I/II) with a stricter conformity route, or whether it is likely out of scope. These are manufacturer declarations — ShipGate records them, it does not infer them.
~19 checks run against repository evidence: SBOM generation and release artifacts, dependency manifests and lockfiles, SECURITY.md and reporting route, supported-version documentation, CI security scanners, Dependabot/Renovate, GitHub Action SHA pinning, release process, signing/attestation signals, committed secrets, default credentials in configs, license, user documentation, changelog, update-mechanism signals, and tests in CI. Every finding cites its source requirement in Regulation (EU) 2024/2847.
What is never inferred from code: intended purpose, support period, manufacturer identity, market placement, classification, risk acceptance. Those are ANSWER and PROVE items.
Provide a GitHub token in the scan app to scan private repositories and open fix PRs. The token is kept in your browser's session storage; each scan or fix-PR request sends it to the ShipGate server, which uses it for that request's GitHub API calls and then discards it — it is never stored server-side. Use a fine-grained token scoped to the repositories you scan (read for scanning; read/write contents + pull requests for fix PRs). A GitHub App with installation-scoped access is planned to replace pasted tokens.
The fix PR creates branch shipgate/cra-readiness with only mechanical files (SBOM workflow, SECURITY.md draft built from your answers, dependabot.yml) and opens one pull request. Placeholders in [brackets] are manufacturer facts ShipGate will not invent.
CRA reporting obligations apply from 11 September 2026, via the ENISA single reporting platform. The full lifecycle for an actively exploited vulnerability: early warning within 24 hours of awareness, vulnerability notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure is available. For a severe incident: early warning within 24 hours, incident notification within 72 hours, and a final report within one month of the incident notification. The reporting gate tracks whether your organization has a responsible contact, triage ownership, escalation procedure, assigned reporting responsibility, and 24-hour capability. ShipGate prepares and tracks readiness; it does not submit regulatory reports.
Every gate run produces a receipt (SG-<year>-<commit>) recording exactly which ruleset ran against which commit with which evidence and declarations. You can also download .shipgate/product.yml and evidence.yml to version compliance state with your code, and generate a CRA technical-documentation skeleton (Annex VII starting point) with [REQUIRES MANUFACTURER INPUT] markers.
Beyond the CRA rule pack, ShipGate runs two licence engines over the exact published artifact rather than over a repository's intentions. The OSS licence gate witnesses an npm tarball or a GitHub release asset — opening it without executing it — and checks whether each bundled component's required notice actually accompanies the bytes you ship.
The MPL evidence report goes a layer deeper for Mozilla Public License 2.0 material. It identifies MPL-labelled components by their own bytes and then stops at the questions it cannot answer from evidence, rather than guessing:
(MPL-2.0 OR Apache-2.0) never silently becomes MPL because the MPL engine happens to be running. Until you state your election, no MPL coverage is derived and no obligation is asserted.LICENSE in a directory proves a file exists; it does not establish that the notice scopes those particular files. The report says so instead of inferring coverage.not_covered status anywhere in the engine.Every claim carries its provenance (observed, corroborated, derived, declared, reviewed), and each receipt lists the exact rulesets that produced it together with their state. The MPL evidence adapters — attachment, Source Code Form, Executable Form, and executable lineage — are frozen; the interpretation layer that joins them is not yet graduated, so its output is labelled evaluation-grade and is never presented as a settled verdict.
What the report now does: for each MPL-labelled component it inspects the source files inside the exact published artifact, establishes attachment per file from the notices those files actually carry, binds the published version to a corroborated upstream revision, and composes the two into the set of Covered files before checking the §3.1/§3.4 obligations. What it still reports rather than hides: how many files were matched versus inspected, since the witness scan is bounded — anything beyond those bounds is counted, never treated as absence. A file without a notice is not thereby outside MPL, and an unestablished Source Code Form is not an uncovered file.
Rule packs are versioned like software, and each engine reports its own current version in the page header and in every receipt (never from a hardcoded string). When regulatory guidance changes, ShipGate ships a new ruleset version — your repository may be unchanged while the rules changed, and the gate says so explicitly. A frozen ruleset cannot change semantics without a new version, and the licence engines archive every superseded version alongside the defect ledger that forced it.
POST /api/scan { repo, answers, evidence, token? } → gate result + receipt
POST /api/fix-pr { repo, token, files, findingTitles } → { pr: { url, number } }
GET /api/receipt/:id → receipt JSON
POST /api/scope { answers } → scope determination
POST /api/oss/witness { package, version? } → artifact-witnessed OSS gate
POST /api/oss/gh-release{ repo, tag?, asset?, token? } → release-asset witness
POST /api/mpl/scan { package, version?, declarations? } → MPL evidence report
GET /api/rulesets → current ruleset ids
The three artifact endpoints make ShipGate fetch remote archives, so they are rate limited per client.
ShipGate is software for release-readiness checks and evidence preparation. It is not a conformity assessment body, does not issue CE marks or declarations of conformity, and does not certify regulatory compliance. Final product classification, conformity assessment and market-placement decisions remain with the manufacturer. Nothing on this site is legal advice.