Security: Improving OpenSSF Scorecard Rating for Enterprise Compliance (Targeting 7.0+)

[ecervantescelonis]

Description

Hi Valibot team! First off, thank you for building such an incredible, tree-shakable validation library. The performance and tiny bundle footprint have been massive wins for the ecosystem.

Our organization is actively evaluating Valibot for a core project, but we operate under a strict internal compliance policy that requires any third-party dependencies to meet a minimum threshold score of 7.0 on the OpenSSF Scorecard audit.

Currently, Valibot's real-time scorecard registers at 5.2 / 10.

While Valibot already scores exceptionally well on critical metrics like Dangerous-Workflow (10/10), Binary-Artifacts (10/10), and CI-Tests (9/10), there are a few process-level configurations dragging down the aggregate score. Addressing these would help enterprise developers clear compliance hurdles smoothly.

---

Low-Hanging Fruit to Push the Score Past 7.0

According to the OpenSSF Scorecard CLI output, we can easily clear the 7.0 compliance bar by tightening a few configurations across the repository workflows:

1. Define Explicit Top-Level Token Permissions (Currently 0/10)

The scorecard is flagging that several workflows (such as .github/workflows/ci.yml and publish.yml) do not explicitly define restrictive top-level repository token permissions at the root.

• Remediation: Declaring explicit read-only permissions at the absolute top of the workflow files securely drops ambient privileges:

  permissions:
    contents: read

[fabian-hiller]

Hey, thank you so much for bringing it to our attention. Yes, we are happy to do what we can to raise the score. We should generally be in a great position for this. Would you be interested in helping us, e.g., by creating PRs? If you don't have time, no worries. I will try to prioritize these issues and work on them ASAP.

@dosu, please do some research for us and determine the steps we need to take to get a 10 out of 10 score, ordered by the amount of effort needed.

[dosubot]

Hey @fabian-hiller! I did a thorough audit of the repository against all 18 OpenSSF Scorecard checks. Great news — Valibot is already in solid shape on many fronts, and recent work on pinned dependencies and Dependabot has knocked out two checks already. Here's everything needed to reach 10/10, ordered from quickest to most effort:

---

🟢 Already Scoring Well (No Action Needed)

• Dangerous-Workflow (10/10) — no dangerous patterns [1]
• Binary-Artifacts (10/10)
• Pinned-Dependencies (10/10) — all Actions pinned to commit SHAs [2]
• Dependency-Update-Tool (10/10) — Dependabot configured [2]
• License (10/10) — MIT license present [3]
• Maintained (10/10) — actively developed
• CI-Tests (9/10) — comprehensive CI [1]
• Packaging — published to NPM and JSR [4]

---

Phase 1: Quick Wins (~2 hours) → Expected score: ~7.5/10

1. Token-Permissions (0/10 → 10/10) — ~30 min
The biggest single improvement. Add explicit top-level permissions: contents: read to all workflow files (ci.yml, publish.yml, security.yml), then declare specific write permissions only at the job level where needed. StepSecurity's tool can auto-generate the correct config [5].

2. Branch-Protection (~0/10 → 10/10) — ~15 min
Enable full branch protection in GitHub Settings → Branches [5]:

• Require PRs with 2 approvals, dismiss stale approvals on new pushes
• Require review from Code Owners
• Require approval of most recent push
• Include administrators in restrictions
• Require status checks to pass and branches to be up to date

3. Security-Policy Enhancement (~4/10 → 10/10) — ~1 hour
The existing SECURITY.md needs expansion to include: a disclosure timeline (e.g. "90-day coordinated disclosure"), what constitutes a vulnerability, a response process with timelines, supported versions table, and a link to GitHub Security Advisories [5].

---

Phase 2: Medium Effort (~8–13 hours) → Expected score: ~9.0/10

4. Full SAST with CodeQL (~6/10 → 10/10) — 2–4 hours
The current security workflow runs CVE scanning [6] but not full source-code analysis. Add CodeQL init + analyze steps for JavaScript/TypeScript alongside the existing OWASP scanning [5].

5. SBOM Generation (0/10 → 10/10) — 2–3 hours
Add CycloneDX SBOM generation to the publish workflow and attach it as a release artifact. Something like npx @cyclonedx/cyclonedx-npm --output-file sbom.json [5].

6. Signed Releases / SLSA Provenance (0/10 → 10/10) — 4–6 hours
Add SLSA provenance generation using slsa-framework/slsa-github-generator to cryptographically attest build provenance. Alternatively, Sigstore offers a simpler path [5].

---

Phase 3: Advanced / Long-Term (~28+ hours) → Expected score: 9.5–10.0/10

7. Fuzzing (0/10 → 10/10) — 8+ hours
For a validation library, fuzzing is especially valuable. Property-based testing with fast-check is the lightest option (OpenSSF detects it). OSS-Fuzz integration is the gold standard [5].

8. CII Best Practices Badge (0/10 → 5–10/10) — 20+ hours
Comprehensive self-certification at bestpractices.dev. A Passing badge gets 5/10, Silver gets 7/10, Gold gets 10/10. Many criteria overlap with the above, so completing them first reduces the remaining work here [5].

---

Bottom line: Phase 1 alone (about 2 hours of work) should push the score past the 7.0 compliance threshold @ecervantescelonis mentioned. Phases 1+2 together should land around 9.0/10. The Token-Permissions fix is the single highest-impact change — 30 minutes of work for a massive score jump.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[ecervantescelonis]

Hey @fabian-hiller and team,

I’d love to help! In fact, I've just submitted a Pull Request that completely tackles Point 1 (Explicit Token-Permissions) across the repository.

You can find the PR here: #1544