would it be possible to disable binary-artifact checks for gradle and mvnw wrapper jars?

[pjfanning]

• https://docs.gradle.org/current/userguide/gradle_wrapper.html
• https://maven.apache.org/wrapper/

Example failure:
https://github.com/pjfanning/excel-streaming-reader/security/code-scanning/1

These jars are commonly checked in to make building easier. If it is the OSSF's aim to discourage this common practice, then that's ok. It's just that up until now, it has not been regarded as major issue.

[laurentsimon]

Scorecard now ignores gradle wrappers ossf/scorecard@dd8fbc0, so the next release should not complain.

Scorecard now looks for the "gradle wrapper" GitHub action that verifies whether binaries have the same hash pubished by gradle's official repo. If the action is installed, scorecard ignores the binary. Is there something similar for maven?

/cc ethanent who wrote the PR

[fab1an]

This needs to be updated, since Gradle-wrapper-validation action changed it's name (https://github.com/gradle/wrapper-validation-action):

Users are encouraged to update their workflows, replacing:

uses: gradle/wrapper-validation-action@v3

with

uses: gradle/actions/wrapper-validation@v3

[spencerschrock]

This needs to be updated, since Gradle-wrapper-validation action changed it's name (https://github.com/gradle/wrapper-validation-action):

Users are encouraged to update their workflows, replacing:
uses: gradle/wrapper-validation-action@v3
with
uses: gradle/actions/wrapper-validation@v3

Thanks for the heads up. We were able to fit the fix into our planned release today, and you can see it in the v2.3.3 release.

[fab1an]

@spencerschrock This works for me mostly, but is a bit flaky. I see the binary artifacts detected issue appearing and disappearing at random. What could be the reason for this? I have the gradle validation action in my build-workflows:

• https://github.com/fab1an/kotlin-json-stream/blob/master/.github/workflows/build-master.yml#L34

Do I also need it in auxiliary workflows like OpenSSF Scorecard itself:

• https://github.com/fab1an/kotlin-json-stream/blob/master/.github/workflows/scorecard.yml
• https://github.com/fab1an/kotlin-json-stream/blob/master/.github/dependabot.yml

[fab1an]

@spencerschrock Could you please have another look in this? This check action "appears" and "is fixed" alternatingly without me changing the file.

I am changing a completely unrelated file and I get this:

[spencerschrock]

This works for me mostly, but is a bit flaky. I see the binary artifacts detected issue appearing and disappearing at random. What could be the reason for this?

So the code looks that the gradle wrapper ran successfully:
https://github.com/ossf/scorecard/blob/98ec491a888a8a0db9d83a3c7d379ae1f46321de/checks/raw/binary_artifact.go#L203-L225

I don't see your CI going red. I think there is a race condition between when Scorecard runs and when "Build Master" finishes. If scorecard runs while "Build Master" is still going, the latest workflow run wont have the "success" status. Scorecard is currently finishing for you in ~1minute instead of ~2 minutes for build master.

In terms of workarounds, I'm curious if you could change Scorecard away from push and instead run after Build master completes with a workflow_run trigger.

e.g.

on:
  branch_protection_rule:
  schedule:
    - cron: '33 9 * * 0'
  workflow_run:
    workflows: [Build Master]
    branches: [master]
    types:
      - completed

in terms of a Scorecard change, perhaps if the run is still in progress, we fall back to previous commits ?

[fab1an]

I am trying this, for now it worked.

I have a similar issue with the SAST and CI-Test rules, it keeps telling me

score is 9: SAST tool is not run on all commits -- score normalized to 9:
Warn: 29 commits out of 30 are checked with a SAST tool

and

score is 9: 29 out of 30 merged PRs checked by a CI test -- score normalized to 9
Click Remediation section below to solve this issue 

[fab1an]

I have a similar issue with the SAST and CI-Test rules, it keeps telling me

Could this be because I renamed my workflows at some point?

[spencerschrock]

codeQL didn't run for fab1an/kotlin-json-stream#7, so the 29/30 seems accurate.

In terms of closing and re-openning i'm not sure why it's doing that

[fab1an]

In terms of closing and re-openning i'm not sure why it's doing that

Like I said I renamed an action. If scorecard-action works in a way that it looks for workflow-files and checks whether the workflow in it ran for the last 30 PRs by name, then it could miss the rename.