SCMD CyberSuite
The cybersecurity file of a regulated product, kept current from live data instead of rewritten for every audit.
- Question
- Can the cybersecurity documentation of a medical device update itself when a dependency changes, instead of being rewritten by hand before each submission?
- Result
- That is what it does. Inventory, vulnerabilities, risks and documents live in one place, and an approved document can be reproduced exactly years later. Available to clients under NDA.
The problem
The cybersecurity file of a medical device is usually spread across spreadsheets, Word documents, a dependency scanner, a vulnerability tracker and a few repositories. The SOUP list goes out of date the day a library changes. Every audit or submission means rebuilding the evidence by hand, and the trace from threat to control to test lives in someone’s head.
CyberSuite puts all of it in one model, client → project → parts → versions, and builds the documents from that data. While a document is a draft it follows the data. When it is approved, it is frozen as a snapshot that can be reproduced exactly, with its history and audit trail.
- 01SBOM and inventory
- 02Vulnerabilities
- 03Risks
- 04Documents
- 05Submission package
What it covers
SBOM and components
Generated by scanning repositories, artifacts, container images, firmware and live systems over SSH, or imported as CycloneDX and SPDX. Versioned, scored and compared between versions. Hardware, cryptography and AI models (HBOM, CBOM, AI-BOM) too, and SOUP/OTS inventory with supplier, support level and end of life.
Vulnerabilities
Continuous matching against OSV, NVD, GitHub advisories, KEV and EPSS, with triage, SLAs and prioritisation by CVSS 3.1 and 4.0, SSVC and the MITRE rubric for medical devices. VEX in and out as CycloneDX, OpenVEX and CSAF.
Risk
Threat modelling with STRIDE, LINDDUN and attack trees, scored by exploitability. A complete ISO 14971 risk management file, with FMEA, fault trees and IEC 62366-1 use errors, linked to the cybersecurity risks and traced to requirements and tests.
Documents
More than 55 document types, with templates and styles per client. Draft, review, approval and obsolescence, with electronic signature, diff between revisions, and export to PDF, Word, HTML and Markdown.
Submissions
A package ordered for the FDA, the MDR or the Cyber Resilience Act, with the approved revision of each document, signed SBOM and VEX, and checksums. It also warns about missing or outdated documents. Includes the MDS2 form and executive reports.
After release
A coordinated vulnerability disclosure portal per client, with signed CSAF advisories. Guided regulatory notifications with their deadlines, under the CRA, MDR, FDA, GDPR and NIS2. Licence policies and NOTICE files, and hardening checks on embedded Linux.
Frameworks it works with
- FDA premarket cybersecurity
- MDR / MDCG
- IEC 62304
- IEC 81001-5-1
- ISO 14971
- IEC 62366-1
- IEC 62443-4-1
- NIST SSDF
- Cyber Resilience Act
- NIS2
- GDPR
For each framework there is a clause-by-clause compliance checklist, and evidence is reused where frameworks overlap. CyberSuite helps you meet these standards, but it doesn’t certify compliance. Responsibility for the content stays with the manufacturer.
How it is deployed
- On our instance, with your data isolated from other clients at the database level.
- On yours, on-premise with Docker Compose or as a single binary as a service, including air-gapped networks that receive vulnerability feeds as signed offline packages.
- In the browser or on the desktop, with a desktop app that can switch between servers.
- Single sign-on with OIDC, issue sync with Jira, GitHub and GitLab, encrypted backups, and an optional AI drafting assistant. The assistant is off by default, and a person always reviews what it writes.
Built the way we would audit it
CyberSuite holds sensitive client data, so we treat it as an audit target. It has an immutable audit log, signed exports, internal network egress blocked by default, external tools run in isolated containers, documented security reviews, and an interface checked against WCAG 2.2 AA. The regulatory content is checked against the official sources, and each item records whether that check has been done.