sscsb

p4gs/sscs-bootstrapper

A+

https://github.com/p4gs/sscs-bootstrapper · scanned 2026-09-03 at c8a23493ec0c on main · sscsb 0.3.1 · methodology v1 · scan run · verified+ local 8

100% of the answered checks passed · 90.9% of the checks were answered at all

verified needs attention unverified — outside the math

Defences found, by attack group

This lists defences the scan found, not weaknesses it found. A missing defence is not a break-in, and a full set of checks is not safety: nine groups and 54 checks do not cover everything. What the nine groups are →

These checks do not stop an attack. They let an outsider tell what a project already does, and where to report a problem. They are not in the list above: best-practices-badge, compliance-map, osps-baseline, publish-targets, secure-repo, security-insights.

Raw sscsb verdicts and every reclassification are shown — transparency about what was and wasn't verifiable is the product.

Phase 1 — Commit integrity

8 pass · 0 fail/gap · 1 unverified
100%

Phase 2 — Dependencies

7 pass · 0 fail/gap · 1 unverified
100%

Phase 3 — Build receipts

8 pass · 0 fail/gap · 0 unverified
100%

Phase 4 — Code & build hardening

4 pass · 0 fail/gap · 0 unverified
100%

Phase 5 — Ongoing posture

3 pass · 0 fail/gap · 1 unverified
100%

Phase 6 — Distribution & publishing

0 pass · 0 fail/gap · 0 unverified
no evidence

Authenticated scan — signature verified

This record was produced in the repository's own CI and keyless-signed there. Before listing it, the directory verified the Sigstore bundle against the certificate identity https://github.com/p4gs/sscs-bootstrapper/.github/workflows/sscsb-scan.yml@refs/heads/main bound to commit c8a23493ec0c on 2026-09-03. The repository, workflow path, and default branch are burned into that certificate by GitHub's OIDC issuer, not asserted by the record. Amber and hatched links above are the work list: adopt the flagged controls, re-run the action, and the next record replaces this one.

scan-record.json Signature bundle Action docs

Local scan — signature verified

A maintainer ran sscsb on their own machine and signed the record with their git signing key. The directory verified that detached SSH signature with ssh-keygen -Y verify against .sscsb/policy/allowed_signers fetched from this repository at commit 3cb129084db2 — committed content the submitter does not supply. Verifying principal 10093271+p4gs@users.noreply.github.com (SHA256:prXatGO56nl8Or4JdDSzIIcj8hZE1jBxnFaXZOnAPDQ) on 2026-09-11.

What that proves, exactly: a holder of a key this repository commits as an approved signer asserts this result at that commit — nothing further. It is a real link, and a shorter chain than an authenticated scan, which proves the repository's own CI produced the record.

It forged 8 controls: commit-signing, ai-trailers, ai-dep-gate, ai-receipts, package-trust, bumblebee, grype, socket-firewall. Every other class comes from the repository-observable record above; a local scan never overturns one, and never widens the scope it is measured against.

ssh-keygen -Y verify -f allowed_signers \
  -I "10093271+p4gs@users.noreply.github.com" -n sscsb-scan-record \
  -s scan-record.local.json.sig < scan-record.local.json
scan-record.local.json Detached signature

What the evidence merge found

The local record describes commit 3cb129084db2, while the repository scan on this listing describes c8a23493ec0c. Its local-environment rows may predate the code above them.

Two scores are on this page and only one of them is ours. The grade and coverage shown here — A+, 100%, coverage 90.9% — are the DIRECTORY's, computed from every evidence source it holds under the published methodology. The signed local record linked below carries its own score block (A+, 100%, coverage 89.5%): that is the SUBMITTER's self-report, computed on their machine over the controls that machine had in scope. It is republished byte-identically because the signature covers those exact bytes, not because the directory endorses the number.