Embedded Linux · CVE Remediation · FDA §524B
Close the vulnerabilities in your embedded Linux device: kernel, OS, and application stack.
Backport Security remediates security findings across the whole device: the Linux kernel and BSP, OS packages, and application code in C/C++, Python, and C#. I close the CVEs, perform the upgrades, and turn the fixes into submission-ready FDA premarket (524B) evidence, without stalling the release.
An embedded Linux security expert. Independent, hands-on, direct. No layers, no handoffs.
Standards, formats, & tooling I work in
- CycloneDX
- SPDX
- VEX
- CISA KEV
- CWE
- IEC 62304
- Yocto
- GitLab CI/CD
- Black Duck
- FOSSA
The Problem
The software works. The cybersecurity submission is a different discipline entirely.
Most teams shipping a connected medical device hit the same four walls. Backport Security sits exactly in that seam: the one place most consultancies can’t.
- SBOM The SBOM is incomplete.
- CVEs CVEs pile up faster than anyone can triage them.
- KERNEL The kernel and supporting assets are years behind upstream.
- LANGUAGE The build team doesn’t speak FDA. The regulatory team can’t read a CVE.
Services
Three places I do the actual work.
The build-level remediation and the regulatory evidence, in the same hands.
- 01
Embedded Linux & Cross-Stack Vulnerability Remediation
Getting a device back to a documented patch posture is the hard, unglamorous work. I remediate findings across the whole stack: the Linux kernel and BSP, OS packages and userland, the build system (Yocto/BitBake), and application code in C/C++, Python, and C#. Backports, version upgrades, and end-of-life migrations included.
This is where a clean scan actually comes from.
- 02
FDA Premarket Cybersecurity (Section 524B)
Submission-ready cyber documentation built to survive reviewer scrutiny: SBOM (CycloneDX/SPDX), CVE triage and exploitability analysis, VEX and affected-status justifications, remediation evidence, and the risk rationales reviewers ask for.
Had a submission held up on cybersecurity, or want to make sure it won’t be? Start here.
- 03
SBOM & Vulnerability-Management Tooling
Stop drowning in false positives. Custom automation across Black Duck, FOSSA, and CISA KEV to normalize SBOMs, cut embedded noise, and scale CVE triage, wired into your GitLab CI/CD.
Evidence regenerates with every build instead of being rebuilt by hand before every audit.
How I work
From open findings to submission-ready evidence.
A bounded, transparent path.
- 01
Scope
A short call to map the device, the stack, and what’s blocking it, plus an honest read on whether I’m the right fit before anyone commits.
- 02
Assess
SBOM, CVE triage and exploitability analysis, and a gap analysis across the kernel, OS, and application stack. You get a prioritized findings list and a remediation plan.
- 03
Remediate
I close the findings: backports, version upgrades, and end-of-life migrations across the kernel, OS packages, and application code. Fixed and verified.
- 04
Evidence
The 524B cyber-package (SBOM, VEX, risk rationales, and remediation evidence), generated in CI and handed over ready to submit.
Where to start
Most engagements begin with a fixed-scope readiness assessment: a clear first step that tells you exactly where the device stands and what closing it will take.
Who you’ll work with
You hire the engineer, not an agency.
I’m Rafe Centuori, and Backport Security is just me: a specialist in FDA premarket cybersecurity and embedded Linux security remediation for medical devices.
I’ve been the constant owner of product security and the embedded platform for a connected, FDA-regulated clinical instrument: the Yocto/BitBake build, the kernel and BSP, the SBOM and CVE remediation, the VEX justifications, and the 524B submission evidence reviewers expect. The instrument changed corporate hands three times; that ownership stayed with me throughout. I’m equally at home in the kernel and in front of regulatory and leadership stakeholders.
B.S. Engineering Management (ECE), University of Arizona
Representative work
Proven, not theoretical.
Anonymized examples of work I’ve delivered.
- Embedded Linux
Migrated a clinical instrument’s embedded Linux off an end-of-life Yocto release (Dunfell to Scarthgap LTS) for its FDA submission: refactored the kernel, bootloader, and dependency graph, patched the affected CVEs reported against the build, and wrote not-affected justifications for the rest.
- Platform hardening
Rebuilt a Packer-provisioned Ubuntu VM and kernel onto an LTS baseline with LUKS full-disk encryption, keeping its Dockerized, Dapr-based microservices running across the upgrade.
- SBOM tooling
Rolled out FOSSA SCA scanning across every repository, then migrated the program to Black Duck. Built Python automation to remediate gaps in the generated SBOMs and cut false positives.
- CI/CD
Built the GitLab CI/CD across the Yocto build, the native, Python, and C# services, and the VM’s Docker images. Each produces a standalone, release-versioned installer (including the SWU device-upgrade file) that a master installer packages and deploys automatically.
- FDA 524B
Produced the cybersecurity evidence for an FDA premarket (524B) submission: SBOM, VEX and affected-status justifications, remediation evidence, and the risk rationales.
FAQ
Questions I get.
You’re a solo practice. What about availability and continuity?
I take a deliberately small number of engagements, so yours gets real attention. I also scope and document so the work lives in your repo and design history file. If you ever need to bring it in-house or hand it to another engineer, everything is there. I’ll tell you upfront if my calendar can’t meet your timeline.
Can you work within our QMS and SOPs?
Yes. I work inside your quality system and document to your procedures, so the cyber-evidence slots straight into your design history file and submission rather than sitting beside it.
Will you sign an NDA?
Always. An NDA goes in place before any device details change hands, and I can work under your MSA or other agreements as your contracts team requires.
Can you work in our GitLab and CI/CD?
Yes. The tooling and evidence generation run inside your GitLab CI/CD, so the SBOM and cyber-evidence stay current automatically rather than being assembled by hand under deadline.
Our submission already got a cybersecurity hold. Can you help?
Yes. I triage the deficiency, close what the reviewer flagged across the stack, and produce the response evidence. Tell me what came back and where the device is.
Do you do penetration testing or full QMS authoring?
That’s not my core. I focus on closing vulnerabilities across the embedded stack and producing the 524B evidence. For specialized penetration testing or full QMS authoring, I’ll point you to people who do it well, and I’m happy to work alongside them.
Where are you based, and do you work remotely?
Tucson, Arizona, working remotely with engineering and regulatory teams across the US.
Contact
Sitting on open vulnerabilities, or a submission that’s stuck?
Tell me where the device is in its lifecycle and what’s blocking it: the open CVEs, the aging stack, the cyber package. I’ll tell you whether I can help and what it would take.
For security firms: I take on the kernel- and BSP-level remediation, end-of-life migrations, and build-system work that’s hard to staff, white-label or named.
Talk about subcontracting