TürkçeDemo
Menu

Procedure

Submit a CycloneDX document and obtain a traceable policy decision

Prepare an API token and project scope, submit with Kubaba CLI, wait for asynchronous evaluation, and verify the PASS/WARN/BLOCK result.

Content statusVerified in sourceDocumentation versionLatest
Smart Kubaba Scan History with project, component, finding, status, and policy decisions
Scan History presents component and finding counts plus PASS or BLOCK outcomes for CLI submissions with environment and source metadata.

Role and prerequisites

The token owner must retain CreateScan, UploadSbom, and ViewScan; add RunScanReevaluation when needed and CreateScanProject only for the explicit project-creation flow.

  • OSV bootstrap must be successful and the target organization/project active.
  • CycloneDX JSON must be version 1.5 or newer, and the client must reach the backend with TLS verification.
  • The token is shown only once; store it in a CI secret manager and provide it through KUBABA_TOKEN.

Procedure steps

  1. Create a token with the narrowest required scopes on API Tokens, store the complete value securely, and confirm it cannot be recovered after closing the creation dialog.
  2. Use kubaba config set to persist only non-secret settings such as server, project, organization, timeout, and output; confirm kubaba config view never prints token material.
  3. Run kubaba sbom scan <file> for an existing SBOM or kubaba audit <path> for a source tree. If an absent project must be created explicitly, use --create-project with a project key.
  4. Observe the CLI creating the scan, streaming the SBOM with a checksum, waiting for terminal state after completion, and reading the latest policy result.
  5. In Scans > detail, verify Overview, Components, Dependencies, Findings, Policy, and SBOM tabs, plus environment, branch, commit, and unresolved counts.

Success criteria

  • The scan reaches Completed; raw SBOM checksum and size metadata are visible without exposing the storage key.
  • Components and dependency edges are paginated, and findings link to OSV advisory and fixed-version evidence.
  • Without unresolved components, applicable policies produce PASS, WARN, or BLOCK; BLOCK maps to CLI exit code 1, while WARN fails only with fail-on-policy.
  • Re-uploading the same checksum to the same scan is idempotent as a duplicate, and repeated completion does not create another initial job.

Failure and security boundaries

  • An invalid bearer token never falls back to a browser session and is rejected with 401. Tokens are not written to logs, URLs, config files, or child-process environments.
  • Malformed, checksum-mismatched, unsupported, or oversized SBOMs are rejected and temporary storage objects are cleaned up.
  • Unsupported ecosystems, invalid versions, or unresolved ranges appear as NOT_EVALUATED and are not treated as vulnerability-free.
  • --create-project never silently changes an existing organization, populated branch or repository URL, or inactive project.