New guide on container security best practices

[riverma]

Purpose

• A best practice guide to help folks easily scan container (docker) related code repositories for vulnerabilities, automatically

Proposed Changes

• [ADD] New best practice guide and associated files
• [CHANGE] Yarn plugin added to help render code snippets

Issues

• [New Best Practice Guide]: Container Vulnerability Scanning #155

Testing

• Site rendered locally successfully and without build errors
• See example of guide: https://riverma.github.io/slim/docs/guides/software-lifecycle/security/dependency-vulnerability-scanning/

[nutjob4life]

Minor "here" hyperlink issue but otherwise looks great, reads great. And I learned about .mdx files!

[riverma]

Minor "here" hyperlink issue but otherwise looks great, reads great. And I learned about .mdx files!

Thanks for reviewing this @nutjob4life! Much appreciated! Yeah - MDX is allowing these guides to get all fancy, with embedded code and additional features. Some interesting possibilities down-the-line!

Curious if the hyperlink issue you were seeing was related to this block or somewhere else?

[nutjob4life]

@riverma weird, my comment got dropped somehow.

Anyway, the issue is the hyperlinking of [here]. It's a pet peeve of mine. Hyperlinking the word "here" makes a tiny target (Section 508 issue) but also relatively free of context. Read more about it.

You can rework it by writing something like:

NOTE: you'll need a DockerHub account to run the `docker scout` tool.
Note that this command will compare a local scan's results with Docker's database.
[More information about Docker Scout is available](https://docs.docker.com/scout/quickstart/).

[riverma]

Minor "here" hyperlink issue but otherwise looks great, reads great. And I learned about .mdx files!

@riverma weird, my comment got dropped somehow.

Anyway, the issue is the hyperlinking of [here]. It's a pet peeve of mine. Hyperlinking the word "here" makes a tiny target (Section 508 issue) but also relatively free of context. Read more about it.

You can rework it by writing something like:

NOTE: you'll need a DockerHub account to run the `docker scout` tool.
Note that this command will compare a local scan's results with Docker's database.
[More information about Docker Scout is available](https://docs.docker.com/scout/quickstart/).

Thanks for the clarification! Feedback incorporated 👍

[lewismc]

Hi @riverma explicit mention of Docker in the title is probably necessary. Reasoning; there are many (OCI-compliant) alternatives to Docker which could also be scanned for security vulnerabilities.
That is unless you want to broaden the scope of this best practice outside of Docker. Just food for thought :)
Nice work.

[riverma]

Hey @lewismc - great observation! I was wanting to keep this guide title general so that we could support content for the Docker alternatives as well down-the-line.

That being said (and we could get feedback from @NASA-AMMOS/slim-community here too) - which other containers should we support within this guide? By that I mean: which other container technologies are actually being used by your projects right now or will be in aspiration? True to the SLIM philosophy - we tend to make guides that are targeted towards solutions / technology by our community members, and as the community grows, we iterate and expand the scope. (CC @NASA-AMMOS/slim-community-member-leads)

[jpl-jengelke]

The Open Container Initiative (OCI) is a standard started and promoted by Docker, amongst others. Many on Lab are now using Podman, which reports to be OCI-compliant, in place of Docker. In fact, I believe it is mandated going forward on AWS for some teams. Here is more information on Podman origins.

Thinking off-the-grid, what about making it an OCI-compliant container security guide?

[riverma]

Hi @lewismc @jpl-jengelke - thought about your suggestions, discussed a bit with @lylebarner and ended up swapping to the grype toolkit, which is OGC compliant and not Docker specific. Moreover, it can scan non-containers as well.

[jpl-jengelke]

I didn't engage a formal review, but added a number of comments. Hopefully they are helpful.

Also, I wanted to note there is no reason why we cannot have multiple container security guides, including a specific Docker container security guide.

[riverma]

One suggestion from @ddalton-swe is to look at this tool (which is being utilized for some current projects): https://github.com/anchore/grype

[riverma]

Thank you for the extensive review @jpl-jengelke . I’m going to try out an OCI complaint tool to support non-Docker containers, but if they are insufficient I’ll suggest with take @lewismc suggestion and make this a Docker specific guide for now and add in other scanning tools the community suggests for other container types later.

[riverma]

@NASA-AMMOS/slim-community - I've made some updates to this PR to take into account feedback from @nutjob4life @jpl-jengelke @lewismc. Let me know if you have other thoughts!

See live rendering here: https://riverma.github.io/slim/docs/guides/software-lifecycle/security/dependency-vulnerability-scanning/

[nutjob4life]

This is a fabulous guide and I am looking forward to bringing Grype into my toolchain. Big time approval.

I did have some comments but they can largely be ignored.

One other comment: the image static/img/continuous-testing-image.png is included in the pull request but isn't referenced? Did I miss it?

Thanks for the guide!

[nutjob4life]

If you're going to call YAML files .yml, I will insist you call HTML files .htm 😈

[riverma]

I hear you @nutjob4life! However, this is a "feature" of the pre-commit tool itself. It doesn't recognize yaml extensions by default, it is strictly looking for a .pre-commit.yml file in the local repository. There is a workaround (use the --config parameter), but its extra typing. See pre-commit/pre-commit#702

[nutjob4life]

Hi @riverma, unless my dyslexia is kicking in, I think that's reversed. The pre-commit tool looks specifically for .pre-commit-config.yaml (with the a).

The issue cited wanted support without the a (.yml) but the maintainers were all "nah bro".

[riverma]

@nutjob4life - apologies! I keep making the mistake of citing things that actually contradict my argument 😂. I could’ve sworn I got an error message from pre-commit though. Let me do some digging and share feedback.

BTW what is your opinion on .jpg vs .jpeg? ;)

[nutjob4life]

BTW what is your opinion on .jpg vs .jpeg? ;)

@riverma don't get me started 🤣

But I will leave you with this:

[riverma]

🤯

[riverma]

This is a fabulous guide and I am looking forward to bringing Grype into my toolchain. Big time approval.

I did have some comments but they can largely be ignored.

Thanks for the guide!

Thanks @nutjob4life - appreciate you taking the time and glad the guide is useful!

One other comment: the image static/img/continuous-testing-image.png is included in the pull request but isn't referenced? Did I miss it?

Looks like main wasn't merged fully in this branch. I've updated and changes like the above are no longer in the PR. Thanks for catching this.