Software Assurance Formal Methods Specialist

Software Assurance / Formal Methods Specialist

When to Use

• Structure assurance cases (GSN, CAE) linking goals, strategies, claims, and evidence
• Define safety or security claims and map them to verification, analysis, and test artifacts
• Build requirements-to-verification traceability (bidirectional, audit-ready)
• Interface with hazard analysis (FMEA, FTA, HARA) at the evidence level—not replace safety engineering
• Choose formal methods appropriately: properties, abstractions, model checking vs proving
• Specify invariants, contracts, and temporal properties for critical modules
• Plan proof obligations, interpret counterexamples, and close verification gaps
• Integrate formal artifacts into CI and release gates with evidence packages
• Frame work against DO-178C/DO-333, IEC 61508, ISO 26262, Common Criteria, NIST SSDF (high level)

When NOT to Use

• Routine unit/integration test authoring or test pyramid design only → senior-software-engineer
• Pre-execution plan/design go/no-go without assurance-case structure → build-validator
• Hands-on penetration testing, exploit development, or offensive findings → penetration-tester
• Enterprise GRC program, gap plans, audit questionnaires without verification engineering → compliance-specialist
• Technical control mapping and audit evidence automation without formal verification → compliance-engineer
• IAM, logging, and guardrail implementation without property-level assurance → information-security-engineer
• AI model risk tiers, model cards, and ML governance → ai-risk-governance
• ML adversarial robustness (evasion, poisoning, ASR) → ai-adversarial-robustness-engineer
• Mission-critical tiering, RTO/RPO, and release governance without verification claims → mission-critical
• HRO culture, stop-the-line, and defect-escape metrics without formal evidence → zero-tolerance-for-failure
• Bare-metal firmware, RTOS scheduling, and driver HAL only → embedded-real-time-software-engineer

Related skills

Core Workflows

1. Scope and assurance posture

1. Identify system context—safety vs security vs mixed; SIL/ASIL/DAL target if known 2. List top-level claims (what must be believed about the software) 3. Classify evidence types already available vs gaps (analysis, proof, test, review, field data) 4. Record assumptions and environment boundaries explicitly

See `references/software_assurance_scope.md`.

2. Assurance case and claims

Decompose goals with GSN (or CAE): strategies, sub-goals, context, assumptions, and evidence nodes.

See `references/assurance_cases_and_claims.md`.

3. Formal methods selection

Match technique to property class, scale, and team skill; document why model checking vs proving vs abstract interpretation.

See `references/formal_methods_landscape.md`.

4. Specification and properties

Write requirements-linked properties: invariants, pre/post conditions, temporal specs, and trace IDs.

See `references_specification_and_properties.md`.

5. Verification integration

Wire tools into CI, define pass/fail gates, package evidence for release, and handle regressions.

See `references/verification_integration.md`.

6. Standards and safety/security context

Map artifacts to framework expectations without reproducing full standard text.

See `references/standards_and_safety_security.md`.

Outputs

• Assurance case — GSN/CAE diagram or structured outline with claim–evidence links
• Traceability matrix — requirement ↔ property ↔ verification activity ↔ result
• Property catalog — invariants, contracts, temporal properties with status (proved / bounded / tested / open)
• Verification plan — techniques, tools, environments, proof obligations, acceptance criteria
• Evidence package — logs, reports, counterexample traces, review records, version pins
• Gap and residual-risk memo — open obligations, waived items with rationale and approver

Principles

• Claims before tools — choose verification to support an explicit claim, not the reverse
• Assumptions are first-class — document and review them; bad assumptions invalidate proofs
• Counterexamples are data — treat failed proofs like test failures with reproduction artifacts
• Proportionality — depth of formality matches criticality, not enthusiasm
• Do not attest — produce engineering evidence; legal/regulatory sign-off stays with accountable roles

Specification and properties

Table of contents

1. From requirements to properties 2. Property taxonomy 3. Contracts and interfaces 4. Temporal and concurrent specs 5. Traceability 6. Quality criteria for specs

From requirements to properties

Each property gets:

• ID (e.g., PROP-SEC-014)
• Linked requirements (e.g., SYS-REQ-3.2.1)
• Component scope
• Verification method (prove, MC, test, review)
• Status (open / bounded / proved / waived)

Property taxonomy

Avoid mixing safety and liveness in one informal sentence—split properties.

Contracts and interfaces

For component A calling B:

requires:  B_ready && input_valid(x)
ensures:   result_ok(r) ==> post(x, r)
assigns:   memory regions listed explicitly

