Repository navigation
feat: bring FuSaOps' own artifacts into x-FuSa spec v1.14.0 conformance - #84
Merged
Merged
Conversation
…a spec v1.14.0 conformance Dogfoods the schema work from spec v1.13.0/v1.14.0 against FuSaOps' own evidence artifacts. Also fixes a real, pre-existing bug: every Hash field across fmea/tara/safetycase/sas/sci/qualify emitted bare hex instead of the sha256:-prefixed form spec section 2.7 requires for a field named hash. - New shared Canonicalize (RFC 8785) in the root package, replacing each package's fixed-struct-order computeHash. - hara: SafetyGoal.fssrRef (space-delimited string) promoted to fssrRefs []string (MUST, >=1 entry) per section 1.2.5. - fmea: entries/failureMode/item/actionPriority/mitigations/ requirementIds/ratingScale/summary per section 9.2. - tara: threats/threat/attackFeasibility/mitigations renamed; impact is now an SFOP object (safety/financial/operational/privacy) per ISO 21434 Clause 15.7 instead of one generic severity. - safetycase: adds a GSN (Goal Structuring Notation v3) nodes/edges/ completeness projection alongside the existing claims/evidence model. - sas: adds checklist/summary (section 9.3) alongside activities. - sci: adds artifacts[] (file/hash/version, section 9.3) alongside items[]. - Regenerated fmea.json/tara.json/safety-case.json against the new code (all three were badly stale). fmea.csv/tara.md/safety-case.md/ .mermaid have no current code path producing them; left untouched. - 7 new requirements registered. Signed-off-by: SoundMatt <SoundMatt@users.noreply.github.com>
| return buf.Bytes(), nil | ||
| } | ||
|
|
||
| func writeCanonical(buf *bytes.Buffer, v interface{}) error { |
|
|
||
| //fusa:test REQ-FO-CORE008 | ||
| func TestCanonicalizeInvalidJSON(t *testing.T) { | ||
| if _, err := Canonicalize([]byte(`not json`)); err == nil { |
| } | ||
| buf.WriteByte('}') | ||
| default: | ||
| return fmt.Errorf("canonjson: unsupported type %T", v) |
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
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
Follows the three spec PRs earlier this session (v1.12.0 → v1.14.0, formalizing HARA/FMEA/TARA/safety-case/SAS/SCI schemas, a content-quality baseline, detection heuristics, and attestation). This PR dogfoods that work: FuSaOps develops itself as an ISO 26262 ASIL-C tool and ships its own
.fusa-hara.json/fmea.json/tara.json/safety-case.json— this brings those six packages into conformance with the schemas just written, and fixes two real pre-existing bugs found by reading the actual generated output against the spec.Real bugs fixed along the way:
Hashfields emitted bare hex, notsha256:-prefixed, acrossfmea/tara/safetycase/sas/sci/qualify— spec §2.7 requires the prefix for any field namedhash(as opposed tosha256, which stays bare). Fixed all six.hara.go'sfssrRefwas a space-delimited string cramming multiple requirement ids into one field instead of a real array — promoted tofssrRefs []string(now MUST, ≥1 entry per §1.2.5), closing a real ISO 26262-8 Clause 6 traceability gap. Migrated.fusa-hara.json's 5 safety goals in place (all 11 referenced ids already resolved correctly, zero risk).fmea.json/tara.json/safety-case.jsonwere badly stale — pre-dating even the previous schema by several tool generations (fmea.json/tara.json had a completely unrelated{format, generated_at, module, entries}shape). Regenerated against the new code.Canonicalize(RFC 8785 JSON Canonicalization Scheme) in the root package replaces six near-identical, fixed-struct-ordercomputeHashcopies with one genuinely deterministic canonicalizer — also now backsqualify's hash.Schema conformance (each package, per x-FuSa spec §9.2/§9.3):
fmea:entries[]/failureMode/item/actionPriority/mitigations/requirementIds/ratingScale/summary. Each of the 8 failure modes now links to the real FuSaOps requirement its corrective action lives in.tara:threats[]/threat/attackFeasibility;impactis now an SFOP object (safety/financial/operational/privacy, ISO 21434 Clause 15.7) instead of one generic severity — each of the 8 scenarios re-rated per-axis, not copy-pasted.FeasibilityVeryLowcorrectedvery_low→very-low.safetycase: adds a GSN (Goal Structuring Notation v3)nodes/edges/completenessprojection alongside the existingclaims/evidence model (a faithful re-expression, not a rewrite — same file-existence+SHA-256 logic, just also expressed as goal→strategy→solution nodes).sas/sci: additivechecklist/summaryandartifacts[]projections alongside their existing richer models.For
safetycase/sas/sciI took the conservative path — add the spec-required projection as new fields, keep the existing (well-tested, working) model untouched — rather than deleting/renaming it, since the existing logic wasn't wrong, just missing the spec's specific field names. This meant zero existing test changes for those three packages.Test plan
go build ./.../go vet ./.../gofmt -l .— cleango test ./...— all packages pass, zero regressionsfmea.json/tara.json/safety-case.jsonvia the real built binary and manually inspected the output.fusa-hara.jsonmigration verified: all 5 safety goals'fssrRefsstill resolve into.fusa-reqs.json