SOUP validation

[Mystery]

Hi Everyone,

I’m currently working on an embedded medical device application and need to perform SOUP (Software of Unknown Pedigree) analysis for the following components: QML, QtQuick, and QtQuickControls.

Could anyone please guide me on how to approach this? Specifically, I’d appreciate suggestions on:

What aspects should be evaluated during the SOUP analysis?
What kind of testing or validation is recommended for these components?
Any insights, best practices, or references would be really helpful. Thanks in advance!

[SGaist]

Hi and welcome to devnet,

You might found more information here.

The Qt Company has people who can assist in preparing things for certification but you will have to contact them.

[lukas_kosinski]

Hi @Mystery. Although your topic is quite old, I thought it made sense to comment on it, as this is a question that many ask themselves, and the Qt website doesn't provide an answer. Of course, it's not their role.

I am going to answer this question as someone deeply involved in medical device software development - most of the time with Qt. We're ISO 13485 (medtech software) certified and often participate in or solely create documentation according to the IEC 62304 standard. Actually, this is somehow connected to the recently introduced EU CRA, because SBoMs will be basically a standard not only for medical apps.

It's important to know that Qt on its own isn't certified. Some tools, like Qt Safe Renderer, are.
BUT, Qt does a lot of jobs to ensure their software is of the highest quality, which is very useful for SoUP documentation. They do professional issues management, track changes, have static code analysis and unit tests so you can include it all in your documentation.

What we usually do for dependencies (whether they are Qt modules or anything else) is:

1. SBoM (Software Bill of Materials) - a detailed inventory that lists all your components (both internal and external) and their dependencies that make up the entire system. This is now required by the FDA in electronic format (like CycloneDX) as well!
2. Vulnerabilities assessment - practically speaking, an Excel table where you go through the known vulnerabilities of the components and you assess whether they can do harm to your device. It all depends on what kind and what class of device it is. You can have two types of vulnerabilities -> cybersecurity ones and functional ones. All of them can be exploited if you are not careful.

I will not focus on Quality Assurance and Validation of your internal components - code you write on your own, but rather on the dependencies. More specifically the modules you mentioned. Generally speaking, those are GUI modules so the risk is rather limited, but you have to assess them anyway.

In your SBoM you might want to document:

1. Dependency name
2. Its supplire
3. Version
4. Hash (not necessarily)
5. Software level of support
6. End-of-support date
7. License

You can also go extra and explain what's the purpose of the particular dependency, but SBoM is not a place for that. It's probably to be done in Software Detailed Design documents.

Then assessment:
Component | Version | Vulnerability | Discovery method (you can, for example go over Qt's Gerrit or public vulnerabilities trackers like NVD, CISA KEV etc) | Applicability | Potential effects (if applicable) | Dangerous situation (if applicable) | Method of control (if applicable) | Evaluation (Detectability, Severity, Probability) | Recommended actions.

Hope my answer is not overwhelming. I've tried to be as high-level and practical as possible without going into too many details. There is a lot of other work to be done around it, like the plan to handle vulnerabilities, but it's probably not a topic for this forum. In practice, all medical documentations really differ company to company.

I wrote once about Software of Unknown Provenance in Medical Devices.