sharang/compliance-scanner-agent
1
0
Fork 0
Code Issues 79 Pull Requests 1 Actions Packages Projects Releases 1 Wiki Activity

ONB-Epic · Multi-target artifact-aware onboarding wizard #118

New Issue
Open
opened 2026-07-10 08:32:57 +00:00 by sharang · 4 comments
sharang commented 2026-07-10 08:32:57 +00:00
Owner
Copy Link
Copy Source

Epic — Multi-target, artifact-aware onboarding wizard

Problem

Onboarding today is git-only and rudimentary. Three disconnected entry points exist, each with its own bare form and no notion of what kind of software the target is:

  • TrackedRepository (name / git_url / branch / auth / tracker) — the SAST/SBOM/CVE/lint/secrets path (compliance-dashboard/src/pages/repositories.rs).
  • DastTarget (base_url / WebApp|RestApi|GraphQl / auth) — the DAST path.
  • PentestSession (target_id + repo_id + wizard config) — the pentest path.

The product vision is a single workflow: onboard the target → classify it → ingest whatever artifacts exist → run the applicable scans (SAST if code, DAST if runtime/binary, active pentest if a reachable running target). That requires an onboarding that understands the full spectrum of targets — Yocto / embedded Linux, PLC / SPS (IEC 61131-3), bare-metal firmware, RTOS firmware, Android, iOS, websites, backend services, desktop apps — and knows which artifacts and scans apply to each.

Design principle (borrowed from Tramiton)

