GitOps for Safety‑Critical Software: Integrating RocqStat and Static Timing Analyses into PR Workflows
gitopsembeddedsafety

GitOps for Safety‑Critical Software: Integrating RocqStat and Static Timing Analyses into PR Workflows

UUnknown
2026-02-11
10 min read
Advertisement

Practical GitOps patterns to embed RocqStat WCET checks into PR workflows, automate artifact promotion, and create tamper‑evident audit trails for safety‑critical embedded systems.

Hook: When a timing regression can cost millions, why leave WCET to the release day?

Embedded teams building safety‑critical systems (automotive, avionics, industrial controls) face a unique pain: functional tests can pass, CI greenlights a merge, and only later a timing or worst‑case execution time (WCET) analysis reveals a critical regression. In 2026, with regulators and OEMs demanding stronger evidence for timing safety, this risk is unacceptable. This guide shows practical GitOps patterns to embed static timing analysis (RocqStat/WCET) into pull request (PR) workflows, automate artifact promotion, and create tamper‑evident audit trails that satisfy safety and compliance reviewers.

Why timing analysis must be part of GitOps in 2026

Two industry trends make timing checks in GitOps non‑negotiable:

  • Regulatory and OEM pressure: Automotive and aerospace stakeholders increasingly require documented evidence that software meets timing budgets. Late 2025 and early 2026 saw tighter supplier requirements for WCET traceability.
  • Tool consolidation: Vector Informatik's January 2026 acquisition of RocqStat (StatInf) signals a push to unify WCET and verification workflows into toolchains like VectorCAST—making integration into CI/CD more accessible and enterprise‑friendly.
Vector said the RocqStat team will accelerate innovation in timing analysis and analytics while integrating with VectorCAST to create unified timing and test workflows.

For DevOps and embedded teams, the implication is clear: integrate timing analysis early, often, and in a verifiable way. GitOps—declarative infrastructure and manifest‑driven deployments reconciled by controllers like Argo CD or Flux—gives us tight control over deployment artifacts and auditability. The challenge is adding heavyweight, deterministic timing checks (like RocqStat) into GitOps without blocking developer velocity.

Design principles for embedding timing and safety checks

Use these guiding principles when building PR workflows that include timing analysis:

  • Fast feedback first: Run lightweight, incremental timing regressions on every PR to catch obvious regressions early.
  • Heavy analysis on merge pipelines: Reserve full WCET runs (global path analysis, microarchitectural modeling) to post‑merge or scheduled pipelines on dedicated runners.
  • Deterministic artifacts: Produce reproducible, signed binaries with recorded build provenance (compiler flags, toolchain versions, link maps).
  • Promotion and attestations: Only deploy artifacts that carry a verified attestation showing they passed timing and safety gates.
  • Auditability: Record tool versions, RocqStat configurations, and results in immutable logs (Rekor, SLSA provenance, in‑toto).

Practical GitOps patterns to integrate RocqStat and static timing analyses

Below are battle‑tested patterns you can apply incrementally. They assume you have a CI system (GitHub Actions, GitLab CI, Jenkins X) and a GitOps controller for deployments.

1) Two‑stage PR pipeline: quick checks + gated full analysis

Split timing verification into two stages:

  1. PR precheck (fast): Build with a deterministic toolchain and run RocqStat in a fast mode or run function‑level micro‑analyses for changed modules only. Goal: surface local regressions in seconds–minutes.
  2. Merge/post‑merge full WCET: After merge, run a full WCET pass on the canonical build to produce certified results and create signed attestations used for artifact promotion.

Benefits: developers get fast feedback without blocking merges on long analyses; the team still gets full, auditable WCET certificates before an artifact reaches staging/certified environments.

2) Change‑set focused analysis

RocqStat supports focused analyses if you provide call graphs and function boundaries. Automate detection of modified functions and run WCET analysis scoped to impacted code paths.

Pattern:

  • On PR, compute changed files/functions via git diff and a symbol map.
  • Run incremental RocqStat on those functions and their callers/callees (bounded depth).
  • Report delta WCET and highlight potential chain reactions (callers that might exceed budgets).

3) Threshold gates and severity levels

Not every microsecond increase warrants a block. Use configurable thresholds for PR checks vs. merge gates:

  • Informational: less than X% increase or
  • Warning: between X and Z — require reviewer acknowledgement and a regression test.
  • Blocker: above Z or exceeds a critical task budget — fail CI and require mitigation.

Embed thresholds in the repo as code so they are versionable and auditable.

4) Artifact promotion with attestation and immutable registries

