Article
Card image cap for article

Automation and Shift-Left of the Software Security Life Cycle Prior to Release to Market

Cybersecurity

5/14/2026

Shift Left: Security by Design in Medical Device Software

In my talk at MedtecLIVE 2026 [1] on automation in the design transfer phase of medical devices, I described a principle that is rapidly reshaping how the industry approaches product security: Shift Left.

Rather than treating cybersecurity as a final checkpoint before market release, best practice today is to embed security activities continuously across every phase of the development life cycle, from the earliest requirements discussions to the last deployment step in production. A vulnerability discovered during a penetration test in the late design output phase costs substantially more to fix than the same vulnerability caught during architectural design review.

A vulnerability identified by a lightweight threat model right after the first architectural draft may cost little beyond revising the architecture. Another example is deciding to omit a risky interface entirely because of a poor benefit‑to‑risk ratio, thereby reducing the attack surface.

Regulatory Foundations: IEC 62304 and IEC 81001‑5‑1

This article is based on two complementary standards that provide the regulatory context. IEC 62304 [2] defines the core life-cycle processes for medical device software, including development planning, requirements, architecture, implementation, integration, system testing, release, maintenance, configuration management, and problem resolution.

IEC 81001-5-1 [3] builds on this structure and adds the cybersecurity-specific activities needed for secure health software, covering topics such as development environment security, secure design, threat mitigation, vulnerability and penetration testing, file integrity, private key protection, and security issue handling throughout the product life cycle.

Documenting attack surfaces, trust boundaries, and threat scenarios is explicitly required in IEC 81001‑5‑1 §7.2, including external entities, physical ports such as JTAG, and third‑party components.

The FDA expects to include the Voice of the Customer regarding security, leading to the definition of the product security context. The latter is an extension to the Intended Use of the medical device and expresses the high-level security goals to protect the identified assets, including “non‑negotiable” security defaults, assumptions about the environment, and identification of the major reasonably foreseeable misuses.

Shift Left in Development and CI/CD

Shift Left also means that automation starts early. IEC 62304 §5.5 (Software Detailed Design) requires strategies, methods, and procedures for software unit verification, with predefined acceptance criteria for control flow, resource handling, fault behavior, and boundary conditions. These are ideally implemented as automated unit tests in the CI/CD pipeline (Continuous Integration/Continuous Delivery), so that every commit is checked against the same objective gate.

IEC 62304 §5.6 (Software Integration and Integration Testing) then demands integration testing and systematic regression testing whenever software items are integrated, again with fully traceable records of results, environment, tools, and anomalies.

Integrating automated static security checks into the developer workflow, as part of the CI/CD pipeline, is therefore not a luxury but a direct response to IEC 81001‑5‑1 §5.5.2 and §5.7.3: secure coding standards must be applied, and static code analysis must be used to detect secure coding errors in source code (§5.5.2c), while software composition analysis (SCA) on binary executables and third‑party libraries must detect known vulnerabilities, vulnerable library linkages, and compiler weaknesses (§5.7.3d).

The outputs of these analyses can be coupled to the company's secure coding policy, enforcing consistent rules across projects and generating machine‑readable evidence artefacts that feed directly into the technical documentation.

This is the workflow promoted by DevSecOps: integrating security tooling and accountability directly into the development and operations pipeline rather than treating it as a separate gate, which makes it a natural fit for regulated medical device development that must produce traceable, auditable security records at every lifecycle stage.

The later a security gap surfaces, the more deeply it is entangled with implemented code, validated interfaces, and approved documentation, and the more disruptive its resolution becomes for a regulated product under the MDR, FD&C Act 524B, ISO 13485 and IEC 62304. This is why security must be embedded long before the first line of code is written.

Shift Left in Requirements and Architecture

In requirements engineering, threat modelling and security risk assessment, as required by IEC 81001‑5‑1 Clause 7, should be initiated in parallel with functional requirements definition. The FDA's 2026 Cybersecurity Guidance reinforces this: security objectives such as authentication, authorisation, and data integrity must be traceable from requirements through to release and captured in artefacts like the Software Bill of Materials (SBOM) and security test reports.

At the design input stage, security architecture decisions – defence‑in‑depth layering, least‑privilege principles, secure interfaces between software items – are far less costly to define correctly from the outset than to retrofit into a completed design. IEC 81001‑5‑1 §5.3.1 and §5.3.2 require a documented security architecture, clear trust boundaries, and removal or protection of debug access before release. A secure architecture review early in the process is not overhead; it is the most cost‑efficient security investment available to a development team.

Shift Left in Design Output and Testing

At design output, these same secure coding standards and automated checks become the first gatekeepers in a CI/CD pipeline. IEC 81001‑5‑1 §5.7.1–5.7.4 extend this with mandatory security requirements testing, threat mitigation testing, vulnerability scanning (including SCA against an industry‑recognised vulnerability source), and penetration testing with documented independence of testers.

These activities are ideally organised as progressive stages in the CI/CD pipeline: fast unit and integration tests on every change, vulnerability scans and DAST nightly (Dynamic Application Security Testing scans on the application once per night on an automated schedule), and focused penetration tests before release.

Shift Left at Design Transfer and Production

At the point of design transfer, IEC 81001‑5‑1 §5.1.2 and §5.8.3/5.8.4 shift the focus to the production environment: the development and production IT infrastructure must be protected against unauthorised access, corruption, and deletion, and every executable or script must have a cryptographic integrity mechanism with well‑protected code‑signing keys. In combination with the FDA's SBOM expectations, this ensures that each software image flashed in production is authentic, intact, and fully traceable back to a verified build.

For larger systems with hardware and software on several levels, a Hardware‑in‑the‑Loop (HIL) or partially emulated test environment can be used as an additional Shift Left measure. It enables realistic integration, interface, and security testing before the final target system is fully available, helping to uncover defects and weaknesses earlier in a reproducible pre‑production setup.

Conclusion

The Shift Left principle is therefore not merely a development methodology preference. For connected medical devices subject to IEC 81001‑5‑1, IEC 62304, and the FDA Cybersecurity Guidance, it is the only architecture that ensures continuous compliance and allows a team to arrive at the design transfer phase without surprises.

References

Go back