Tramiton's insight: targets look endlessly varied but fall into a small enumerable set classified by where the signal lives, and detection is table-driven — one row per type, a registry, auto-detection from artifacts. We mirror that here:

  • A target-type registry: one row per target type declaring accepted artifact kinds and applicable scan families.
  • An artifact-aware classifier that infers the target type and recommended scans from what was uploaded/linked (Tramiton's detect for firmware; language/build-system fingerprinting for the rest). Firmware/Yocto/PLC artifacts can hand off to Tramiton for build/SBOM/repro.
  • A scan-applicability matrix: (target type × artifacts present) → {SAST, DAST, Pentest} sub-scans, with rationale, driving what the wizard pre-selects.

Target taxonomy (v1)

Target type Typical artifacts SAST SBOM/CVE DAST Pentest
Web application git/zip + live URL ✓ ✓ ✓ ✓
Backend service / API git/zip + live endpoint ✓ ✓ ✓ (REST/GraphQL) ✓
Desktop application git/zip + binary ✓ ✓ binary/local local
Android app git/zip + APK/AAB ✓ ✓ ✓ (dynamic) ✓
iOS app git/zip + IPA ✓ ✓ limited limited
Firmware — bare metal git/zip + firmware image ✓ (Tramiton/source-arch) ✓ (binwalk/EMBA/cve-bin-tool) — HW-in-loop (opt)
Firmware — RTOS git/zip + image + RTOS cfg ✓ ✓ — opt
Embedded Linux / Yocto BSP layers + firmware image ✓ ✓ (EMBA, heavy SBOM) if net services if net services
PLC / SPS (IEC 61131-3) PLCopen XML / ST / project zip ✓ (control-logic rules) limited — —

Artifact kinds: git repo, source zip/tarball, firmware image/binary, APK/AAB/IPA, container image, live URL/endpoint, PLC project (PLCopen XML / ST), plaintext/free-form description.

Wizard flow (its own screens)

  1. Target type — card grid of the 9 types + "Not sure / auto-detect".
  2. Artifacts — type-aware inputs (git URL, upload zip/firmware/APK/IPA, live URL, paste text); multi-artifact allowed; auto-detection runs and confirms type + discovered languages/build system/frameworks.
  3. Scans + scope — applicable scans pre-selected from the matrix with rationale and toggles; DAST auth; pentest scope/identity/environment/destructive/rate-limit.
  4. Review & launch — summary of target + artifacts + planned scans; create the target and optionally trigger the first scan.

Sub-issues

  • Target taxonomy + unified data model (OnboardedTarget, TargetType, Artifact) + Mongo repo
  • Artifact ingest layer (git / zip / firmware / mobile / container / live URL / plaintext) + storage + validation
  • Artifact-aware classifier / auto-detection (Tramiton detect handoff for firmware/PLC; language + build-system fingerprinting)
  • Scan-applicability matrix (target type × artifacts → SAST/DAST/pentest sub-scans)
  • Onboarding wizard shell — multi-step Dioxus flow (stepper, state, validation, back/next)
  • Wizard screen 1 — target type selection (card grid + auto-detect)
  • Wizard screen 2 — artifact upload/link (type-aware inputs + upload/progress)
  • Wizard screen 3 — scan selection + scope/auth (DAST auth, pentest scope/identity/environment)
  • Wizard screen 4 — review & launch (summary + create + trigger first scan)
  • Firmware / Yocto onboarding specifics (Tramiton ingest + EMBA/binwalk wiring)
  • Mobile (Android/iOS) onboarding specifics (APK/AAB/IPA ingest + tooling)
  • PLC / SPS onboarding specifics (PLCopen XML / ST ingest; ties to CS-E1)
  • Onboarding API endpoints (target CRUD, artifact upload, detection)
  • Migration + back-compat: fold existing TrackedRepository / DastTarget into the target model

Decision to ratify in /plan

Unify the three target models (TrackedRepository, DastTarget, pentest target) under one OnboardedTarget aggregate that owns a set of Artifacts and a set of enabled scan configs — vs. keeping them separate and layering onboarding on top. Recommendation: unify, with the existing structs kept as views/back-compat during migration. /plan settles the exact shape.

## Epic — Multi-target, artifact-aware onboarding wizard ### Problem Onboarding today is git-only and rudimentary. Three disconnected entry points exist, each with its own bare form and no notion of *what kind of software* the target is: - `TrackedRepository` (name / git_url / branch / auth / tracker) — the SAST/SBOM/CVE/lint/secrets path (`compliance-dashboard/src/pages/repositories.rs`). - `DastTarget` (base_url / WebApp|RestApi|GraphQl / auth) — the DAST path. - `PentestSession` (target_id + repo_id + wizard config) — the pentest path. The product vision is a single workflow: **onboard the target → classify it → ingest whatever artifacts exist → run the applicable scans (SAST if code, DAST if runtime/binary, active pentest if a reachable running target)**. That requires an onboarding that understands the full spectrum of targets — Yocto / embedded Linux, PLC / SPS (IEC 61131-3), bare-metal firmware, RTOS firmware, Android, iOS, websites, backend services, desktop apps — and knows which artifacts and scans apply to each. ### Design principle (borrowed from Tramiton) Tramiton's insight: targets look endlessly varied but fall into a *small enumerable set* classified by *where the signal lives*, and detection is **table-driven** — one row per type, a registry, auto-detection from artifacts. We mirror that here: - A **target-type registry**: one row per target type declaring accepted artifact kinds and applicable scan families. - An **artifact-aware classifier** that infers the target type and recommended scans from what was uploaded/linked (Tramiton's `detect` for firmware; language/build-system fingerprinting for the rest). Firmware/Yocto/PLC artifacts can hand off to Tramiton for build/SBOM/repro. - A **scan-applicability matrix**: `(target type × artifacts present) → {SAST, DAST, Pentest}` sub-scans, with rationale, driving what the wizard pre-selects. ### Target taxonomy (v1) | Target type | Typical artifacts | SAST | SBOM/CVE | DAST | Pentest | |---|---|---|---|---|---| | Web application | git/zip + live URL | ✓ | ✓ | ✓ | ✓ | | Backend service / API | git/zip + live endpoint | ✓ | ✓ | ✓ (REST/GraphQL) | ✓ | | Desktop application | git/zip + binary | ✓ | ✓ | binary/local | local | | Android app | git/zip + APK/AAB | ✓ | ✓ | ✓ (dynamic) | ✓ | | iOS app | git/zip + IPA | ✓ | ✓ | limited | limited | | Firmware — bare metal | git/zip + firmware image | ✓ (Tramiton/source-arch) | ✓ (binwalk/EMBA/cve-bin-tool) | — | HW-in-loop (opt) | | Firmware — RTOS | git/zip + image + RTOS cfg | ✓ | ✓ | — | opt | | Embedded Linux / Yocto | BSP layers + firmware image | ✓ | ✓ (EMBA, heavy SBOM) | if net services | if net services | | PLC / SPS (IEC 61131-3) | PLCopen XML / ST / project zip | ✓ (control-logic rules) | limited | — | — | Artifact kinds: **git repo**, **source zip/tarball**, **firmware image/binary**, **APK/AAB/IPA**, **container image**, **live URL/endpoint**, **PLC project (PLCopen XML / ST)**, **plaintext/free-form description**. ### Wizard flow (its own screens) 1. **Target type** — card grid of the 9 types + "Not sure / auto-detect". 2. **Artifacts** — type-aware inputs (git URL, upload zip/firmware/APK/IPA, live URL, paste text); multi-artifact allowed; auto-detection runs and confirms type + discovered languages/build system/frameworks. 3. **Scans + scope** — applicable scans pre-selected from the matrix with rationale and toggles; DAST auth; pentest scope/identity/environment/destructive/rate-limit. 4. **Review & launch** — summary of target + artifacts + planned scans; create the target and optionally trigger the first scan. ### Sub-issues - [ ] Target taxonomy + unified data model (`OnboardedTarget`, `TargetType`, `Artifact`) + Mongo repo - [ ] Artifact ingest layer (git / zip / firmware / mobile / container / live URL / plaintext) + storage + validation - [ ] Artifact-aware classifier / auto-detection (Tramiton `detect` handoff for firmware/PLC; language + build-system fingerprinting) - [ ] Scan-applicability matrix (target type × artifacts → SAST/DAST/pentest sub-scans) - [ ] Onboarding wizard shell — multi-step Dioxus flow (stepper, state, validation, back/next) - [ ] Wizard screen 1 — target type selection (card grid + auto-detect) - [ ] Wizard screen 2 — artifact upload/link (type-aware inputs + upload/progress) - [ ] Wizard screen 3 — scan selection + scope/auth (DAST auth, pentest scope/identity/environment) - [ ] Wizard screen 4 — review & launch (summary + create + trigger first scan) - [ ] Firmware / Yocto onboarding specifics (Tramiton ingest + EMBA/binwalk wiring) - [ ] Mobile (Android/iOS) onboarding specifics (APK/AAB/IPA ingest + tooling) - [ ] PLC / SPS onboarding specifics (PLCopen XML / ST ingest; ties to CS-E1) - [ ] Onboarding API endpoints (target CRUD, artifact upload, detection) - [ ] Migration + back-compat: fold existing `TrackedRepository` / `DastTarget` into the target model ### Decision to ratify in /plan **Unify** the three target models (`TrackedRepository`, `DastTarget`, pentest target) under one `OnboardedTarget` aggregate that owns a set of `Artifact`s and a set of enabled scan configs — vs. keeping them separate and layering onboarding on top. Recommendation: **unify**, with the existing structs kept as views/back-compat during migration. /plan settles the exact shape.
sharang added this to the Onboarding v1 milestone 2026-07-10 08:32:57 +00:00
sharang added the enhancementonboardingepic labels 2026-07-10 08:32:57 +00:00
sharang commented 2026-07-10 08:40:36 +00:00
Author
Owner
Copy Link
Copy Source

Sub-issue index below.

Sub-issue index below.
sharang commented 2026-07-10 08:41:02 +00:00
Author
Owner
Copy Link
Copy Source

Sub-issues created (dependency order)

Backend foundation

  • #119 — ONB-01 · Target taxonomy + unified data model
  • #120 — ONB-02 · Artifact ingest layer
  • #121 — ONB-03 · Artifact-aware classifier / auto-detection (Tramiton handoff)
  • #122 — ONB-04 · Scan-applicability matrix
  • #131 — ONB-13 · Onboarding API endpoints

Wizard UI

  • #123 — ONB-05 · Wizard shell (multi-step flow/state/nav)
  • #124 — ONB-06 · Screen 1: target type selection
  • #125 — ONB-07 · Screen 2: artifact upload/link
  • #126 — ONB-08 · Screen 3: scan selection + scope/auth
  • #127 — ONB-09 · Screen 4: review & launch

Target-family specifics

  • #128 — ONB-10 · Firmware / Yocto (Tramiton + EMBA/binwalk)
  • #129 — ONB-11 · Mobile Android/iOS (APK/AAB/IPA)
  • #130 — ONB-12 · PLC / SPS (PLCopen XML / ST; ties CS-E1)

Migration

  • #132 — ONB-14 · Fold TrackedRepository / DastTarget into the target model

Build order: #119 then #120 and #122 in parallel, then #121, then #131; wizard #123 -> #124 -> #125 -> #126 -> #127; family specifics #128/#129/#130 after #121; #132 last.

### Sub-issues created (dependency order) **Backend foundation** - #119 — ONB-01 · Target taxonomy + unified data model - #120 — ONB-02 · Artifact ingest layer - #121 — ONB-03 · Artifact-aware classifier / auto-detection (Tramiton handoff) - #122 — ONB-04 · Scan-applicability matrix - #131 — ONB-13 · Onboarding API endpoints **Wizard UI** - #123 — ONB-05 · Wizard shell (multi-step flow/state/nav) - #124 — ONB-06 · Screen 1: target type selection - #125 — ONB-07 · Screen 2: artifact upload/link - #126 — ONB-08 · Screen 3: scan selection + scope/auth - #127 — ONB-09 · Screen 4: review & launch **Target-family specifics** - #128 — ONB-10 · Firmware / Yocto (Tramiton + EMBA/binwalk) - #129 — ONB-11 · Mobile Android/iOS (APK/AAB/IPA) - #130 — ONB-12 · PLC / SPS (PLCopen XML / ST; ties CS-E1) **Migration** - #132 — ONB-14 · Fold TrackedRepository / DastTarget into the target model **Build order:** #119 then #120 and #122 in parallel, then #121, then #131; wizard #123 -> #124 -> #125 -> #126 -> #127; family specifics #128/#129/#130 after #121; #132 last.
sharang commented 2026-07-10 10:33:12 +00:00
Author
Owner
Copy Link
Copy Source

Suite-integration workstreams added

compliance-scanner is one product in a suite; onboarding reconciles with siblings rather than duplicating them. Added three tracking issues + will build the seams (provider ports + model fields) into Steps 3–4:

  • #135 — ONB-16 · Tramiton evidence reconciliation. Shell out to tramiton detect --json; reconciliation key = firmware SHA-256 == our Artifact.content_hash; near-term reads local .tramiton/ outputs (cloud has no read API yet); entitlement via offline Ed25519 LicenseGrant. Formats already match (CycloneDX/OpenVEX).
  • #136 — ONB-17 · Compliance-scope capture + pluggable ControlsProvider (built-in OSCAL vs Benjamin's breakpilot-compliance RAG — 300k+ atomic controls from ~400 laws).
  • #137 — ONB-18 · Werkpilot remediation hook (downstream consumer; light).

Seams built now (in Steps 3–4): ExternalRef/ExternalSystem + ComplianceProfile on the target model; EvidenceProvider + ControlsProvider ports in compliance-core; a TramitonCli impl + a deterministic mock jig so CI never needs the tramiton binary; ingest computes sha256 for every blob (the tramiton match key).

### Suite-integration workstreams added compliance-scanner is one product in a suite; onboarding reconciles with siblings rather than duplicating them. Added three tracking issues + will build the seams (provider ports + model fields) into Steps 3–4: - #135 — ONB-16 · Tramiton evidence reconciliation. Shell out to `tramiton detect --json`; reconciliation key = firmware SHA-256 == our `Artifact.content_hash`; near-term reads local `.tramiton/` outputs (cloud has no read API yet); entitlement via offline Ed25519 `LicenseGrant`. Formats already match (CycloneDX/OpenVEX). - #136 — ONB-17 · Compliance-scope capture + pluggable `ControlsProvider` (built-in OSCAL vs Benjamin's breakpilot-compliance RAG — 300k+ atomic controls from ~400 laws). - #137 — ONB-18 · Werkpilot remediation hook (downstream consumer; light). **Seams built now (in Steps 3–4):** `ExternalRef`/`ExternalSystem` + `ComplianceProfile` on the target model; `EvidenceProvider` + `ControlsProvider` ports in compliance-core; a `TramitonCli` impl + a deterministic mock jig so CI never needs the tramiton binary; ingest computes sha256 for every blob (the tramiton match key).
sharang commented 2026-07-12 21:56:44 +00:00
Author
Owner
Copy Link
Copy Source

OT/ICS + embedded-Linux roadmap (from testing-strategy discussion)

Tracked extensions to the firmware/PLC path:

  • #148 — PLC/SPS dynamic testing: soft-PLC (OpenPLC) + Modbus/OPC-UA/EtherNet-IP probing (beyond static control-logic rules CS-E)
  • #149 — Embedded Linux/Yocto dynamic path: QEMU boot (runqemu / FirmAE / Firmadyne) → DAST + pentest against the live image's services
  • #150 — Bitbake/Yocto provider (tramiton coverage gap) + Yocto-native SPDX SBOM & cve-check
  • #151 — FirmwareStatic scanner: EMBA + binwalk + cve-bin-tool for firmware images (implements the #128 stub; ties CS-A2)

Testing without hardware: OpenPLC + Beremiz + GRFICS (PLC); prebuilt Yocto qemux86-64 / IoTGoat / OpenWrt in QEMU (embedded Linux).

### OT/ICS + embedded-Linux roadmap (from testing-strategy discussion) Tracked extensions to the firmware/PLC path: - #148 — PLC/SPS **dynamic** testing: soft-PLC (OpenPLC) + Modbus/OPC-UA/EtherNet-IP probing (beyond static control-logic rules CS-E) - #149 — Embedded Linux/Yocto **dynamic** path: QEMU boot (`runqemu` / FirmAE / Firmadyne) → DAST + pentest against the live image's services - #150 — **Bitbake/Yocto provider** (tramiton coverage gap) + Yocto-native SPDX SBOM & `cve-check` - #151 — **FirmwareStatic scanner**: EMBA + binwalk + cve-bin-tool for firmware images (implements the #128 stub; ties CS-A2) Testing without hardware: OpenPLC + Beremiz + GRFICS (PLC); prebuilt Yocto qemux86-64 / IoTGoat / OpenWrt in QEMU (embedded Linux).
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
P0-demo
CERTifAI P0 demo build tickets (CS-*)
 bug
critical
enhancement
epic
Tracking issue spanning multiple sub-issues
 high
infrastructure
onboarding
Multi-target onboarding wizard redesign
 performance
security
v0.3.0
No labels enhancement epic onboarding
Milestone
No items
No Milestone Onboarding v1
Projects
Clear projects
No projects
Assignees
Clear assignees
Benjamin_Boenisch sharang (Sharang Parnerkar)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sharang/compliance-scanner-agent#118