Create a promotion pipeline that only moves artifacts between GitOps environments (dev → integration → staging → certified) when they carry signed attestations proving they passed timing and safety checks.

Components:

  • Reproducible build artifact (static binary or firmware image) stored in an OCI registry or artifact repository with immutable tags.
  • Attestation generated by the WCET job (e.g., in‑toto predicate or SLSA provenance) signed with a repository key or cosign.
  • Promotion controller (GitOps operator) that checks the presence and validity of attestations before updating the environment manifests. See how document lifecycle systems validate records in practice: comparing CRMs for full document lifecycle management.

5) Tamper‑evident audit trail

For compliance audits you need proof of who ran analyses, which tool versions, and the exact inputs. Combine these:

  • Sign build artifacts with cosign (sigstore project) and push entries to Rekor.
  • Emit an in‑toto attestation containing a RocqStat run summary, toolchain digest, and link map digest (in‑toto predicate examples).
  • Record the CI run ID, runner identifier, and Git commit in SLSA‑level provenance stored alongside the artifact.

When auditors ask for evidence, you can present the artifact hash, the attestation, and a Rekor entry proving the attestation existed at a point in time.

Example: GitHub Actions workflow pattern

The following pattern shows a compact PR precheck and a post‑merge full run. Replace tool commands with your RocqStat/VectorCAST CLI calls and adjust runner sizes for heavy analysis.

name: wcet-pipeline

on:
  pull_request:
    types: [opened, synchronize, reopened]
  push:
    branches: [main]

jobs:
  pr-quick-check:
    runs-on: ubuntu-22.04
    if: github.event_name == 'pull_request'
    steps:
      - uses: actions/checkout@v4
      - name: Install toolchain
        run: ./ci/install-toolchain.sh
      - name: Build deterministic artifact
        run: make reproducible-build
      - name: Compute changed functions
        run: ./ci/changed-functions.sh > changed.txt
      - name: Quick RocqStat run (incremental)
        run: rocqstat --incremental --input changed.txt --output pr-report.json
      - name: Post results as PR check
        run: ./ci/post-pr-check.py pr-report.json

  full-wcet-on-merge:
    runs-on: self-hosted-wcet
    needs: [pr-quick-check]
    if: github.event_name == 'push'
    steps:
      - uses: actions/checkout@v4
      - name: Full deterministic build
        run: make reproducible-build
      - name: Full RocqStat WCET
        run: rocqstat --full --config tools/rocq-config.yml --output wcet-full.json
      - name: Sign artifact and attestation
        run: |
          cosign sign --key ${{ secrets.COSIGN_KEY }} artifact.bin
          ./ci/generate-in-toto-attestation.py wcet-full.json > attestation.json
          cosign sign-blob --key ${{ secrets.COSIGN_KEY }} --output attestation.sig attestation.json
      - name: Upload artifact + attestation to registry
        run: ./ci/push-artifact.sh artifact.bin attestation.json attestation.sig

Key ideas: keep PR runs lightweight, perform full WCET on canonical images, and attach signed attestations to artifacts used in GitOps deployments.

Integrating with GitOps controllers and promotion logic

Make your GitOps controller (Argo CD / Flux) require artifact attestations before it reconciles a new manifest:

  • Use a GitOps pre‑sync hook that validates attestation signatures against Rekor and the expected RocqStat signature identity.
  • Block reconciliation for artifacts without valid attestations.
  • Store environment promotion state (artifact hashes + attestation metadata) in a GitOps manifests repo so promotion itself is a Git operation.

This converts deployment promotion into a traceable Git commit: the single source of truth for which artifacts are allowed in each environment.

Timing regression tests: automation and interpretation

Automate regression tests that map WCET values to requirements:

  • Baseline capture: After a certified build, store baseline WCET numbers per entry point with metadata (tool version, CPU model, build ID).
  • Delta detection: Compare PR or post‑merge WCET runs to the baseline; compute absolute and percentage deltas.
  • Root cause assist: When deltas occur, automatically extract call stacks and changed symbols, attach compiler/linker maps, and highlight likely causes (inlining, added loops, changed compiler flags).

Store results in a time series DB (TimescaleDB, Prometheus+Loki) to visualize trends and trigger alerts when long‑term drift is detected.

Provenance: recording the exact environment that produced results

WCET is sensitive to the toolchain and hardware model. For each run record:

  • RocqStat version and configuration file hash.
  • Compiler version, flags, and full command‑line recorded.
  • Link map and symbol table digests.
  • Hardware model used for microarchitectural modeling (pipeline, cache sizes, clock settings).
  • CI runner id, OS image digest, container image digest (record these as part of your secure CI practice: security best practices).

