Part of #118. Suite-integration workstream. compliance-scanner and tramiton are the same company — onboarding must reconcile tramiton's authoritative firmware evidence, not recompute it.
Context
tramiton already does firmware build detection, SBOM (CycloneDX/SPDX), VEX (OpenVEX), reproducible builds, and attestation. When a tenant who owns tramiton onboards a firmware/Yocto target here, we should fetch/reuse tramiton's evidence.
Integration facts (verified against /home/sharang/workspace/tramiton, v0.4.0)
Mechanism: shell out to the tramiton CLI (crates are license = "Proprietary"; mirror the JSON, don't link). tramiton detect --json <path> → {repo, detections, plan:BuildPlan} with typed target{board,mcu,arch}, build_system, framework, confidence, gaps.
Reconciliation key: tramiton project_id (shared cross-product key) + firmware SHA-256 = compliance-scanner's Artifact.content_hash. Ingest hashing is the join key.
Cloud read-back does NOT exist yet — tramiton cloud only stores SBOMs (write-only). Near-term reconciliation reads local .tramiton/ outputs (tramiton.lock TOML, sbom.cdx.json, vex.openvex.json, DSSE attestation). Cloud fetch needs tramiton to add read endpoints later.
Formats already match (CycloneDX 1.5, OpenVEX 0.2.0) — reconciled evidence flows in shapes we handle.
Scope
Seam now: EvidenceProvider port in compliance-core + a TramitonCli impl (detect handoff + local .tramiton/ reader) + a deterministic mock for tests. ExternalRef/ExternalProvenance on the target model (system=tramiton, project_id, subject_sha256, status, license_grant?).
Firmware/Yocto scans prefer reconciled tramiton evidence when the artifact hash matches; else recompute.
Later: cloud fetch once tramiton adds read endpoints; LicenseGrant verification for entitlement (needs shared pinned pubkey).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Part of #118. Suite-integration workstream. compliance-scanner and tramiton are the same company — onboarding must reconcile tramiton's authoritative firmware evidence, not recompute it.
Context
tramiton already does firmware build detection, SBOM (CycloneDX/SPDX), VEX (OpenVEX), reproducible builds, and attestation. When a tenant who owns tramiton onboards a firmware/Yocto target here, we should fetch/reuse tramiton's evidence.
Integration facts (verified against
/home/sharang/workspace/tramiton, v0.4.0)tramitonCLI (crates arelicense = "Proprietary"; mirror the JSON, don't link).tramiton detect --json <path>→{repo, detections, plan:BuildPlan}with typedtarget{board,mcu,arch},build_system,framework,confidence,gaps.project_id(shared cross-product key) + firmware SHA-256 = compliance-scanner'sArtifact.content_hash. Ingest hashing is the join key..tramiton/outputs (tramiton.lockTOML,sbom.cdx.json,vex.openvex.json, DSSE attestation). Cloud fetch needs tramiton to add read endpoints later.LicenseGrant {project, subscription, expires}(packaged asProjectBundle). Map tramitontenant_id→ our tenant.Scope
EvidenceProviderport in compliance-core + aTramitonCliimpl (detect handoff + local.tramiton/reader) + a deterministic mock for tests.ExternalRef/ExternalProvenanceon the target model (system=tramiton, project_id, subject_sha256, status, license_grant?).LicenseGrantverification for entitlement (needs shared pinned pubkey).Depends on
ONB-01 (#119), ONB-02 (#120), ONB-03 (#121). Firmware specifics (#128).