IDE Software Risk And Cybersecurity Summary
Status: Reviewer summary Owner: BionicLoop engineering Last updated: 2026-04-07 12:32 EDT
Purpose
Provide a proportionate study-facing summary of the main software risk and cybersecurity points for the current IDE software baseline.
Main Software Risk Themes
The software risk story for the current baseline is concentrated in four areas:
- incorrect or mistimed insulin-delivery decisions
- stale, missing, or degraded CGM/pump state leading to poor control decisions
- alerting/acknowledgement failures that could hide significant device/runtime conditions
- local telemetry/export handling and operator access to stored investigational data
Current Risk-Control Position
Key controls already represented in the codebase and quality chain include:
- guarded runtime execution and command application when pump state is unavailable
- normalized alert taxonomy with explicit severity and acknowledgement behavior
- clinician-gated critical settings
- explicit accepted/deferred requirement dispositions rather than silent ambiguity
- unit/integration/UI verification structure across algorithm, runtime, alerting, and operator workflow surfaces
The full risk register and trace mapping remain in:
Cybersecurity Boundary
The current software baseline relies on a split boundary:
- manufacturer/device-side controls for Omnipod DASH and Dexcom G7 are inherited and documented as relied-upon controls
- BionicLoop owns the local controller-app behaviors, including local storage, export, logging, and package provenance statements
Current cyber scope for this software baseline is limited to:
- local file/export posture
- permissions/background-mode posture
- secret/logging review posture
- provenance/process notes for embedded packages
- explicit statement of what cloud/auth/security closure is deferred
Current Cybersecurity Recommendation
Engineering’s current recommendation is:
- acceptable with explicit conditions for the current investigational software handoff baseline
- not positioned as a broader release baseline without additional hardening
Reason:
- the main local issue is real and explicit: step telemetry CSV is automatically exported into Documents
- file sharing and open-in-place are currently enabled
- reviewed auth/network logging does not directly expose bearer tokens or passwords in the reviewed paths
- the package does not over-claim ownership of DASH/G7/Dexcom-app security behavior
Conditions Required For The Investigational Baseline
The current investigational recommendation assumes:
- the local CSV/export posture is explicitly accepted as part of the study baseline
TV-SEC-001is promoted into formal evidence at freeze- the current file-sharing/open-in-place posture is explicitly dispositioned in the submission record
- the software baseline continues to avoid broader release claims for deferred auth/cloud/security areas
Open Cybersecurity Items That Still Matter
- external supplier/FDA artifact linkage for inherited DASH/G7/Dexcom-app claims
- freeze-time
TV-SEC-001execution - freeze-time SBOM/advisory artifact execution
- documented acceptability decision on the investigational export/file-sharing posture