OpenSSF improvements
A maintainer worksheet: where the OpenSSF Scorecard number is capped for a one-maintainer project and what could still move it. Work already shipped isn’t repeated here; SECURITY.md lists it. Anything marked to check hasn’t been confirmed against the live Scorecard report or the repository settings yet.
Scorecard: where the ceiling is
.github/workflows/scorecard.yml publishes the score after every green CI run on a push to main, weekly, and when a branch protection rule changes; the README badge reads it. The checks that are capped or open:
| Check | Status | Why, and what would move it |
|---|---|---|
| Code-Review | Capped | One maintainer (GOVERNANCE.md), so nobody else can approve a pull request. A Reviewed-by: trailer would satisfy the scanner without a review having happened, and won’t be added. Not fixable without a second person. |
| Contributors | Capped | The check wants contributors from at least two organizations; there’s one. |
| Fuzzing | Open, candidate | No fuzzer runs. Python is covered by the check (atheris, via OSS-Fuzz or ClusterFuzzLite), so this isn’t not-applicable: instadroid.parsing.parse_hierarchy() is pure and parses device-supplied XML, the natural first target (TESTING.md). |
| Branch-Protection | To check | Depends on the rulesets for main and dev (required checks, required pull request, who can bypass), which live in the repository settings, not in this tree. ci.yml’s CI result roll-up is meant to be the one required check. Two required approving reviews, the top tier, needs a second person regardless. |
| CII-Best-Practices | Capped | Scores 0: the project isn’t registered at bestpractices.dev and won’t be. |
| Signed-Releases | To check, likely low | Release images carry signed build-provenance and SBOM attestations, and the tags are signed, but the attestations are pushed to the registry, not uploaded as GitHub Release assets, and the check reads release assets only. |
| Pinned-Dependencies | To check | Third-party actions are SHA-pinned, the CI tools are SHA-256-pinned in tools.txt, pip installs use hashed locks (the setuptools build dependency included), the Markdown tools install with npm ci from .github/package-lock.json (transitive dependencies included), and every image is pinned by digest. Local actions are referenced as uses: ./.github/actions/..., which Scorecard exempts; it reads the $/ self-repository form as an unpinned third-party action, so lint_workflows.sh rejects that form. |
| Token-Permissions | To check | Every workflow defaults to contents: read (Scorecard’s own workflow to read-all, as publish_results requires) and grants writes per job. |
| Packaging | To check | publish.yml publishes to GHCR from a tag; confirm the check detects it. |
| Vulnerabilities | To check | OSV reads both hashed locks; advisories.yml runs pip-audit on the same locks and npm audit on the Markdown tools’ lock, weekly and after each merge to main, into one tracking issue. |
Expected to be at or near 10 with nothing to do: Binary-Artifacts (no binaries tracked), Dangerous-Workflow (no pull_request_target; the workflow_run workflows, advisories.yml, coverage.yml, image-scan.yml, link-check.yml, pages.yml, scorecard.yml and tool-versions.yml, act only on a green run from main and check out no pull request code), Dependency-Update-Tool (.github/dependabot.yml), License (LICENSE.md, MIT), Maintained, SAST (CodeQL on every push and pull request) and Security-Policy (docs/SECURITY.md). To check against the live report.