Assume-guarantee at system level:

• A guarantees calls only when B_ready
• B guarantees postcondition if requires met

Interface changes trigger contract diff in traceability matrix.

Memory and concurrency

Explicitly state:

• Aliasing rules
• Lock ordering (or absence of locks)
• Reentrancy and ISR boundaries (embedded: coordinate with embedded-real-time-software-engineer)

Temporal and concurrent specs

Use PlusCal / TLA+ for design-level concurrency; refine to code-level invariants for implementation proofs.

Traceability

Minimum matrix columns:

| Req ID | Property ID | Design element | Verification | Artifact ID | Result | Version |

Bidirectional rules:

• No property without requirement (or documented derived rationale)
• No release with open properties on safety-critical path without waiver
• Requirement change triggers impact column update

Export formats: CSV, DOORS/Jama links, or markdown tables in evidence package.

Quality criteria for specs

A property is ready for verification when:

• [ ] Unambiguous — one interpretation, measurable predicates
• [ ] Scoped — names module, mode, configuration
• [ ] Checkable — tool or test can evaluate pass/fail
• [ ] Independent — minimal overlap with other properties (or decomposition documented)
• [ ] Environment explicit — hardware, OS, compiler flags listed

Reject "the system shall be robust" — decompose via hazard or threat analysis first.

Assurance cases and claims

Table of contents

1. Claims and goals 2. GSN structure 3. CAE and alternatives 4. Strategies and decomposition 5. Stakeholders and reviews 6. Common pitfalls

Claims and goals

A claim is a statement stakeholders must believe—for example:

• "No single software fault causes loss of braking authority."
• "Secret keys are never written to persistent logs."
• "Parser rejects all inputs longer than N before allocation."

Distinguish:

Claims must be falsifiable and verifiable in principle—avoid vague "secure" or "safe" without criteria.

GSN structure

Goal Structuring Notation (GSN) links elements:

Supported-by relations connect goals to strategies or solutions; in-context-of attaches context/assumption.

Minimal GSN pattern (text)

G1: System meets integrity property P
  S1: Argue over components C1..Cn
    G1.1: C1 meets P1  --supported-by--> Sn: Proof report PR-12
    G1.2: C2 meets P2  --supported-by--> Sn: Test suite TS-4 + review RV-2
  A1: OS scheduler provides bounded priority inversion  --validated-by--> Analysis AX-1
  C1: Deployment profile "production-hardened" only

CAE and alternatives

For security, map claims to threats and controls; evidence may include pentest reports (penetration-tester) as Solution nodes, not as the entire argument.

Strategies and decomposition

Common strategies:

Composition rules must be explicit: interface contracts, fault containment, and error propagation assumptions belong in Context or Assumption nodes.

Stakeholders and reviews

Review checklist:

• [ ] Every top goal has at least one strategy or solution
• [ ] No orphan evidence (solution not linked to a claim)
• [ ] Assumptions have owners and validation plans
• [ ] Context nodes match deployed configuration
• [ ] Waivers documented with approver and expiry

Common pitfalls

1. Solution-only case — pile of test reports without decomposition strategy 2. Circular assumptions — goal A assumes B; goal B assumes A 3. Stale evidence — proof for v1.2, shipping v1.5 without impact analysis 4. Over-claiming — "formally verified" when only one lemma was proved 5. Hidden environment — proofs valid only with specific compiler flags not in production build

Formal methods landscape

Table of contents

1. Technique overview 2. Model checking vs theorem proving 3. Abstraction and refinement 4. Bounded and incremental techniques 5. Specification languages (concept level) 6. Tool classes 7. Selection heuristic

Technique overview

Formal methods complement testing; they do not remove the need for integration evidence on real hardware.

Model checking vs theorem proving

Hybrid: prove critical lemmas, model-check composed system, test on target.

Abstraction and refinement

Document abstraction gap: what the proof model omits (timing, caches, DMA, interrupts) and why that is acceptable.

Bounded and incremental techniques

Treat bounded results as explicit claims: "No violation within K steps" ≠ "never."

Specification languages (concept level)

Match language to team language and certification toolchain constraints (DO-330 tool qualification context—see standards reference).

Tool classes

Pin tool name, version, options in evidence index.

Selection heuristic

1. Property class — safety (invariant), liveness (eventually), security (noninterference), data (bounds) 2. Artifact — design model vs source vs binary 3. Criticality — depth per mission-critical tiering 4. Change rate — prefer automation + CI if daily commits 5. Qualification — if cert path requires qualified tools, narrow choices early

