Add OpenSSF Scoreboard analysis

[pandatix]

Currently, octoscan provides great audit value, but has no audit itself.

This PR brings the OpenSSF Scoreboard as a continuous security audit tool. It should help contributors that are non-developers but have a security profile to give them guidelines on how to help octoscan improve its security practices and posture.

My last manually-triggered audit showed current octoscan scores 4.7/10 which highlights plenty room for improvement, but no big security defect. The expected behavior with Scoreboard is to raise both the score thus the security practices and the security knowledge of the community. Moreover it has a cool badge 😄

Dependencies are pinned as a good practice from OpenSSF.

[hugo-syn]

Hi, I don't think this is relevant for this kind of project, I tried it on the repo and got the following:

• try to recruit more maintainers to the project
• Place a security policy file SECURITY.md in the root directory of your repository. This makes it easily discoverable by a vulnerability reporter
• Run CodeQL checks in your CI/CD
• Integrate the project with OSS-Fuzz
• Repository was created in last 90 days. (this is false I don't even understand this alert)

This is an offensive tool to help discover vulnerabilities, not a tool that will be deployed and executed on some servers where users can interact with it.

However, based on the output of the tool I've enabled dependabot. Another easy remediation action could be to pin the different GitHub action.

[pandatix]

Yes all scoreboard recommendations are not mandatory: you won't find any repository with a 10/10. It is more a goal and a set of good practices, a target that obviously could not be always achieved... but you have to shoot for the moon.

As you say it already provided a good value with dependabot ! It could now do even better :

• branch protection (0/10)
• pinned dependencies (3/10)
• signed releases (0/10)
• token permissions (0/10)

As an end-user of octoscan I expect the dependency to improve on its own security (I don't use it as a red team tool but for continuous assessment in a blue team effort). An example of unexpected use of octoscan could parallel scoreboard: it was not first intended to be used as a platform, but is now.

[hugo-syn]

Signed releases is a good idea, do you have examples of how to do this ?

For pinned dependencies it's too long to do for each action I don't want to loose time on this.

I've added a weak branch protection and for token permissions same I don't want to loose time on this sorry :)

[echoix]

For pinned dependencies it's too long to do for each action I don't want to loose time on this.

Renovate instead of dependabot can do that with the best-practices preset (or manually configured). It keeps the comment after the commit hash updated too, with the same granularity

[pandatix]

It keeps the comment after the commit hash updated too

dependabot can do it too. What is the value of renovate here ?

[pandatix]

Signed releases is a good idea, do you have examples of how to do this ?

SLSA has an official GitHub Action and documentation for the Go builder.

I use it often, with an example here.

[hugo-syn]

It keeps the comment after the commit hash updated too

dependabot can do it too. What is the value of renovate here ?

Do I first need to pin the commit to get this feature ?

[hugo-syn]

Signed releases is a good idea, do you have examples of how to do this ?

SLSA has an official GitHub Action and documentation for the Go builder.

I use it often, with an example here.

Ok I'll take a look thank you !

[pandatix]

It keeps the comment after the commit hash updated too

dependabot can do it too. What is the value of renovate here ?

Do I first need to pin the commit to get this feature ?

Dependabot and Renovate will work on actions pinned by the gitoid (the hash) followed by the comment of the corresponding tag. It is not mandatory for them to work, but is a good practice for integrity checks: a git tag is not immutable, while a commit is.

To sum it up, current dependabot configuration will open PRs for dependency updates, whatever the pin strategy (either per-tag or per-gitoid).

[echoix]

Renovate can do the conversion, or pin a semver up to patch instead of only major. That's what I was trying to say. It was in response to saying it would be really long to change everywhere