-
Notifications
You must be signed in to change notification settings - Fork 474
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
⚠️ Allow probes to specify their own bad outcomes #4020
⚠️ Allow probes to specify their own bad outcomes #4020
Conversation
No one interacts with the probes directly, and having them in the same package helps with follow up commits Signed-off-by: Spencer Schrock <sschrock@google.com>
…on for Signed-off-by: Spencer Schrock <sschrock@google.com>
Signed-off-by: Spencer Schrock <sschrock@google.com>
Signed-off-by: Spencer Schrock <sschrock@google.com>
@laurentsimon this is still a WIP as I need to switch around more probes. But this commit (eec4665) shows the new field Does this generally match what you mentioned in our meeting today? |
I was thinking we'd create a new field in the def.yml: - remediation
on: true | false
text: bla
... and use that to determine when remediation needs to be populated. Having in def.yml also helps with documentation |
Sorry, that's basically what you did - I missed the example .yml files and was looking for a def.yml. Yeah We're on the same page. +1 on having badOutcome private! |
For the yaml, I like the nested |
Signed-off-by: Spencer Schrock <sschrock@google.com>
Signed-off-by: Spencer Schrock <sschrock@google.com>
with the swap, the true outcome is now the bad outcome. Signed-off-by: Spencer Schrock <sschrock@google.com>
with the rename, the true outcome is now bad Signed-off-by: Spencer Schrock <sschrock@google.com>
Signed-off-by: Spencer Schrock <sschrock@google.com>
Signed-off-by: Spencer Schrock <sschrock@google.com>
we can always make it public again later Signed-off-by: Spencer Schrock <sschrock@google.com>
/scdiff generate Pinned-Dependencies,Contributors,Security-Policy,Vulnerabilities,Branch-Protection,SAST,CII-Best-Practices,Dangerous-Workflow,Code-Review,Token-Permissions,Signed-Releases,Fuzzing,License,CI-Tests,Binary-Artifacts,Dependency-Update-Tool,Maintained,Packaging |
What kind of change does this PR introduce?
structured result breaking change
What is the current behavior?
OutcomeNegative
which was always assumed to be negative, got changed toOutcomeFalse
, which isn't always a bad thing. Some probes detect dangerous behaviors, which would mean the remediation should be applied to OutcomeTrue.What is the new behavior (if this is a feature change)?**
The
github.com/ossf/scorecard/v4/finding/probe
package was merged intogit.luolix.top/ossf/scorecard/v4/finding
.Probes can declare in their YAML which outcome should cause the findings to have a remediation. This is done by specifying a
onOutcome
field underremediation
in the yaml:This enables fixing the outcome/probe names for some probes.
hasOSVVulnerabilities
hasDangerousWorkflowScriptInjection
hasDangerousWorkflowUntrustedCheckout
notCreatedRecently
->createdRecently
freeOfAnyBinaryArtifacts
->hasBinaryArtifacts
freeOfUnverifiedBinaryArtifacts
->hasUnverifiedBinaryArtifacts
notArchived
->archived
Which issue(s) this PR fixes
Fixes #3654
Special notes for your reviewer
Does this PR introduce a user-facing change?
For user-facing changes, please add a concise, human-readable release note to
the
release-note
(In particular, describe what changes users might need to make in their
application as a result of this pull request.)