Initial supported practices

[mlieberman85]

This is a tracking issue for what things Skootrs needs to support from a security best practices, standards, specifications, etc. standpoint. I am assuming Go is the default supported language. Also "won't do" doesn't mean it will never be done, but just not the focus for an initial release.

Best Practices Badge: https://www.bestpractices.dev/en/criteria/0

Must Do:

• FLOSS License (default to Apache 2.0)
• Working build system
• Secured against MITM attacks - This I think happens by definition since the project is on Github
• Must not leak private credentials - we can just enforce this for what Skootrs does. Can't do it for the entire project.
• Static code analysis - Use a reasonable default.

Could Do:

• Setup versioning on releases
• Default bug reporting process
• Default vuln reporting process
• Publicly known vulnerabilities fixed (somewhat) - Turn on dependabot or similar
• Dynamic code analysis - I'm currently not aware of any good dynamic code analysis tools that just run in github actions.

Won't Do:

• Website work
• Documentation beyond just getting README and default templates
• Working test suite
• New functionality testing
• Warning flags
• Security development knowledge (Skootrs has no way of magically generating a human security expert)
• Good cryptographic practices

Scorecard checks: https://github.com/ossf/scorecard/blob/main/docs/checks.md

Must Do:

• No Binary-Artifacts (i.e. executables) in repo - Create .gitignore that ignores common binaries for the language
• Branch-Protection - Enable branch protection on github
• CI-Tests - enable common CI checks for the language
• CII-Best-Practices - (some, see best practices badge above)
• Code-Review - enforce code-review (for now single person code review)
• Dangerous-Workflow - follow these rules for everything else Skootrs is doing in Github
• Dependency-Update-Tool - dependabot or similar like renevatebot
• Fuzzing - Enable fuzing tools listed in scorecard (assuming language supports it?)
• Maintained - Skootrs can't support this directly but since a new project will fit this it should be hit automatically since a new project is less than 90 days old :)
• Packages - Github action that publishes a release
• Pinned-Dependencies - Enforce pinning like go sum file for builds?
• SAST - Turn on default SAST (CodeQL?)
• Security-Policy - Default security policy
• Signed-Releases - Looks like SLSA counts here, ideally do this. Otherwise find/build a github action that uses sigstore for signed releases? Looks like GPG also fits this but should probably look to move away from this.
• Token-Permissions - Defaults workflows managed by skootrs will follow this.
• Vulnerabilities - Run OSV scanner
• Webhooks - Not sure anything skootrs will do involves generating/managing webhooks. Check with scorecards team.

Won't Do:

• Multiple contributors from multiple orgs - Projects will inevitably have 1 contributor, the person who used Skootrs to create the project at first.

Allstar:

• This mostly overlaps with stuff checked by scorecard.

Others:

Must Do:

• Generate SBOM
• Function to forward to GUAC

Could Do:

• Default in-toto layout
• Generate SBOMit SBOM
• Default gittuf
• Default TUF
• Run Witness against build

[pxp928]

Must Do:

• Add Generate SLSA attestation workflow
• Configurable choice for SBOM being created (SPDX or CDX)
• Pinning by hash (including github actions and DockerFile)

[mlieberman85]

Must Do:

• Add Generate SLSA attestation workflow
• Configurable choice for SBOM being created (SPDX or CDX)
• Pinning by hash (including github actions and DockerFile)

For the first one I think that's covered by:

Signed-Releases - Looks like SLSA counts here, ideally do this. Otherwise find/build a github action that uses sigstore for signed releases? Looks like GPG also fits this but should probably look to move away from this.

For the second one I disagree. Remember this is just for an initial release.

For the third one that should be covered by this:

Pinned-Dependencies - Enforce pinning like go sum file for builds?

The check in scorecard states that everything including actions is considered in scope here: https://github.com/ossf/scorecard/blob/main/docs/checks.md#pinned-dependencies