Generalise the Nexus IQ SBOM upload path beyond Go

[ModeSevenIndustrialSolutions]

Context

PR #38 introduces go_scan_mode: 'api' on sonatype-lifecycle.yaml: generate a CycloneDX SBOM, then POST it to Nexus IQ's REST API instead of running sonatype-lifecycle-scan-action.

The mechanism is Go-shaped in its naming, but nothing about it is actually Go-specific. The upload step resolves an application UUID and POSTs a CycloneDX document to sources/cyclonedx. Given a CycloneDX document, it works for any ecosystem.

If PR #38 absorbs this reshaping before merge, close this issue. It exists so the follow-up is not lost if #38 merges in its current Go-specific form.

Why it matters

We have Python and Node.js projects wanting CLM coverage. Framed as go_scan_mode, each new ecosystem needs its own bespoke branch in the lane. Framed as an ecosystem-agnostic scan_mode, they need nothing.

The generators already exist across the estate:

Ecosystem	Generator	Already used by
Go, Node.js, Java, Rust, containers	lfreleng-actions/sbom-action (syft)	go-workflows, node-workflows
Python	lfreleng-actions/python-sbom-action	python-workflows

sbom-action's README states it "[g]enerates CycloneDX Software Bill of Materials (SBOM) reports for projects in any language/ecosystem", defaults to sbom_spec_version: 1.5 (exactly what PR #38 hardcodes), and notes the interface "mirrors python-sbom-action, giving callers one contract across the actions estate".

Proposed shape

Two orthogonal inputs rather than one conflated one:

• build_type — unchanged in meaning: how dependencies get resolved before a CLI scan (none / maven / gradle / go, plus python per the linked issue)
• scan_mode: 'cli' | 'sbom' — how results reach Nexus IQ

cli stays the default. The SBOM upload has no synchronous policy verdict, so fail_on_policy_warnings, ignore_scanning_errors, ignore_system_errors and the iq_* inputs are all inert under sbom — PR #38 documents this well and that documentation should carry over.

Benefits

• Python, Node.js, Java, Rust and container coverage with no per-ecosystem branching
• Removes the hand-rolled go install cyclonedx-gomod@... step and the go_sbom_tool_version input
• Replaces a version-string pin with the SHA pinning used everywhere else in the lane
• Consistent with how the lane already composes org actions (maven-build-action, tox-run-action, build-metadata-action)

Composing an action rather than nesting a reusable workflow keeps this within the scoping rule at docs/BRIEF.md L53.

Blocked by

• Verify Nexus IQ ingestion of syft-generated CycloneDX SBOMs #39 — if syft output identifies materially worse than cyclonedx-gomod, the backend choice changes (though the generic interface may still be right, via sbom-action's backend input).

Also worth doing

• Record the decision in docs/BRIEF.md. If this lands, D20 stops being "Go gets an SBOM branch" and becomes "the lane gets an ecosystem-agnostic SBOM transport, of which Go is the first consumer" — a more durable decision to record.
• Note that sbom-action is currently v0.0.1, which is early for a security lane to depend on. Worth a conscious decision rather than an implicit one.

Related: PR #38.

[ModeSevenIndustrialSolutions]

Status update: partially absorbed by PR #38 (head cc52d5e).

What landed there:

• go_scan_mode renamed to scan_mode: 'cli' | 'sbom' — the transport axis this issue proposed, in shape (a) from the review thread (orthogonal inputs, no Go-specific target axis added yet)
• Validation updated to cli | sbom; the inert-input list in the description now also names iq_cli_version / iq_java_version / iq_java_distribution
• The lane header and D20 now state explicitly that scan_mode is not Go-specific and that only the Go path drives it today

Remaining scope of this issue (do not close on #38 merge):

1. Replace the in-lane go install cyclonedx-gomod@… step with lfreleng-actions/sbom-action — still blocked by Verify Nexus IQ ingestion of syft-generated CycloneDX SBOMs #39
2. Extend sbom mode beyond build_type: 'go' (Node.js, Java, Rust, containers via sbom-action; Python via python-sbom-action)
3. Retire the go_sbom_tool_version input once (1) lands
4. Enforce the mode/ecosystem pairing in validation: as of cc52d5e, scan_mode: 'sbom' with a non-Go build_type is accepted by validation but silently runs the CLI scan instead (the scan step's guard is build_type != 'go' || scan_mode != 'sbom'). Until sbom works everywhere, that combination should fail validation loudly rather than do something other than what the caller asked — the same reject-typos-early philosophy the existing build_type validation states. Generalising per (2) dissolves the problem; until then it is a trap. (Also flagged on the PR — if it gets fixed there, strike this item.)

One counterpoint from the PR worth carrying into this issue: the author notes go install pkg@version is checksum-verified against GOSUMDB, so it is tamper-evident once published — a weaker guarantee than a commit-SHA pin, but not equivalent to a floating @latest. The in-file comment on go_sbom_tool_version now records this and points here.