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).
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.
Rule packs are versioned like software (current: CRA-EU-2026.08.1). 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.
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
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.