Tuesday, June 03, 2025

Synergies Between Regulatory Compliance and DevSecOps

After 15+ years building medical device software, I've learned something counterintuitive: FDA regulations don't slow down secure development—they accelerate it. For as long as I've been a Software Engineer, I've thought about the things that can and will go wrong in software, and what the security implications could be.

The modern view of this is called "DevSecOps". This is short for Development, Security, and Operations, a software engineering culture and practice that integrates security into all phases of the software development lifecycle, promoting a culture of shared responsibility for security.

If you think about how this point-of-view maps to the world of regulatory compliance for medical devices and software, there are fundamentals that are key for both. For instance, ISO62304 and the DevSecOps are concerned with Hazard Analysis and Threat Modeling respectively, as well as requiring traceability and auditing capabilities as foundational for risk management. The emergence of DevSecOps has driven a welcome "left shift" of cybersecurity into the software development cycle, making security part of requirement and design. This is getting teams to think about security earlier and not consider it a "bolt-on" activity. The regulatory requirements actually enhance DevSecOps. 

For Instance: Paying attention to the software manifests and SBOM from the start can help drive conversations such as "Do we really need that library?", "What vulnerabilities does the library have?" and “Do we really need 47 dependencies for one feature?”.  If you have to answer these questions at deployment, without having given them prior consideration, it is a painful, rushed and more error-prone process than it needs to be. An SBOM that meets FDA guidelines is going to support good vulnerability management practices.

Lastly, the testing required for medical devices usually exceeds the scope and depth of testing done solely for cybersecurity. It's not a question of either/or but both for a successful deployment/release.

 


No comments: