OpenSSF evidence and maintenance
Talos has an OpenSSF Best Practices application and a public Scorecard report. The Best Practices application is in progress. Silver is a Best Practices level; Scorecard reports a separate score from zero to ten. This page records evidence and outstanding work without claiming either badge attainment or future results.
Prerequisites
Assess the exact public commit, recorded test environment and executed release. A candidate workflow is evidence of its source contract; local tests cannot establish that GitHub actually signed or published an artifact. Human criteria require the named maintainer's confirmation.
Published observations
| Observation | Scope and evidence |
|---|---|
| Scorecard 8.3/10 | Public API report dated 2 October 2026, 05:20:04 UTC; commit 06a635e06d13ff95a1c04632f89383740ffa57b1 |
| Best Practices application | Passing 97%, Silver 76% after the 2 October evidence update; neither level awarded |
| Coverage and test policy | PR 625 merged at 06a635e; its source tree equals the verified candidate 2388cec |
| Reviewed integration | PR 608, approved by bit-mis, merged at 9783406; PR 625 later merged at 06a635e |
| Live protection | Active ruleset 24306812; privileged audit passed with exact snapshot parity and no bypass actors |
| Security analysis | CodeQL on merged master passed; upload success alone does not certify absence of security defects |
| Published Scorecard workflow | Master run succeeded with public results enabled |
The Scorecard API reports the commit and assessment date. Earlier scores of 3.1 and 7.7 refer to earlier public source and assessment dates. Historic review and test activity continue to affect the new score; a workflow edit cannot change past reviewed changesets.
Coverage and regression proof
Silver requires at least 80% statement coverage. Measure all talos Python
modules with the maintained acceptance suite, executable documentation and
examples in the current full-framework environment. Optional-framework skips
in the core-only lane are not proof of framework behavior.
.github/coverage-full.toml instruments subprocesses and retains the original
package as the report scope. tools/check_statement_coverage.py rejects
missing modules, duplicate or foreign checkout paths, inconsistent totals and
coverage below 80%, using statement counts rather than the combined line/branch
percentage. The documentation job in .github/workflows/ci.yml runs the check
and retains its JSON report. The existing required lint gate keeps its separate
core coverage floor and ratchet.
The pre-improvement full-framework measurement was 6,756 of 8,711 statements (77.56%), across 176 modules. The reviewed and merged 2.0.2 source measured 7,046 of 8,711 statements (80.89%) with 215 passing maintained tests and no skips, plus the complete documentation corpus and examples; its 104 existing excluded lines were unchanged. The dated verification receipt records local execution evidence. The complete coverage guard and all framework lanes also passed in hosted candidate CI. The post-merge master run also passed the framework matrix, executable corpus and complete coverage guard. Its retained original report measures 7,054 of 8,711 statements (80.98%) over all 176 modules; 215 maintained tests passed with no skips. This is distinct from the earlier local measurement. New regression cases exercise Pareto/diversity selection, causal scaling and the packaged Keras, TensorFlow and PyTorch SFD training and restoration paths. Use the selected source's executed report for its result; do not substitute a projected total or narrow the measured package.
The six-month fixed-bug ledger inventories the merged public source from 2 April through 2 October 2026. Added regression assertions cover 16 of 25 independently identified fixed-defect groups (64%). Nine uncredited groups remain in the denominator; feature additions, open changes and unrepaired defects are excluded. The ledger binds every credited assertion to immutable merged source and states the historical audit limits.
Release evidence
Release policy owns the signed-artifact contract and Making a release owns the authorized sequence. Signature verification must bind the artifact, repository, signer workflow, source commit and source ref. An authentic Sigstore bundle and attested SHA-256 checksum list belong with each new release's wheel and source distribution. Historical releases remain unsigned unless their actual evidence says otherwise.
A successful reviewed release execution is still needed for the signed-release criterion. PyPI enablement is a separate decision; the presence of organization credentials does not establish a trusted publisher or release approval.
Application review and remaining facts
Use the official passing and Silver criteria. Each answer must link to current public evidence or state a justified permitted exception. Keep unsupported answers Unknown. In particular:
- Name a primary developer who confirms secure-design and common-vulnerability knowledge; policies and generated prose cannot establish that expertise.
- Retain the maintainer's supplied vulnerability-history attestation and the bounded project advisory inventories; legacy dependency advisories remain a separate unresolved obligation.
- Name an independent backup maintainer and confirm their ability, credentials and legal authority to continue development and issue a fix within one week.
- Review substantive static diagnostics. An inherited-debt ratchet is not a claim that every warning is fixed or every style exception is rare and local.
- Resolve legacy dependency advisories individually without treating trusted model execution as proof that a dependency vulnerability is unexploitable.
- Link an actual signed release and verify its artifacts from a consumer environment.
- Refresh the fixed-bug ledger after later merges; its current 64% result applies only to the recorded six-month public-source inventory.
- Reassess input, certificate and credential validation after the reviewed maintenance changes are integrated; candidate tests alone do not establish the deployed state.
The security assurance case records trust boundaries; CONTRIBUTING records contribution and test policy; SECURITY.md records vulnerability handling; the roadmap covers the next year. Their publication establishes policy, not retrospective compliance.
The portal requires application data to be submitted under the Community Data License Agreement–Permissive Version 2.0. The authorized project representative must accept those terms before submission. After a level is attained, publish its achievement link on the repository front page or live project website within 48 hours, as the criteria require. The README links the live OpenSSF application and measured coverage publication; the maintainer explicitly lifted its prior freeze for this update. An undeployed documentation site does not establish achievement notice.
Annual review
Re-run the current and minimum framework lanes, executable documentation, full-package coverage, dependency audits, recovery and installed-wheel proof. Inspect live ruleset parity, reviewer access, backup authority and publisher configuration. Check public Scorecard and badge answers against the current commit; refresh expired exceptions and release evidence. Record the date and commit for each claim rather than carrying forward an old green status.