SCA, SAST, DAST, fuzzing and penetration testing run together, so every result arrives with the context to prove whether it is exploitable.
The target decides the scope, not the statement of work.
Embedded targets get SAST on source and compiled binaries, firmware and bootloader analysis, and fuzzing on every interface, including JTAG, UART and BLE.
The services and apps around the device get DAST on running services, API and session testing, and the same SCA and SAST as the device.
DICOM, HL7, MQTT and proprietary protocols are fuzzed with malformed traffic on the real product, in our lab or over TestLink.
Each test answers a different question; only all of them answer the reviewer's.
A CVE in a component says nothing about whether the vulnerable function is reachable on this device.
A weak pattern in source may sit behind a control, or in code that never executes on the shipped configuration.
A reachable fault with no source context cannot be traced to its root, so it cannot be fixed once or chained correctly.
Every result is placed on the digital twin and verified before it is called a finding.
The same phases every time; open-box access is what lets phase three cover the whole product.
Scope, constraints, threat focus, test cases generated from the twin.
Interfaces, entry points, trust boundaries, workflows.
SCA, SAST, DAST, fuzzing and pentest techniques, all at once.
Verify each candidate on the twin, in code, on the device.
Multi-step exploitation and root-cause chaining.
Findings, weaknesses, evidence, prescriptive fixes.
Source, build, architecture, threat model, SBOM and privileged test access; nearly all premarket tests are now open-box.
Every test case maps to a component, interface or dataflow, which is what FDA reviewers ask to see.
The record is retained, so a new release tests the change against everything already known.
Every Product Security Testing Report documents the process a reviewer will ask about.
Which of SCA, SAST, DAST, fuzzing, attack surface, robustness and pentest ran against each component, and with what coverage.
Each test case mapped to the architecture element and threat it exercises, with the result recorded.
For every finding the exploit path and proof; for every weakness the rationale for the record.
Which tests are included in an ELTON test?
Every test type the target supports: software composition analysis against the SBOM, static analysis of source and binaries, dynamic analysis of running services, fuzzing of every parser and protocol, attack surface and robustness analysis, penetration testing, and exploitability verification on the twin, in code and on real hardware.
Why not buy SAST, DAST and a pentest separately?
Because each one answers a different question and none of them answers the reviewer's question. SCA says what is in the product, SAST where the code is weak, DAST what is reachable, fuzzing what breaks, pentesting what an attacker can chain. Run in silos they produce five lists with no shared context, so exploitability cannot be analyzed comprehensively.
What is the difference between a finding and a weakness?
A finding is exploitable on this device as shipped, directly or conditionally, and carries the test case that proves it. A weakness is a real result with no exploit path on this release; it stays in the record with a written rationale, because FDA reviewers probe the results you did not fix.
Where is this documented?
In the methodology section of every Product Security Testing Report: the test types executed per target, the tools and coverage record, test cases mapped to the architecture and threat model, and the verdict and evidence behind every finding and weakness.