✨ Separate check from policies for the Vulnerabilities check

[laurentsimon]

checker/raw_results.go: add structure for results
checks/vulnerabilities.go: rewrite fr policy seperation
checks/raw/vulnerabilities.go: data retrieval
checks/evaluation/vulnerabilities.go: score calculation
pkg/json_raw_results.go: displays the results.

Refactor the Vulnerabilities check by separating the data retrieval and policy (score) evaluation.
This will allow users to create their own policies based on the raw (more structured) results, see ttps://github.com//issues/1245

No breaking changes.

[justaugustus]

@laurentsimon -- Overall looks good, just a few nits.

Can you also tighten up the commit messages?

<area>: <what's changing>

<why it's changing>

<footer/signoff>

ref: https://cbea.ms/git-commit/

[naveensrinivasan]

@laurentsimon -- Overall looks good, just a few nits.

Can you also tighten up the commit messages?

<area>: <what's changing>

<why it's changing>

<footer/signoff>

ref: https://cbea.ms/git-commit/

Great suggestion, but this is not a blocker IMO. We have been following a process for our commits and it is working.

We don't stress for sign-off. If we want to bring such changes, can you please create an issue?

[laurentsimon]

@laurentsimon -- Overall looks good, just a few nits.

Can you also tighten up the commit messages?

<area>: <what's changing>

do I need to write <area> because we're going to use a tool for release notes? Or is this just a placeholder?

<why it's changing>

same question as above.

<footer/signoff>

ref: https://cbea.ms/git-commit/

what should I add in the footer/signoff?

[laurentsimon]

@laurentsimon -- Overall looks good, just a few nits.

Can you also tighten up the commit messages?

<area>: <what's changing>

<why it's changing>

<footer/signoff>

ref: https://cbea.ms/git-commit/

tell me if the new description is fine or not, thanks.

[justaugustus]

We don't stress for sign-off. If we want to bring such changes, can you please create an issue?

Sure, that's a larger discussion: #1533

do I need to write <area> because we're going to use a tool for release notes? Or is this just a placeholder?

This is more for code hygiene than anything else. Ideally, you can interrogate a commit message and understand exactly why a change happened.

Imagine you're debugging a regression and looking through the tree for a code change that was maybe not as innocuous as you expected.

Would you prefer to see:

linter

OR

checks/raw: Fix `errcheck` lint warnings

Another example:

githubrepo updates

OR

clients/githubrepo: Refactor clients to accept `log.Logger`

[github-actions]

Integration tests success for
[2ea7b66]
(https://github.com/ossf/scorecard/actions/runs/1752414051)

[david-a-wheeler]

Given the previous comments from @swinslow , we might want to change all copyright statements to something like:

// Copyright Security Scorecard Authors

See Copyright Notices in Open Source Software Projects. I believe the legal requirement for the copyright statement (with the date) ended in the US in 1976 :-).

[laurentsimon]

friendly ping for LGTM.

[justaugustus]

Thanks @laurentsimon!

[naveensrinivasan]

Needs more tests for this https://codecov.io/gh/ossf/scorecard/commit/5f9fff3b20ce7eb933978c7a4f9391cb2c9b3d89