Scanning of container images

[planetf1]

Having images that are scanned for vulnerabilities provides more confidence for users wanting to run or adopt our demo images

One approach I've used in the past is to post to quay.io (in addition to docker.io).

I believe quay.io is free for public opensource repositories.

See https://docs.redhat.com/en/documentation/red_hat_quay/3/html-single/about_quay_io/index#vuln-database-clair

There may also be other free scanners that could be used.

Performing scanning will mean we should review the results, and appropriately mitigate the findings. Regular updates would likely be needed to base images etc.

[planetf1]

Another reason for adding another repo is that dockerhub are increasingly implementing tighter quota limits. However, since the demo images are exactly that, rather than for production, in most cases I doubt users would hit those limits. Possibly if coming from within a large corporate network.

OpenSource projects can apply to join dockerhub's community programme here

However this doesn't detract from the idea of trying to get some additional container scanning done cheaply.

[ghost]

We can enhance the workflow by integrating automated vulnerability scanning with Docker Scout. Utilizing the docker scout cves command allows us to scan Docker images for known vulnerabilities and generate reports in several formats, including sarif and markdown.

For instance, to generate a markdown report, you can run the following command:

docker scout cves <image-name> --format markdown > report.md

[SWilson4]

We can enhance the workflow by integrating automated vulnerability scanning with Docker Scout. Utilizing the docker scout cves command allows us to scan Docker images for known vulnerabilities and generate reports in several formats, including sarif and markdown.

For instance, to generate a markdown report, you can run the following command:

docker scout cves <image-name> --format markdown > report.md

Thanks for the suggestion, @BusyKhalid. Would you be willing to contribute a PR for this feature?

[ghost]

Sure, currently I’m working on updating the Docker files. I’ll add a separate workflow for scanning and report generation to keep everything organized.

[ghost]

As I set up workflows for the demos, I’d like to confirm the preferred approach: would it be more effective to create individual workflows for each demo, or should I design a single workflow that encompasses all demos? Any guidance would be greatly appreciated.

[SWilson4]

As I set up workflows for the demos, I’d like to confirm the preferred approach: would it be more effective to create individual workflows for each demo, or should I design a single workflow that encompasses all demos? Any guidance would be greatly appreciated.

I think a general workflow/job that runs for each demo using a matrix (or a similar approach) would be ideal. It should be easy to add future demos (e.g., by adding a value to a matrix).

[ghost]

I think a general workflow/job that runs for each demo using a matrix (or a similar approach) would be ideal. It should be easy to add future demos (e.g., by adding a value to a matrix).

I’ll go with your approach.

[alraddady]

@baentsch Since the PR https://github.com/open-quantum-safe/oqs-demos/pull/348 is approved and will be merged soon, I suggest closing this issue, what do you think?