Cybersecurity Plan (Investigational Build)
Status: Final draft prepared for handoff (pending review)
Version: 0.9
Owner: BionicLoop engineering
Prepared by: BionicLoop engineering
Reviewer: ____
Approver: ____
Decision date: ____
Effective date: ____
Baseline freeze SHA: ____
Last updated: 2026-04-06 12:37 EDT
Revision History
| Version | Date | Author | Summary of Changes |
|---|---|---|---|
| 0.1 | 2026-03-27 | Engineering | Initial cybersecurity draft baseline |
| 0.9 | 2026-04-06 | BionicLoop engineering | Added handoff-ready metadata and expanded the software handoff cyber package with trust boundaries, inherited-control mapping, local-control mapping, and explicit artifact gaps |
1. Scope
This plan covers cybersecurity controls for:
- mobile app runtime
- connected-device communications (CGM + pump)
- telemetry data handling (local and future cloud path)
Current software-handoff boundary:
- In current engineering handoff scope:
- local/device-resident telemetry handling and export controls
- software design statements for secure telemetry architecture
- documentation of implemented auth/session code paths where they affect software understanding
- Deferred from the current software handoff package:
- formal closure of cloud-upload verification
- protected API access, onboarding-provider, authorization-role, password-recovery, session-restore, and auth-failure continuity claims represented by
SRS-SEC-003..009
Execution tracking for the current software handoff package is maintained in Cybersecurity_Handoff_Register.md.
2. Security Objectives
- Preserve safety-critical command integrity.
- Protect confidentiality of participant data.
- Maintain availability of safety-relevant status and logs.
3. System Trust Boundary Summary
Primary trust-boundary elements for the current software handoff package:
- iPhone-resident BionicLoop application
- Dexcom G7 sensor communication path and supporting official Dexcom application
- Omnipod DASH pod communication path
- local persistence (
UserDefaults, app documents, keychain) - local alerting and notification surfaces
- future cloud telemetry path
Current boundary statement:
- BionicLoop owns the controller-app software behavior, local persistence choices, local export behavior, alerting behavior, and cloud-client code it ships.
- Dexcom and Insulet own the cleared device firmware, proprietary radio/device behavior, and primary CGM/pump safety/security controls of their respective products.
- Local package code (
OmniBLE,G7SensorKit,LoopKit) is treated as software of unknown provenance / inherited open-source software that still requires version, provenance, and delta tracking by BionicLoop.
4. Supplier / Inherited Control Matrix
| Component | Security Property Relied Upon | Current Evidence Available in Repo | Additional Artifact Needed for Handoff-Grade Closure | BionicLoop Ownership Boundary |
|---|---|---|---|---|
| Omnipod DASH pod / radio session | Device-side command/session security and encrypted command transport | Local OmniBLE implementation uses LTK-backed encrypted DASH transport with nonce sequencing and AES-CCM handling in OmniBLE/OmniBLE/Bluetooth/EnDecrypt/EnDecrypt.swift, OmniBLE/OmniBLE/PumpManager/MessageTransport.swift, and OmniBLE/OmniBLE/PumpManager/PodComms.swift. |
Insulet / FDA-cleared product cybersecurity and interoperability artifact or approved supplier summary identifying the relied-upon control. | BionicLoop may rely on the pod/session security model but does not claim original ownership of DASH firmware/radio security. |
| Dexcom G7 sensor / radio session | Device-side authenticated CGM session behavior | Local G7 integration exposes a dedicated authentication characteristic and authenticated service boundary in G7SensorKit/G7SensorKit/BluetoothServices.swift; the plugin README also requires use of the official G7 app in G7SensorKit/README.md. |
Dexcom / FDA-cleared product cybersecurity and interoperability artifact or approved supplier summary identifying the relied-upon control. | BionicLoop may rely on the G7 session model and official Dexcom app requirement but does not claim original ownership of Dexcom device/app security. |
| Official Dexcom application | Primary CGM alarm and safety alerting | Current BionicLoop requirements and IFU explicitly state Dexcom remains the source of truth for CGM alarming. | Formal citation package for Dexcom alarm/security behavior used by the study / submission team. | BionicLoop owns only its supplemental in-app CGM status/review presentation. |
OmniBLE local package |
Pump communication implementation | Local source and tests are present in repo; README identifies it as Loop-associated Omnipod Bluetooth PumpManager code; the current provenance review now also records the identified likely public upstream repo URL, likely import commit basis, and shipped local delta summary, and the curated delta review now classifies the reviewed local transport changes as connection/pairing recovery behavior rather than cryptographic weakening. | Any available upstream tag/release mapping for the identified import basis. | BionicLoop owns the chosen version and any local modifications it ships. |
G7SensorKit local package |
CGM communication implementation | Local source is present in repo; README documents official G7 app dependency; the current provenance review now also records the identified likely public upstream repo URL, likely initial import and later sync commit basis, and shipped local delta summary, and the curated delta review now records no security-semantic local delta in the reviewed BLE/auth/logging surfaces. | Any available upstream tag/release mapping for the identified import/sync basis. | BionicLoop owns the chosen version and any local modifications it ships. |
LoopKit local package |
Shared data storage / platform helper library behavior | Local source and license are present in repo; the current provenance review now also records the identified likely public upstream repo URL, likely import commit basis, and shipped local delta summary, and the curated delta review now records no security-semantic local delta in the reviewed auth/keychain/logging surfaces. | Any available upstream tag/release mapping for the identified import basis. | BionicLoop owns the chosen version and any local modifications it ships. |
5. BionicLoop-Owned Local Security Controls
| Control Area | Current Implementation / Observation | Evidence in Repo | Current Limitation / Residual Gap |
|---|---|---|---|
| Token and credential storage | Auth tokens and stored credentials are persisted in iOS Keychain with kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly. |
BionicLoop/App/AuthSessionNetworking.swift |
Applies only to auth/session data, not to all local telemetry artifacts. |
| Authenticated API requests | Protected requests carry Authorization: Bearer <token> and retry once after 401 using refreshed token. |
BionicLoop/App/AuthenticatedAPIClient.swift, BionicLoop/App/AuthSessionNetworking.swift |
Formal closure for protected cloud/API scope remains deferred in this handoff package. |
| Local telemetry outbox persistence | Telemetry outbox is persisted locally with bounded queue behavior and retry/permanent-failure handling. | BionicLoop/App/CloudTelemetryReporter.swift, BionicLoop/App/CloudTelemetryOutbox.swift |
Outbox currently persists in UserDefaults; this should be treated as an app-level implementation detail, not a protected long-term record store. |
| Export minimization boundary | Step CSV export is documented as development-only. | BionicLoop/Runtime/LoopTelemetryStore.swift, Docs/Quality/SoftwareRequirementsSpecification.md |
CSV currently writes plain UTF-8 to the app Documents directory; no explicit file-protection setting is applied in code. |
| File-access surface | App currently enables UIFileSharingEnabled and LSSupportsOpeningDocumentsInPlace. |
BionicLoop/Resources/Info.plist |
This increases the importance of documenting operator/site controls around exported files and should be reviewed before production release. |
| Logging discipline | Debug/API/telemetry logging redacts request query strings and avoids dumping bearer tokens directly. | BionicLoop/App/AuthenticatedAPIClient.swift, BionicLoop/App/CloudTelemetryReporter.swift, BionicLoop/App/AuthSessionNetworking.swift, Docs/Quality/Cybersecurity_Logging_and_Secret_Review.md |
Reviewed for the current handoff package, but debug-response-snippet behavior and console observability remain a residual development-risk consideration if auth/cloud scope is later reopened. |
| Platform permissions | Current app declares Bluetooth-central background use and Bluetooth usage descriptions. | BionicLoop/Resources/Info.plist |
No separate entitlements file is present; an explicit least-privilege permission review record is still needed for handoff evidence. |
6. Security Baseline Controls
- Transport security for all cloud telemetry endpoints (future primary path).
- Minimize persistent local sensitive data; local CSV/export remains development-only.
- Principle of least privilege for iOS permissions, background modes, and file-sharing exposure.
- Dependency and package version tracking (SBOM-ready inventory).
- Logging controls: avoid secrets and unnecessary identifiers in clear text.
- Explicit failure handling for unavailable/unknown device states.
- Identity and access control implementation exists in development builds, but formal closure for protected auth/provider/role flows is deferred from the current software handoff package.
7. Threat Scenarios (Current Focus)
- BLE disruption or spoofed/disrupted communication causing stale status.
- Unauthorized access to exported local telemetry files.
- Data exfiltration via insecure cloud upload path (future risk).
- Dependency vulnerability introducing runtime compromise.
- Account takeover or unauthorized API access via weak/misconfigured auth flows.
- Privilege escalation from incorrect role/scope mapping.
- Improper access to app Documents content because file sharing / open-in-place is enabled while development exports are present.
- Security-relevant behavior drift between local forks of
OmniBLE/G7SensorKit/LoopKitand their upstream source without explicit provenance tracking.
8. Planned Evidence Artifacts
- threat model worksheet (data flow + trust boundaries)
- SBOM/dependency inventory snapshots
- static analysis/dependency scan results
- penetration/resilience test notes for network upload path (when implemented)
- incident-response drill notes
- identity-provider configuration review notes (Cognito, Apple, Google, email flow)
- auth negative-test evidence (expired/revoked token, role denial, session hijack resistance)
- supplier / inherited-control matrix with upstream provenance and local delta tracking for
OmniBLE,G7SensorKit, andLoopKit - local export/file-sharing review note covering
UIFileSharingEnabled,LSSupportsOpeningDocumentsInPlace, and development-only CSV behavior - current execution register:
Docs/Quality/Cybersecurity_Handoff_Register.md - current provenance review note:
Docs/Quality/Cybersecurity_SOUP_Provenance_Review.md - current embedded-package delta review note:
Docs/Quality/Cybersecurity_Embedded_Package_Delta_Review.md - current local file/permission review note:
Docs/Quality/Cybersecurity_Local_File_and_Permission_Review.md - current dependency inventory note:
Docs/Quality/Cybersecurity_Dependency_Inventory.md - current SBOM/advisory process note:
Docs/Quality/Cybersecurity_SBOM_and_Advisory_Process.md - current logging/secret review note:
Docs/Quality/Cybersecurity_Logging_and_Secret_Review.md - current supplier artifact request list:
Docs/Quality/Cybersecurity_Supplier_Artifact_Request_List.md - current baseline acceptability recommendation:
Docs/Quality/Cybersecurity_Baseline_Acceptability_Recommendation.md - current
TV-SEC-001freeze execution checklist:Docs/Quality/Cybersecurity_TV_SEC_001_Freeze_Execution_Checklist.md
9. Current Control and Evidence Matrix
| Security Area | Related IDs | Current Handoff Scope | Current Control / Design Statement | Verification / Evidence Position |
|---|---|---|---|---|
| Inherited DASH and G7 link security | RA-003, RA-009 |
Supporting inherited control context | Current code shows encrypted DASH transport and G7 authentication surfaces; BionicLoop relies on supplier/device security rather than re-implementing device firmware controls. | Supplier/FDA artifact linkage still needed before handoff-grade closure can reference inherited controls cleanly. |
| Local telemetry export and file handling | SRS-SEC-002, TV-SEC-001, RA-009 |
In scope | Local export is controlled, data minimization remains required, and development-only local export path is explicitly documented. File-sharing/open-in-place surface is explicitly recognized as part of the threat boundary. | Needs formal evidence rerun/promotion at freeze; currently tracked as software-handoff work, not deferred. |
| Secure cloud upload as primary transport architecture | SRS-SEC-001, TV-SEC-002, RA-009 |
Design statement documented; formal verification deferred | Architecture intent remains documented: secure cloud upload is the long-term primary transport and local CSV is development-only. | Formal cloud-upload control verification is deferred from the current software handoff package. |
| Protected API access, onboarding providers, role authorization, password recovery, session restore, auth-failure continuity | SRS-SEC-003..009, TV-SEC-003..008, RA-009 |
Deferred from current software handoff package | Existing implementation may exist in development builds and remains documented for software understanding. | No closure is claimed in this handoff package; re-open only when auth/cloud scope is intentionally brought back into package scope. |
| SOUP / local-package provenance | RA-009 supporting control |
In scope as documentation/process requirement | Local packages are embedded in the repo and now have a current repo-observable provenance review note, curated local-delta review note, dependency inventory note, and SBOM/advisory process note for the current baseline. | Current process documents exist; remaining work is any available tag/release mapping plus freeze-time SBOM/advisory execution. |
10. Identity and Access Planning (Deferred from Current Software Handoff Package)
This section is intentionally marked as pending team discussion before implementation lock.
- Proposed onboarding providers:
Sign in with AppleGoogleEmail(exact mode pending decision: magic link vs password)- Proposed AWS identity platform:
- Cognito
User Poolas primary identity provider - optional
Identity Poolonly if temporary AWS credentials are required - Required decisions before implementation:
- per-user identity requirement vs limited unauthenticated investigational mode
- role model and least-privilege scope design
- token/session lifecycle and revocation handling
- consent/legal onboarding content
- deprovisioning and emergency-access process
11. Current Missing Artifacts / Open Cyber Gaps
- Approved supplier or FDA-cited cybersecurity/interoperability artifacts for the exact Dexcom G7 and Omnipod DASH security properties being relied upon
- Any available upstream tag/release mapping for the identified
OmniBLE,G7SensorKit, andLoopKitimport/sync baselines - Freeze-time execution of the formal SBOM/advisory artifact defined by
Cybersecurity_SBOM_and_Advisory_Process.md - Receiving-team freeze decision on whether to accept the documented investigational conditions for the current Documents-directory export, file-sharing, permission surface, and residual debug-logging posture, or require hardening
- Formal execution and promotion of in-scope
TV-SEC-001usingCybersecurity_TV_SEC_001_Freeze_Execution_Checklist.md - Clear decision on whether any portion of cloud-security verification should be re-entered into the current handoff package
12. Deferred Auth / Cloud Scope Note
For the current engineering software handoff package:
SRS-SEC-003..009are not claimed as closed software scopeTV-SEC-003..008are not handoff-ready evidence obligations in this passSDD-AUTH-001,SDD-AUTH-002,SDD-POL-015, andSDD-POL-016remain documented because the implementation exists, but they should be treated as documented implementation context rather than accepted closure claims for this package
13. Incident Handling (Seed)
- Define severity levels (
Critical,High,Medium,Low). - Create response SLAs by severity.
- For
Critical/Highfindings: - triage immediately
- patch and verify
- update risk register + traceability matrix
- communicate impact to study/clinical stakeholders
14. Regulatory Alignment
See Docs/Quality/RegulatoryReferences.md for FDA cybersecurity guidance links and applicability notes.