Embed these details into the in‑toto predicate. This data is crucial for audits and for reproducing a problematic run months or years later.

Compliance and safety standards alignment

Mapping your GitOps/CI artifacts to standards is necessary for certification:

  • ISO 26262 (automotive): link WCET evidence back to safety requirements and show traceability from requirements → code → timing proof.
  • DO‑178C (avionics): preserve tool qualification info and ensure tool versioning and deterministic invocation are part of the build record.
  • IEC 61508 (industrial): keep an immutable audit trail for timing analyses and mitigation decisions.

RocqStat outputs and classifier data are commonly accepted as part of timing evidence; keep them signed and stored with your artifacts.

Scaling strategies and cost control

Full WCET runs are compute‑intensive. Use these strategies to scale:

  • Cloud burst runners: Run heavyweight analysis on spot or preemptible instances scheduled via your CI's autoscaling pool.
  • Incremental caching: Cache intermediate RocqStat artifacts keyed by function object digests so repeated runs reuse previous analyses.
  • Prioritization: Run full WCET on release branches and high‑risk PRs only; use sampling and statistical warnings for low‑impact changes.

Also run a simple cost analysis to understand compute tradeoffs and justify burst capacity.

Expect these trends and techniques to mature in 2026:

  • Tighter toolchain integration: Vector's acquisition of RocqStat will accelerate vendor toolchain integration (VectorCAST + RocqStat), providing smoother CI hooks and standardized output schemas for attestations.
  • AI‑assisted triage: Emerging tools analyze change sets and historical WCET data to recommend which code paths to analyze first, reducing wasted runs.
  • Standardized predicates: Industry groups are converging on standard in‑toto predicates for timing analysis results which improves cross‑vendor auditability (analytics and predicate standardization).
  • SLSA adoption upstream: More embedded teams will require SLSA provenance for firmware artifacts as part of supplier contracts.

Checklist: What to implement in the next 90 days

  1. Enable deterministic builds and capture a reproducible artifact for every PR.
  2. Create a lightweight RocqStat incremental job in PRs that returns pass/warn/fail and posts results to the PR.
  3. Add a post‑merge full WCET job that produces a signed attestation and stores it in the artifact registry.
  4. Configure your GitOps controller to validate attestations before deploying to staging/certified environments.
  5. Start recording baseline WCET numbers and build provenance in a time series DB for trend analysis.

Common pitfalls and how to avoid them

  • Pitfall: Blocking all merges on full WCET runs. Fix: use the two‑stage pattern and thresholds to balance safety and velocity.
  • Pitfall: Missing tool version data in attestations. Fix: always include tool and runner digests in the in‑toto predicate.
  • Pitfall: Unreproducible builds leading to invalid WCET runs. Fix: enforce pinned compiler toolchains and capture build containers as digest‑addressable images.

Case study snapshot (anonymized)

An automotive supplier adopted a GitOps promotion flow with RocqStat integrated into CI in Q4 2025. They implemented PR incremental WCET checks and post‑merge full runs. The result over six months:

  • 40% fewer late‑stage timing defects.
  • 30% reduction in costly re‑certification cycles due to earlier detection of timing regressions.
  • Audit time for timing evidence fell from days to hours because artifacts and attestations were versioned and signed.

Actionable takeaways

  • Embed ROCQ/WCET runs into PRs for fast feedback but run full, auditable WCET jobs on canonical artifacts post‑merge.
  • Use signed attestations and immutable registries to enable safe artifact promotion in GitOps workflows.
  • Record full provenance (tool versions, build environment, map files) in in‑toto/SLSA predicates for compliance readiness.
  • Automate regression triage to reduce the cost of heavy WCET runs and keep developer velocity high.

Next steps and call to action

If your team is ready to turn WCET from a release‑day surprise into an integrated, auditable part of your GitOps pipeline, start with the 90‑day checklist above. Newworld.cloud helps embedded teams design reproducible builds, implement RocqStat CI integrations, and configure artifact promotion with cosign/in‑toto and GitOps controllers. Reach out for a consultation or download our GitOps + Timing checklist to get a templated GitHub Actions pipeline and in‑toto predicate examples.

Advertisement

Related Topics

#gitops#embedded#safety
U

Unknown

Contributor

Senior editor and content strategist. Writing about technology, design, and the future of digital media. Follow along for deep dives into the industry's moving parts.

Advertisement
2026-02-22T04:15:01.312Z