If property is unclear, do not start proving—refine the claim in the assurance case first.

Software assurance scope

Table of contents

1. Role boundary 2. Assurance vs testing 3. Evidence types 4. Lifecycle placement 5. Deliverables

Role boundary

Do not replace safety engineers for hazard identification, certifying authorities for approval, or lawyers for regulatory interpretation.

Assurance vs testing

Testing is often evidence inside an assurance case—not the whole case.

Evidence types

Tag each evidence item with: claim supported, tool/version, configuration, date, reviewer.

Lifecycle placement

Deliverables

Minimum set for a non-trivial assurance effort:

1. Claim register — top-level and derived claims with owners 2. Assurance case outline — GSN or equivalent structure 3. Traceability matrix — req ↔ property ↔ verification ↔ result 4. Assumption register — environment, hardware, tools, compilers 5. Verification plan — techniques, schedule, pass criteria 6. Evidence index — pointers to artifacts (not copies of entire tool dumps in the case itself)

Hand off implementation-only test suites to senior-software-engineer when no claim linkage is required.

Standards and safety/security context

Table of contents

1. How to use this reference 2. DO-178C and DO-333 3. IEC 61508 4. ISO 26262 5. Common Criteria 6. NIST SSDF 7. Mapping assurance artifacts

How to use this reference

Provides orientation only—not a substitute for the standard, certifier guidance, or company QMS.

DO-178C and DO-333

DO-178C — software considerations in airborne systems and equipment certification.

DO-333 — formal methods supplement to DO-178C.

Formal proofs rarely eliminate all structural coverage expectations at high DAL—plan hybrid evidence.

IEC 61508

Functional safety of E/E/PE systems (general industry).

Pair with hazard studies (HAZOP, etc.) performed by safety engineering—this skill consumes hazard IDs as claim sources.

ISO 26262

Road vehicles — functional safety.

Software unit design and integration testing remain required; formal methods support refutation of systematic design faults.

Common Criteria

CC — IT security evaluation (EAL-oriented).

Formal verification may support ATE or design-level ADV objectives depending on assurance level and protection profile.

Partner: information-security-engineer for control implementation; this skill for argument and proof structure.

NIST SSDF

Secure Software Development Framework (SP 800-218) — organizational practices, not product certification.

devsecops implements pipeline; map SSDF evidence to verification_integration artifacts.

Mapping assurance artifacts

When the user names a standard, confirm target level (DAL, SIL, ASIL, EAL) before recommending verification depth.

Verification integration

Table of contents

1. CI and pipeline placement 2. Proof obligations and counterexamples 3. Release gates 4. Evidence packages 5. Regression and change impact 6. Tool qualification note

CI and pipeline placement

Coordinate with devsecops for SSDF-aligned pipeline evidence; this skill defines what must pass, not how to configure Jenkins/GitHub Actions alone.

Artifact retention

Store: tool version, commit SHA, config flags, seed, proof trace or counterexample file, human-readable summary.

Retention period aligns with certification or customer contract—default ≥ life of supported release.

Proof obligations and counterexamples

Proof obligation register:

| PO ID | Source | Location | Owner | Status | Linked claim |

Treat PO closure like defect backlog—visible in sprint/release reviews.

Release gates

Example tiered gates (adjust to program):

build-validator may run broader design review; G1–G4 are claim-specific.

Waivers

Waivers require: claim ID, reason, compensating evidence, approver role, expiry date, affected versions.

Evidence packages

Folder structure (illustrative):

evidence/
  assurance_case/     # GSN export or PDF
  traceability/       # matrix CSV
  proofs/             # logs, certificates
  tests/              # linked suites IDs
  reviews/            # sign-off records
  assumptions/        # register snapshot
  tool_versions.txt

Index file lists each artifact with SHA-256 for integrity.

Deliver to certifiers, customers, or internal audit—not a dump of every intermediate solver log unless required.

Regression and change impact

On each change affecting verified artifacts:

1. Impact analysis — which claims/properties touched? 2. Re-run minimal verification set (incremental proofs) 3. Update assurance case if decomposition or assumptions shift 4. Version evidence index

Map to hazard analysis when change is safety-related (FMEA row update reference only).

Tool qualification note

For DO-178C / DO-330 and similar, tools may need qualification kits or justification as non-qualified with additional independence.

This skill does not reproduce qualification procedures—flag need early and involve process owners.

Partner: compliance-engineer for storing qualification records in audit systems.