chore: bump go-FuSa pin to v0.47.0; harden fmea content-quality gate - #56
Merged
Conversation
The gofusa CLI pin was 11 minor versions behind upstream (v0.36.0 vs current latest v0.47.0). Bump both CI locations (the "gofusa" full- lifecycle job and the "compliance" standards job) to v0.47.0 and re-point the job name/comment accordingly. Verified locally against this repo's code with v0.47.0 before pushing: check/trace/cyber/vuln/qualify/verify/coverage/hara/boundary/sci/ coupling/tara/fmea/release/safety-case and all 7 standards gap reports (iso26262, iec61508, iso21434, iec62443, do178, unece, slsa) all still pass cleanly. Upgrading also fixes a real content-quality regression upstream (go-FuSa#60): dFMEA entries now vary failureMode/effect/cause text by each function's actual component/receiver/parameter shape instead of collapsing onto ~4 fixed strings (61 entries now produce 25 distinct value-sets, up from 4). That's enough headroom to safely turn on `gofusa fmea`'s -strict content-quality gate (x-FuSa spec §1.6.2) in both CI jobs as a regression guard, which this commit also does. `gofusa tara` deliberately keeps no -strict: 100% of this repo's CYBER findings are genuine CYBER009 (narrowing-conversion) hits, so tara.json's single-rule-type repetition is factually accurate rather than templated boilerplate — see go-LIN#50 for the full writeup on why an attestation isn't being fabricated here. Also confirmed a real, reproducible go-FuSa CLI bug survives the upgrade: `gofusa do178`'s text-mode summary line prints a nonsensical "-1 GAP" (the count arithmetic undercounts MANUAL objectives), while the same report's `-format json` summary counts are internally consistent. Filed upstream. Since the underlying data is fine in JSON mode, add a CI backstop to the "compliance" job that re-runs every standard's gap report through `-format json` and fails the build if any summary count is ever negative, so this class of tooling bug can't silently regress unnoticed again. Closes #53 Signed-off-by: Matt <47545907+SoundMatt@users.noreply.github.com>
Owner
Author
|
Filed upstream: SoundMatt/go-FuSa#86 (do178 text-mode summary line prints a negative GAP count; the |
SoundMatt
added a commit
that referenced
this pull request
Jul 29, 2026
#56 bumped the gofusa pin to v0.47.0 and turned on the fmea -strict content-quality gate in ci.yml's "gofusa" and "compliance" jobs, but release.yml's own "Install go-FuSa" / "Regenerate dFMEA table" steps were left on v0.36.0 without -strict — the tag-push release job that regenerates and commits safety evidence straight to main was silently out of step with the rest of the repo's pin. Bump release.yml to v0.47.0 and add -strict to its fmea step to match ci.yml's gofusa/compliance jobs, so all three workflow locations use an identical, explicit pinned version. Verified locally with go-FuSa v0.47.0: full gofusa lifecycle (check/ trace/cyber/vuln/qualify/verify/coverage/hara/boundary/sci/coupling/ tara/fmea -strict/release/safety-case/audit-pack) and all 7 standards gap reports (iso26262/iec61508/iso21434/iec62443/do178/unece/slsa) pass cleanly with 0 real gaps; go build/vet/test -race all green. Signed-off-by: Matt <47545907+SoundMatt@users.noreply.github.com>
SoundMatt
added a commit
that referenced
this pull request
Jul 29, 2026
) * feat(ci): attach SBOM/provenance/safety evidence to GitHub Releases release.yml generated SBOM, build-provenance, and other safety-case evidence on every tag push, but only ever committed those files back into git history on main. They were never uploaded as release assets, so "the SBOM for v1.3.0" had no stable, versioned, downloadable location — main's copy is regenerated and overwritten on every subsequent tag and does not correspond to any one past release. Confirmed empty asset lists on existing releases via `gh api repos/SoundMatt/go-LIN/releases/tags/v1.3.0 --jq '.assets'`. Add a step that attaches sbom.json, provenance.json, artifact-manifest.json, fmea.json, tara.json, and safety-case.json to the GitHub Release for the tag this job is running for — the standard SLSA/SBOM distribution pattern `gh release download` and SBOM scanners expect. The release for a given tag may already exist by the time this job runs (created by whatever process pushed the tag) or may not yet, so the step handles both: creates a minimal release if one doesn't already exist, then always uploads/clobbers the evidence assets. Closes #52 Signed-off-by: Matt <47545907+SoundMatt@users.noreply.github.com> * fix(ci): release.yml was missed by the go-FuSa v0.47.0 pin bump #56 bumped the gofusa pin to v0.47.0 and turned on the fmea -strict content-quality gate in ci.yml's "gofusa" and "compliance" jobs, but release.yml's own "Install go-FuSa" / "Regenerate dFMEA table" steps were left on v0.36.0 without -strict — the tag-push release job that regenerates and commits safety evidence straight to main was silently out of step with the rest of the repo's pin. Bump release.yml to v0.47.0 and add -strict to its fmea step to match ci.yml's gofusa/compliance jobs, so all three workflow locations use an identical, explicit pinned version. Verified locally with go-FuSa v0.47.0: full gofusa lifecycle (check/ trace/cyber/vuln/qualify/verify/coverage/hara/boundary/sci/coupling/ tara/fmea -strict/release/safety-case/audit-pack) and all 7 standards gap reports (iso26262/iec61508/iso21434/iec62443/do178/unece/slsa) pass cleanly with 0 real gaps; go build/vet/test -race all green. Signed-off-by: Matt <47545907+SoundMatt@users.noreply.github.com> --------- Signed-off-by: Matt <47545907+SoundMatt@users.noreply.github.com>
SoundMatt
added a commit
that referenced
this pull request
Jul 29, 2026
go-FuSa v0.47.1 (upstream go-FuSa#87) shipped a few hours after this repo's v0.47.0 pin bump (#56), and it fixes exactly the bug that #56's commit message noted was "filed upstream": do178's text-mode summary line printed a nonsensical negative GAP count while -format json's counts were correct. Re-checked latest go-FuSa release right before acting; v0.47.1 is current as of this commit. Bump all three pin locations (ci.yml's gofusa job, ci.yml's compliance job, release.yml) to v0.47.1 so they stay identical, per this repo's own established convention. Verified locally with go-FuSa v0.47.1: full gofusa lifecycle (check/ trace/cyber/vuln/qualify/verify/coverage/hara/boundary/sci/coupling/ tara/fmea -strict/release/safety-case/audit-pack) and all 7 standards gap reports pass cleanly; do178's text-mode summary now correctly prints "0 GAP" instead of "-1 GAP", confirming the upstream fix. The ci.yml JSON-summary negative-count backstop added in #56 still passes and is left in place as a defense-in-depth regression guard even though its originating bug is now fixed upstream. go build/vet/test -race all green. Signed-off-by: Matt <47545907+SoundMatt@users.noreply.github.com>
7 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
gofusaCLI from v0.36.0 to v0.47.0 (11 minor versions behind) in both.github/workflows/ci.ymllocations (thegofusafull-lifecycle job and thecompliancestandards job).-stricttogofusa fmea's content-quality gate (x-FuSa spec §1.6.2) in both jobs — safe now because go-FuSa#60 (shipped between v0.36.0 and v0.47.0) fixed dFMEA's failureMode/effect/cause generation to vary by each function's actual component/receiver/parameter shape. This repo'sfmea.jsonwent from 4 distinct value-sets across 61 entries to 25, clearing the FUSA-STUB002 blanket-fallback threshold.gofusa taradeliberately does not get-strict: 100% of this repo's CYBER findings are genuine CYBER009 (narrowing-conversion) hits, sotara.json's single-rule-type repetition is factually accurate, not templated boilerplate — full writeup in the TARA / dFMEA evidence is boilerplate: 28 threats collapse to 1 string, 61 FMEA entries collapse to 4 value-sets #50 thread.compliancejob) that re-runs every standards gap report through-format jsonand fails the build if any summary count is negative. This exists becausegofusa do178's text-mode summary line prints a nonsensical-1 GAPon this repo even on v0.47.0 (the count arithmetic undercounts MANUAL objectives) — confirmed the same report's-format jsonsummary is internally consistent, so this is a go-FuSa text-renderer bug, not a data problem here. Filed upstream.Verification (local, before push)
go build ./...,go vet ./...,go test -race -count=1 ./...— all pass (also re-run insidegolang:1.25on Linux to match theubuntu-latestrunner).gofusajob sequence (check/trace/cyber/vuln/qualify/verify/coverage/hara/boundary/sci/coupling/tara/fmea -cyber -strict/release) reproduced locally with the v0.47.0 binary — all green.compliancejob sequence reproduced locally, including all 7 standards reports (iso26262/iec61508/iso21434/iec62443/do178/unece/slsa) and the new negative-count sanity-check step — all green.Closes #53
Test plan