On this page
Published:
Key Takeaways
- A scanner alert is a candidate until human review establishes the weakness and its relevant code context.
- CWE identifies the weakness type; a scanner severity label or CWE number is not a device-specific risk rating.
- Confirmed findings connect source evidence, risk reasoning, remediation, retest results, and unresolved-anomaly records.
- A clean rescan alone does not prove a fix works or that all weaknesses have been found.
- The manufacturer owns configuration management, code changes, clinical evidence, risk acceptance, and release.
How do SAST scanner results become confirmed medical device security findings?
A SAST result becomes a confirmed finding through human review that confirms or rejects it with a recorded rationale. Blue Goat Cyber documents why the weakness is present, assigns an appropriate CWE classification, develops device-specific risk reasoning, and connects remediation to retest evidence. Scanner output alone is not a confirmed vulnerability or a release decision.
Reviewed October 23, 2026. Based on Blue Goat Cyber's BGC-GUIDE-SW-002, Rev B, effective October 22, 2026.
Static application security testing (SAST) examines source code for potential security weaknesses without requiring the complete device to be running. It can identify unsafe code patterns early, but it can also flag protected paths, misunderstand configuration, or miss weaknesses outside its supported languages and rules. The review matters as much as the scan.
This page covers source-code security review and finding closure. Component inventory and published third-party vulnerabilities belong to software composition analysis (SCA); see the SBOM guide and SBOM verification workflow. SAST does not replace penetration testing or the manufacturer's broader software lifecycle activities.
1. Define the source and scan scope
We agree the software systems in scope, and the scan is configured to their languages and platform. Under this methodology, SAST covers manufacturer source code in scope and modified third-party code. SCA separately addresses third-party components and published vulnerabilities.
The manufacturer connects the supplied source and configuration to the release under assessment. A scan of a development branch does not automatically describe shipped software.
Scans include checks for credentials that are hardcoded, default, easily guessed, or easily compromised. The SAST report records the tool name, version, and configuration so the result can be reproduced. Those records make later comparisons meaningful: a changed scanner configuration can remove an alert without removing the underlying weakness.
2. Triage alerts before calling them findings
Reviewers examine the flagged operation and surrounding code. The question is whether the reported weakness is present in the assessed software, not whether the scanner assigned a high severity label.
| Review disposition | Evidence and treatment |
|---|---|
| Confirmed weakness | Document the affected code and the conditions that establish the weakness; create a traceable finding |
| Rejected alert or false positive | Record why the reported weakness is not present or applicable, with supporting code or configuration evidence |
These are review dispositions, not prescribed FDA labels. Lack of a running-device exploit demonstration does not by itself make a source-code weakness a false positive. Conversely, a suspicious code pattern does not establish a specific patient-harm outcome.
3. Classify confirmed weaknesses with CWE
Common Weakness Enumeration (CWE), maintained by MITRE, describes weakness types. We select an applicable classification supported by the code evidence, rather than copying a broad scanner label without review. CWE is distinct from CVE: CWE describes a weakness type, while a CVE identifier refers to a publicly cataloged vulnerability.
The examples below illustrate classifications, not findings observed in a particular client or device. Applicability depends on the actual code and deployment context.
| CWE example | Weakness type | What review would examine |
|---|---|---|
| CWE-787 | Out-of-bounds Write | Whether input length and destination bounds are checked before a write |
| CWE-89 | Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') | Whether untrusted data can change a query's structure instead of being passed safely as data |
| CWE-78 | Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') | Whether untrusted values can alter an operating-system command |
| CWE-798 | Use of Hard-coded Credentials | Whether an embedded credential grants access, where it is used, and how it can be replaced |
| CWE-862 | Missing Authorization | Whether a sensitive operation enforces the caller's permissions |
A CWE classification organizes findings and helps identify recurring coding problems. It does not supply exploitability, clinical severity, or an automatic remediation deadline.
4. Build an evidence-backed finding record
Each confirmed finding should be understandable without access to the scanner dashboard. Each confirmed finding records its CWE category, a risk rating, and recommended remediation, and is carried into the risk register and threat model.
Risk review is separate from classification. Scanner severity is an input to investigation, not our final device-risk determination. Security impact can matter even when a patient-harm pathway has not been established. Severity comes from the manufacturer's ISO 14971 hazard analysis, and Blue Goat Cyber does not estimate severity in place of it; absent evidence must not be replaced with a guessed severity. See our risk scoring methodology.
Uncertainty and scope limitations remain visible. A finding that remains at submission is an unresolved anomaly with security impact and is assessed, with its CWE category, in the Assessment of Unresolved Anomalies and the Cybersecurity Risk Assessment. Exploitability may require a defect to be fixed even where an ordinary software benefit analysis would leave it. A report does not silently turn an unresolved item into an accepted risk.
5. Recommend remediation; preserve manufacturer ownership
Remediation addresses the underlying cause, not only the flagged line. Depending on the confirmed weakness, that may mean enforcing bounds, using parameterized queries, removing embedded credentials, or applying authorization at the sensitive operation. Guidance should explain the security objective and the affected paths so the manufacturer can implement and review an appropriate change.
The manufacturer owns code changes, configuration management, clinical severity evidence, risk acceptance, and release approvals. Blue Goat Cyber provides security review and one included round of retest for remediated findings; this is not a general software verification or validation service or an IEC 62304 conformity assessment.
Suppressing a scanner rule is not remediation by itself. A suppression needs a documented rationale and evidence, and it must not conceal a confirmed unresolved weakness. Acceptance of residual risk is a separate, manufacturer-owned decision.
6. Retest the fix and record the outcome
A confirmed finding the manufacturer fixes is retested and closed. One round of retest is included. Retesting is tied to the corrected source revision.
An alert disappearing from a rescan is not sufficient closure evidence on its own. It may reflect an exclusion or rule change. A completed retest also does not establish that the full product contains no other weaknesses. The manufacturer evaluates residual risk and decides whether the release is appropriate.
7. Review the handoff and protect source code
Before delivery, human review and second-person peer review support the quality of the confirmed findings under SW-002 Rev B. The handoff distinguishes raw alerts from reviewed findings and identifies unresolved questions, remediation recommendations, retest status, and limitations.
Source code does not leave Blue Goat Cyber's environment during analysis and is not sent to any third party. It is held with segregated, access-controlled access limited to assigned personnel. Processing and storage location is agreed before transfer. Some component vulnerability lookups can send names, versions, and identifiers to vendor services; restrictions need to be agreed during scoping.
Frequently asked questions
Related guidance
- SBOM requirements, formats, and SAST
- SBOM verification before delivery
- CWE vs CVE: how each supports findings and FDA evidence
- IEC 62304 cybersecurity deliverable map
- Medical device penetration testing
Discuss source-code security review for your release.
Sources and boundaries
- Blue Goat Cyber, BGC-GUIDE-SW-002, SBOM/SAST Methodology, Rev B, effective October 22, 2026. This page summarizes our methodology; the proprietary document is not offered as a public download.
- MITRE Common Weakness Enumeration, including CWE-787, CWE-89, CWE-78, CWE-798, and CWE-862.
- The FDA's February 3, 2026 final premarket cybersecurity guidance, for recommended cybersecurity testing and submission evidence. Our review workflow is not a universal statutory checklist or a guarantee of FDA outcomes.
Sources & references
Primary sources cited in this article. Links open in a new tab.
- MITRE Common Weakness Enumeration- MITRE
- CWE-787- MITRE
- CWE-89- MITRE
- CWE-78- MITRE
- CWE-798- MITRE
- CWE-862- MITRE
- The FDA's February 3, 2026 final premarket cybersecurity guidance- U.S. FDA
