Improve OpenSSF Scorecard score (currently 6.5/10)

[pavank63]

Overview

We ran the OpenSSF Scorecard (v5.4.0) to evaluate this repository's security posture. Scorecard checks open source projects against a set of security best practices — covering CI/CD hygiene, dependency management, vulnerability handling, and more. Each check is scored 0–10, with an aggregate score summarizing overall health.

Current aggregate score: 6.5 / 10

The project scores well in areas like CI testing, code review, and maintenance activity, but has gaps in workflow security hardening and security policy documentation that are worth addressing.

Current Scores

Score	Check	Status
10/10	Binary-Artifacts	No binaries found in the repo
10/10	CI-Tests	All merged PRs checked by CI
10/10	Code-Review	All changesets reviewed
10/10	Contributors	29 contributing organizations
10/10	Dangerous-Workflow	No dangerous patterns detected
10/10	Dependency-Update-Tool	Update tool detected
10/10	License	License file detected
10/10	Maintained	Active development (30 commits, 28 issues in last 90 days)
10/10	Packaging	Packaging workflow detected
9/10	Vulnerabilities	1 existing vulnerability detected
5/10	Branch-Protection	Not maximal on all branches
0/10	Token-Permissions	Workflow tokens with excessive permissions
0/10	Pinned-Dependencies	Dependencies not pinned by hash
0/10	SAST	No static analysis on all commits
0/10	Security-Policy	No SECURITY.md file
0/10	Fuzzing	No fuzzing detected
0/10	CII-Best-Practices	No OpenSSF best practices badge
N/A	Signed-Releases	No releases found

Areas to Improve

Below are some suggested fixes for each area. These are starting points — the approach for each may need to be adapted based on project preferences and maintainer input.

1. Token-Permissions (0/10) — High Priority

Problem: check.yaml and test.yaml have no permissions declared at any level. python-publish.yaml has id-token: write at the job level (correctly, for PyPI trusted publishing), but no top-level restriction — so the token still has full read-write access to everything
else.

Suggested fix:

• Add a top-level permissions: contents: read to all three workflow files
• Keep the existing job-level id-token: write on the build-n-publish job in python-publish.yaml
• Use the StepSecurity workflow analyzer to verify minimum required permissions

2. Security-Policy (0/10) — High Priority

Problem: No SECURITY.md exists anywhere in the repo. Security researchers have no private channel to report vulnerabilities.

Suggested fix:

• Create a SECURITY.md in the repository root (or .github/)
• Include: supported versions, how to report a vulnerability (private contact/email), expected response timeline, and disclosure policy
• Enable private vulnerability reporting in repo settings

3. SAST (0/10) — Medium Priority

Problem: No static application security testing tool runs on commits. The project has a solid pre-commit setup (ruff, mypy, editorconfig, mdformat) but no security-focused linter.

Suggested fix:

• Enable CodeQL via GitHub's Security tab → Code scanning → Set up CodeQL
• Alternatively, add Bandit as a pre-commit hook (fits naturally alongside the existing ruff and mypy hooks in .pre-commit-config.yaml)
• Configure to run on all pull requests and pushes to main

4. Pinned-Dependencies (0/10) — Medium Priority

Problem: All GitHub Actions references use mutable version tags (e.g., actions/checkout@v6, actions-rs/toolchain@v1, pypa/gh-action-pypi-publish@release/v1) instead of commit SHA hashes. Dependabot is already configured for the github-actions ecosystem which is good —
it can automate SHA updates once actions are pinned. Additionally, pip install commands in workflows and e2e scripts are not pinned.

Suggested fix:

• Pin all GitHub Actions to full commit SHAs (e.g., actions/checkout@b4ffde65f... # v6.2.1)
• Use the StepSecurity secureworkflow tool to auto-generate pinned versions
• The existing Dependabot config (.github/dependabot.yml) will automatically keep pinned SHAs up to date
• Affected files: .github/workflows/check.yaml, .github/workflows/python-publish.yaml, .github/workflows/test.yaml

5. Vulnerabilities (9/10) — Medium Priority

Problem: 1 known vulnerability detected in dependencies. Note that the current Dependabot config only covers github-actions — it does not monitor Python package dependencies for known CVEs.

Suggested fix:

• Review Dependabot alerts in the Security tab and patch the flagged dependency
• Consider adding a pip ecosystem entry to .github/dependabot.yml to get alerts for Python dependency vulnerabilities

6. Branch-Protection (5/10) — Low Priority

Problem: Branch protection rules are not maximal on all branches.

Suggested fix:

• Review branch protection settings for main in repo Settings → Branches
• Consider enabling: require status checks, require reviews before merging, dismiss stale reviews, require signed commits

7. Fuzzing (0/10) — Low Priority

Problem: No fuzz testing detected. This is less critical for a Python project than for C/C++/Go projects.

Suggested fix (optional):

• Consider integrating Hypothesis for property-based testing
• For OSS-Fuzz integration, follow the OSS-Fuzz guide

8. CII-Best-Practices (0/10) — Low Priority

Problem: No OpenSSF best practices badge.

Suggested fix:

• Register the project at https://www.bestpractices.dev/
• Complete the self-assessment questionnaire for the "passing" badge level

Running Scorecard Periodically

Rather than running scorecard manually each time, we should set up the ossf/scorecard-action as a GitHub Actions workflow to run on a recurring schedule (e.g., weekly). This would automatically track our score over time, surface
regressions early, and publish results to the OpenSSF Scorecard dashboard so the score is publicly visible. It can also upload findings as SARIF to GitHub's Security tab, making them visible alongside Dependabot and CodeQL alerts.