[AdepuSriCharan]

Description

This PR adds an OpenSSF Scorecard workflow that assesses the Python SDK repository's supply-chain security practices.

The workflow runs on pushes to main, on a weekly schedule, and when branch protection rules change. It publishes Scorecard results using OIDC, uploads the SARIF findings to GitHub code scanning, and keeps the SARIF report as an artifact for five days. A concurrency group cancels superseded runs, so only the newest scan publishes results.

The workflow also:

• Skips forks, which the official Scorecard action does not support.
• Pins every action to a full commit SHA with a version comment. I checked each SHA against its release tag.
• Uses read-all permissions at the top level, as Add the OpenSSF Scorecard GitHub Action and publish the results #1332 asks, with explicitly scoped job permissions.
• Disables persisted checkout credentials.
• Stays within the restrictions Scorecard's publishing API enforces: no top-level env or defaults, no top-level write permissions, and only allowed actions.
• Leaves existing CI workflows and SDK code unchanged.

Validation:

• actionlint 1.7.12 passed.
• The zizmor 1.31.1 offline audit passed. In auditor mode, the only finding is the read-all default that Add the OpenSSF Scorecard GitHub Action and publish the results #1332 asks for.

Publication and code scanning uploads can only be verified upstream after merge, because the Scorecard action doesn't run on forks.

Issue reference

Closes #1332

Checklist

• Code compiles correctly

[sicoyle]

Thank you so much @AdepuSriCharan for your interest in the Dapr open source project and for putting this together! 🙌 The workflow is nicely locked down: read-only top-level permissions, a narrowly scoped job, non-persisted checkout credentials and SHA-pinned actions all line up with the upstream Scorecard template. Could you double-check that each pinned SHA matches the tag in its trailing comment? We'll also keep an eye on the first run on main, since publishing can't be exercised from a fork 👀. I left one small comment inline, please take a look.

_{Drafted with AI assistance and reviewed by me.}

[sicoyle]

nit: what do you think about adding a concurrency group here? If several pushes land on main close together, or a push lands near the weekly cron, each one kicks off a full Scorecard run that publishes results and uploads SARIF, but only the latest run actually matters. Something like this at the top level would drop the redundant runs:

concurrency:
 group: ${{ github.workflow }}-${{ github.ref }}
 cancel-in-progress: true

I'd use the block form rather than an inline { ... } mapping so the ${{ }} expression doesn't get tangled up with YAML flow syntax. Not blocking, happy to merge without it if you'd prefer to keep the workflow identical to the upstream template.

(

python-sdk/.github/workflows/scorecard.yaml

Line 26 in 54f5059

)

[AdepuSriCharan]

Thanks @sicoyle, good idea! I have added it in block form as you suggested. All three triggers run against main, so they share one group, and a newer run cancels the older one. The SARIF upload steps already skip cancelled runs. I also checked Scorecard's publish verifier, and it has no restriction on top-level concurrency, so publishing isn't affected.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 88.18%. Comparing base (461d576) to head (ba9b1e7).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1341      +/-   ##
==========================================
+ Coverage   87.83%   88.18%   +0.35%     
==========================================
  Files         163      165       +2     
  Lines       13065    13432     +367     
==========================================
+ Hits        11475    11845     +370     
+ Misses       1590     1587       -3     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.