morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #4898] Publish an OpenSSF Scorecard result #3040

New issue

Open

opened 2026-10-31 00:35:20 +00:00 by bsakaguchi · 3 comments

bsakaguchi commented

2026-10-31 00:35:20 +00:00

Owner

Originally created by @simlf on GitHub (Oct 17, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/4898

Problem

Third-party supply-chain views (the OpenSSF Scorecard viewer, deps.dev, and install-time trust reports such as chainoftrust.dev) find no published OpenSSF Scorecard result for morluto/rea, so its maintenance-hygiene posture shows as "not measured".

This undersells the project: rea-agents already has strong signals that are visible on npm, namely SLSA provenance attestations and npm trusted publishing from GitHub Actions (checked on rea-agents@6.5.0).

Desired outcome

A published Scorecard result for the repository, refreshed weekly, so tools that read the public Scorecard API can show it.

Suggested approach

Add the standard ossf/scorecard-action workflow (weekly schedule plus pushes to main, publish_results: true, read-only permissions except id-token: write and security-events: write for SARIF upload). It is a small, isolated workflow with no effect on the package or releases.

Evidence and gaps

Source-only observation: https://api.securityscorecards.dev/projects/github.com/morluto/rea has no result, and .github/workflows/ has no Scorecard workflow at the commit checked (3460cea).
npm registry fields checked: dist.attestations.provenance.predicateType is https://slsa.dev/provenance/v1, and _npmUser.trustedPublisher.id is github.
Not checked: what score the repository would receive.

Happy to send the workflow as a PR if that is wanted.

Originally created by @simlf on GitHub (Oct 17, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4898 ## Problem Third-party supply-chain views (the OpenSSF Scorecard viewer, deps.dev, and install-time trust reports such as chainoftrust.dev) find no published OpenSSF Scorecard result for `morluto/rea`, so its maintenance-hygiene posture shows as "not measured". This undersells the project: `rea-agents` already has strong signals that are visible on npm, namely SLSA provenance attestations and npm trusted publishing from GitHub Actions (checked on `rea-agents@6.5.0`). ## Desired outcome A published Scorecard result for the repository, refreshed weekly, so tools that read the public Scorecard API can show it. ## Suggested approach Add the standard `ossf/scorecard-action` workflow (weekly schedule plus pushes to `main`, `publish_results: true`, read-only permissions except `id-token: write` and `security-events: write` for SARIF upload). It is a small, isolated workflow with no effect on the package or releases. ## Evidence and gaps - Source-only observation: `https://api.securityscorecards.dev/projects/github.com/morluto/rea` has no result, and `.github/workflows/` has no Scorecard workflow at the commit checked (`3460cea`). - npm registry fields checked: `dist.attestations.provenance.predicateType` is `https://slsa.dev/provenance/v1`, and `_npmUser.trustedPublisher.id` is `github`. - Not checked: what score the repository would receive. Happy to send the workflow as a PR if that is wanted.

bsakaguchi commented

2026-10-31 00:35:21 +00:00

Author

Owner

@XinwangTao commented on GitHub (Oct 18, 2026):

Good suggestion — the repo already has strong supply-chain signals (SLSA provenance + npm trusted publishing), so publishing a Scorecard result just makes that posture visible to third-party tools instead of showing "not measured". The proposed workflow is minimal and isolated, which is the right shape.

A few practical notes for the PR:

publish_results: true writes the result to a public GCS bucket via the action's own identity, so the security-events: write permission is only needed for the SARIF upload — keeping read-only default permissions otherwise is correct.
Consider adding the Scorecard badge to the README once a result exists, so the repository itself surfaces the score rather than only external viewers.
Pin the workflow to a scorecard-action release tag (not main) for supply-chain hygiene, matching the project's existing pinned-toolchain approach.

@XinwangTao commented on GitHub (Oct 18, 2026): Good suggestion — the repo already has strong supply-chain signals (SLSA provenance + npm trusted publishing), so publishing a Scorecard result just makes that posture visible to third-party tools instead of showing "not measured". The proposed workflow is minimal and isolated, which is the right shape. A few practical notes for the PR: 1. `publish_results: true` writes the result to a public GCS bucket via the action's own identity, so the `security-events: write` permission is only needed for the SARIF upload — keeping read-only default permissions otherwise is correct. 2. Consider adding the Scorecard badge to the README once a result exists, so the repository itself surfaces the score rather than only external viewers. 3. Pin the workflow to a scorecard-action release tag (not `main`) for supply-chain hygiene, matching the project's existing pinned-toolchain approach.

bsakaguchi commented

2026-10-31 00:35:21 +00:00

Author

Owner

@morluto commented on GitHub (Oct 26, 2026):

Thanks for the Scorecard proposal. #4920 is the open workflow implementation and tracks publication and SARIF upload; the overlapping #5304 was closed in favor of that review. I am keeping this issue open until a result is actually published, since an open workflow PR alone does not establish an available Scorecard result.

@morluto commented on GitHub (Oct 26, 2026): Thanks for the Scorecard proposal. #4920 is the open workflow implementation and tracks publication and SARIF upload; the overlapping #5304 was closed in favor of that review. I am keeping this issue open until a result is actually published, since an open workflow PR alone does not establish an available Scorecard result.

bsakaguchi commented

2026-10-31 00:35:22 +00:00

Author

Owner

@XinwangTao commented on GitHub (Oct 27, 2026):

同意保持开放直到结果实际发布。两点补充：#4920 落地后建议在 README 放上 Scorecard badge（api.securityscorecards.dev 的 badge URL 会随结果自动更新），并把 workflow 设为每周 schedule 而非仅手动触发，第三方视图（deps.dev / chainoftrust.dev）抓取的是持续发布的结果，一次性运行仍会显示过期或缺失；另外 Scorecard 会检查 workflow 是否使用 pinned actions，仓库既然已有 SLSA + trusted publishing 的良好实践，把 #4920 的 actions 全部 pin 到 commit SHA 可以顺带把这一项也拿满分，避免"有结果但分数不反映实际安全姿态"的尴尬。

@XinwangTao commented on GitHub (Oct 27, 2026): 同意保持开放直到结果实际发布。两点补充：#4920 落地后建议在 README 放上 Scorecard badge（api.securityscorecards.dev 的 badge URL 会随结果自动更新），并把 workflow 设为每周 schedule 而非仅手动触发，第三方视图（deps.dev / chainoftrust.dev）抓取的是持续发布的结果，一次性运行仍会显示过期或缺失；另外 Scorecard 会检查 workflow 是否使用 pinned actions，仓库既然已有 SLSA + trusted publishing 的良好实践，把 #4920 的 actions 全部 pin 到 commit SHA 可以顺带把这一项也拿满分，避免"有结果但分数不反映实际安全姿态"的尴尬。

bsakaguchi referenced this issue

2026-10-31 01:07:41 +00:00

[PR #3041] [MERGED] feat(setup): add WorkBuddy client support #5575

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#3040

No description provided.

Rows
Columns