Guide on Code Security Scanning

[ingyhere]

Purpose

• Add new security scanning guide focused on the NASA SCRUB tool

Proposed Changes

• [ADD] README contents

Issues

• [Improve Best Practice Guide]: Security scanning with SCRUB, et. al. #25

Testing

• Locally tested with sample repository: full scan, pre-commit hook
• See rendered guide here: https://github.com/NASA-AMMOS/slim/tree/issue_25/docs/guides/software-lifecycle/security/security-scanning

[riverma]

@ingyhere - just a note, adding labels for the type of SLIM best practice category each PR applies to (i.e. governance, software lifecycle, information sharing) helps to make future release notes more readable. See information about categories here.

Also - adding the SLIM Project Board in the PR right hand menu, and tagging the status as well as the iteration helps people understand the time line for the PR.

[riverma]

Great progress on this! Added some comments to consider. One thing additional to note, just remember to add a registry entry so that the guide appears properly in our search. See directions here.

[riverma]

Can we ship this guide with some working scrub.cfg file examples the reader can just drop in and start using?

[ingyhere]

I'm planning to rename it as scrub.yml and, yes, I'll try to add some examples for scrub.cfg.

[riverma]

Sorry - you were thinking of renaming what to scrub.yml?

I'll try to add some examples for scrub.cfg

Awesome! If we can include those files not just as snippets but stand-alone files within /security-scanning, that would allow our infusion automation to easily pick up and propose a solution via pull requests. Now that I think of it: if I wanted to say propose the recommendations you all have put down here via a pull request to a given project repository, which files would I need to propose? A scrub.cfg and a GitHub Action workflow file? Again - having not just a snippet but a file version of the two would make infusion automation much easier to do.

[ingyhere]

Sorry, to clarify,

Workflow file (example in slim-starterkit-python):
codeql.yml -> scrub.yml

The config file would be the same name...

[riverma]

Got it @ingyhere - that makes sense!

[ingyhere]

Done, not resolved yet. Needs a little more testing.

[riverma]

This is more of a question: what happens if I enable all languages? Does CodeQL get confused or is it smart enough to ignore the irrelevant languages? If the latter - can we just list all languages by default so readers don't need to change anything?

[ingyhere]

In most cases it should automatically build correctly. But there is an additional step that can be implemented (see comments) to manually build. This is a bit more involved, see this.

[ingyhere]

After re-reviewing, the comments, ordering and documentation here need a bit of work.

[ingyhere]

@ingyhere - just a note, adding labels for the type of SLIM best practice category each PR applies ...

Also - adding the SLIM Project Board in the PR right hand menu, and tagging the status ...

Done

[nutjob4life]

@jpl-jengelke, quick favor: when this moves out of "draft" state, could you ping me @nutjob4life? I tend to mute draft PRS both logically and mentally 😇 Nevermind, I saw it go out of draft "live" during the tag-up meeting on 2024-05-02

[nutjob4life]

Superbly written guide with a great cadence and feel as well as utility. Should make SCRUB a much easier pill to swallow. Bravo! 🎉

[ingyhere]

Superbly written guide with a great cadence and feel as well as utility. Should make SCRUB a much easier pill to swallow. Bravo! 🎉

Unfortunately as things go ... I see some areas for improvement. But I will make changes and ask for re-review.