How to lock down development for FDA regulated environment

Technical Support
, ,
#1

All,

This is Visual Studio Code and plug-in specific.
I’m using the Verdin full sized carrier and an iMX8M Plus but that doesn’t matter for this question.

I worked my way through the Python example.
https://developer.toradex.com/getting-started/module-2-first-steps-with-torizon/build-and-run-your-first-application-visual-studio-code

I was somewhat shocked when I saw this happening

[09-21 07:11:35.347] Step 5/16 : RUN apt-get update     && apt-get install -y --no-install-recommends     dos2unix     python3-minimal     python3-pip     python3-setuptools     && rm -rf /var/lib/apt/lists/*
[09-21 07:11:35.556] ---> [Warning] The requested image's platform (linux/arm64/v8) does not match the detected host platform (linux/amd64) and no specific platform was requested
[09-21 07:11:35.557] ---> Running in ed678ba7df4c
[09-21 07:11:37.575] Get:1 http://deb.debian.org/debian bullseye InRelease [116 kB]
[09-21 07:11:37.771] Get:2 http://deb.debian.org/debian bullseye-updates InRelease [39.4 kB]
[09-21 07:11:37.797] Get:3 http://security.debian.org/debian-security bullseye-security InRelease [44.1 kB]
[09-21 07:11:37.974] Get:4 https://feeds.toradex.com/debian/snapshots/20210909T072507Z testing InRelease [13.0 kB]
[09-21 07:11:41.440] Get:5 http://deb.debian.org/debian bullseye/main arm64 Packages [8068 kB]
[09-21 07:11:47.043] Get:6 http://deb.debian.org/debian bullseye-updates/main arm64 Packages [2304 B]
[09-21 07:11:49.576] Get:7 http://security.debian.org/debian-security bullseye-security/main arm64 Packages [71.6 kB]
[09-21 07:11:54.403] Get:8 https://feeds.toradex.com/debian/snapshots/20210909T072507Z testing/main arm64 Packages [133 kB]
[09-21 07:11:55.004] Get:9 https://feeds.toradex.com/debian/snapshots/20210909T072507Z testing/non-free arm64

later on it pulled down and installed a bunch of other stuff from deb.debian.org

At some point when I was sitting there idle VSCode decided to magically install stuff as well.

vscode-downloading-stuff-dynamicly

I know kids today think reaching out across the Web to get the latest build of everything is super cool, but in a regulated environment this cannot happen. You have to vet every tool. If one needs to make a minor change, like some text on the screen, you don’t want to go through a full new product verification process with clinical trials because new libraries were introduced; you want to go through the minor change approval path.

How can we lock down your plug-in so it only looks either locally in the VM or a secured and privately hosted repo?

We cannot have the build just finding things on the Web and adding them to the container. Every version of everything must remain locked down.

#2

Greetings @seasoned_geek,

I’m not entirely sure this would be possible with the current iteration of our plugin. Or at least not possible without having to force/break things. Also since by the nature of the plugin most tasks are auto-generated I’m not sure if these behaviors could be overwritten.

It might be easier for control sake to work outside of the IDE where things like containers and Dockerfile can more easily be set.

Note sure how far down the container hole you’ve went by the main thing you’d need to control would be the Dockerfile which is essentially the blueprint for the container.

Most containers are based off another container via the FROM statement. First things first you’d need to freeze the base container. If the base container changes then you re-build the dependent container this will obviously results in a different container. This can be fixed via pulling by digest instead of tag as shown here: docker pull | Docker Documentation

Digest are immutable and always refer to a specific version of container.

Next would be to freeze the Debian feeds in the container. You can do this via snapshot feed similar to what we do in our Dockerfiles: debian-docker-images/Dockerfile at bullseye · toradex/debian-docker-images · GitHub

This will freeze the apt feeds to a certain point in time, therefore they’ll never change/update.

Off the top of my head these would be the steps required to essentially “lock down” a container development environment. However like I said earlier this would probably be easier to do outside of the IDE environment, just due to how our plugin works.

Best Regards,
Jeremias