Ready for some pain? We need to document our libraries because they're SOUP.
SOUP stands for Software of Unknown Provenance. In human language, those are your libraries. Nowadays, these are open-source libraries which you include in your package.json or Gemfile.
But how do you document it?
It depends on your IEC 62304 software safety class again. For class A, it's pretty uncomplicated.
For class B and C, it gets more tricky, so we'll see what needs to be done.
First, we'll do it for the backend Ruby code by going through our Gemfile and documenting Rails as SOUP. After that, we'll look into the package.json of the JavaScript code and document a library from there.
We'll cover:
- What to document for each library.
- What to use as "anomaly list" and how to evaluate it.
- How to introduce a risk classification of SOUP
- How to specify SOUP requirements
- How to verify SOUP without doing tests (i.e. writing code) yourself
Finally, I'll explain the point of SOUP documentation while reducing my ranting to a local minimum.
Check out the SOUP list template on our website:
[ Ссылка ]
