Engineering Software Lab
ESL Takes Complete Ownership of Your Software Evidence Work
SBOM & CVE remediation. Static analysis & bug fixing. Unit testing & code coverage. Requirements-to-test traceability. We do not stop at finding problems — ESL analyzes the software, fixes the findings, reruns the tools, cleans the reports, and delivers the evidence package across source, build artifacts, and binary-only systems.
Many FDA Tasks. One Complete Software-Evidence Workstream.
You keep ownership of the product and submission. ESL owns the execution of the software analysis, remediation, testing, and evidence tasks in scope.
Right-Sized to Your Submission
Not every product or submission level needs every activity. ESL first identifies the applicable software-evidence scope with your quality and regulatory team — then performs only the work that is needed.
End-to-End Remediation — Not Scan-and-Leave
A long finding list does not help a submission. ESL closes the engineering loop for both source-code defects and software-component vulnerabilities: find it, understand it, fix it, prove it.
Engineers Who Fix, Not Reassign
Source is repaired by experienced engineers — not merely reassigned back to your team. Justified deviations are documented, analysis is rerun, and before/after evidence is retained against the controlled baseline.
The Deliverable Is Evidence, Not a Dashboard
The outcome is a reviewed, reproducible, and traceable software-evidence package that reviewers can navigate — not disconnected tool reports they must reconcile.
Four Software-Evidence Services. One Engagement.
Combine SBOM, CVE remediation, static analysis, code repair, unit tests, coverage, and ALM traceability — or take only the individual service you need.
SBOM Reports — Even From Binaries Only
Inventory components and dependencies from source, packages, containers, firmware, or available binary artifacts. Correlate known vulnerabilities, assess relevance, and produce submission-oriented reports.
- Machine-readable SBOM plus human-readable inventory
- Known-vulnerability correlation, incl. binary-only discovery
- Applicability analysis, remediation & documented rationale
- Rescan after changes, residual status made explicit
Static Code Analysis — and Actual Fixes
Configure language-appropriate rules, triage findings, repair defects, document justified deviations, and rerun analysis until the code and evidence are clean enough for the agreed acceptance criteria.
- Rules & severity profile tuned to language and policy
- Findings triaged: defects, deviations, false positives
- MISRA C/C++, CERT C/C++, CWE & project rules
- Final scan & disposition tied to controlled baseline
Unit Testing and Structural Coverage
Create and execute tests, measure statement / branch / condition or other appropriate coverage, analyze uncovered code, repair testability defects, and assemble objective results.
- Risk-appropriate test strategy & acceptance criteria
- Harnesses, stubs, mocks & target communication
- Statement, branch, condition & MC/DC where appropriate
- Uncovered / dead-code analysis with documented disposition
Requirements-to-Test Proof in Your ALM
Connect requirements, risks, tests, runs, results, defects, and code evidence in Polarion or another supported ALM — so reviewers can navigate the chain rather than reconcile disconnected reports.
- Requirements & risk controls mapped to test levels
- Executed tests exported into the ALM with results
- Traceability from requirement through tests to code
- Gaps & progress visible in dashboards & matrices
Find It. Understand It. Fix It. Prove It.
ESL closes the engineering loop for both source-code defects and software-component vulnerabilities — one repeatable remediation workflow.
Discover
Scan source, builds, dependencies, containers, firmware, and binaries available for assessment.
Triage
Remove noise, confirm applicability, classify impact, and prioritize against product risk.
Remediate
Fix code defects; upgrade, replace, patch, or otherwise address vulnerable components.
Verify
Rebuild, rescan, retest, and run regression checks to confirm the remediation.
Evidence
Record tool versions, configuration, findings, dispositions, results, and traceability.
One ESL Team. Two Specialized Evidence Pillars.
Use only the evidence activities your device, risk, and submission require. ESL implements the tools, performs the engineering work, fixes findings, and delivers the reviewed evidence.
SBOMator™
- Source, package, container, firmware & binary-only analysis
- CycloneDX SBOM, VEX decisions & CVSS v4.0 context
- CVE applicability review, remediation & cleaner reports
- Section 524B evidence mapping & postmarket monitoring
- HBOM, FPGA & DataBOM evidence where applicable
Parasoft — IEC 62304-focused verification
- Static analysis with defect triage & source-code remediation
- Automated and engineer-authored unit testing
- Statement, branch, condition & MC/DC coverage
- Requirements-to-test traceability & ALM integration
- C/C++test is TÜV SÜD-certified for use in IEC 62304 development
Complementary roles: SBOMator produces software-composition and cybersecurity evidence. Parasoft produces source-code verification evidence. ESL connects both to the controlled build, requirements, tests, findings, fixes, and release baseline. The manufacturer owns the regulatory decision; ESL supplies the engineering execution and objective evidence behind it.
Your Software Stack Should Not Become Your Evidence Gap
ESL assembles the appropriate tool and engineering workflow for the languages, targets, and artifacts in your product. The exact scope is confirmed during assessment.
Broad Language Coverage
C, C++, C#, Java, VB.NET, and other stacks through suitable static-analysis, testing, and software-composition technologies.
Host to Embedded
Desktop, server, cloud, container, mobile, cross-compiled, and resource-constrained embedded targets — including on-target testing where needed.
Source or Binary-Only
Full repositories, partial source, package manifests, build outputs, containers, firmware, and binaries. SBOM work does not require a perfect source tree to begin.
From Scattered Findings to a Controlled Baseline
What changes when ESL owns the software-evidence execution.
Before ESL
- Unknown components
- Noisy findings
- Unowned defects
- Incomplete tests
- Disconnected evidence
After ESL
- Controlled baseline
- Remediated findings
- Repeatable tests
- Reviewed reports
- Explicit residual risk
Bring ESL the Software — Not a Cleaned-Up Demo
We will build, clean, and connect the evidence. Start with a software-evidence scoping workshop: ESL reviews your intended submission context, software stack, available artifacts, existing tests, and ALM environment — then defines the smallest complete work package needed.
This page describes engineering services, not legal or regulatory advice. FDA guidance documents generally contain nonbinding recommendations unless specific statutory or regulatory requirements are cited. Applicable evidence depends on the device, software functions, risk, submission type, and current FDA expectations. ESL does not guarantee FDA clearance, approval, or inspection outcomes. The manufacturer retains responsibility for safety, effectiveness, quality-system compliance, risk decisions, validation, and submissions. Product and company names are trademarks of their respective owners.