Engineering workflow & boundaries

How a CVE finding becomes a tested merge request.

Every case follows a five-step sequence on a pinned Yocto, Buildroot, OpenWrt, Debian/CIP, or vendor BSP baseline, separating Firmdura's preparation work from your code review, signing keys, and deployment process.

  1. Pin branch and rules

    Agree one supported branch, board config, runner setup, test suite, and written source-handling terms before access.

  2. Verify exposure

    Check build definitions, compile flags, applied patches, and target code paths to classify each CVE.

  3. Update or backport

    Apply a safe minor update or adapt the upstream security fix across diverged APIs with commit provenance.

  4. Rebuild and test

    Build candidate packages and firmware images, then run component and product regression suites against baseline.

  5. Deliver for review

    Submit the merge request, test logs, and audit notes to your queue for engineering review and image signing.

Responsibility & security matrix

Clear separation of execution and control.

Domain Firmdura executes You retain
CVE triage & repair Reachability analysis, patch backporting, package build updates, and VEX or build-metadata records (CVE_STATUS, IGNORE_CVES) Code review, architectural approval, and merge decision
Build & test runs Automated candidate firmware builds and baseline-vs-candidate regression execution Control or approval of build runners, source access, and physical hardware sign-off
Signing & release Release checklist and candidate verification bundle Signing keys, PKI, production image signing, and field / OTA rollout
CRA reporting Technical assessment, 24h / 72h draft notifications, and ENISA deadline tracking Product risk decisions and legal sign-off as manufacturer

Zero vendor lock-in: Every deliverable lives in your repository as standard Git commits, build files, patches, and plain documentation. See our 32-bit ARM CVE-2026-58470 backport walkthrough for a concrete example.

Engagement model & scope

Fixed commitments, scoped per configuration.

Stage 01 · Fixed fee

Baseline & initial cases

Three upstream-backed user-space CVE cases on one pinned firmware configuration (Yocto, Buildroot, OpenWrt, or Debian/CIP), selected from your backlog.

  • Sets up reproducible build and regression checks in your environment
  • Deliverables, acceptance tests, rework boundaries, and price fixed up front
  • Ends with a review checkpoint before ongoing commitment
Stage 02 · Per configuration

Ongoing lifecycle maintenance

Continuous CVE triage, patch adaptation, candidate builds, regression evidence, and CRA Article 14 reporting.

  • Fixed fee per supported branch and hardware configuration
  • Scaled transparently by configuration count, test depth, and reporting scope
  • Kernel upgrades and OS migrations quoted as separate fixed projects

Scope a firmware baseline.

Review your build stack, runner setup, and open maintenance backlog directly with our engineering team.