view release on metacpan or  search on metacpan

doc/update-and-release.md  view on Meta::CPAN

bash -ic "scorecard --repo=github.com/manif3station/developer-dashboard"
```

Treat the result as a real gate, not a passive report:

1. record every failing or unknown check
2. turn those checks into an explicit task list
3. fix repository-side causes with TDD and verification
4. apply GitHub-side settings changes when the check depends on remote state
5. push the fixes
6. rerun Scorecard
7. repeat until every actionable check reaches `10 / 10`

Do not claim the repository is complete while Scorecard still shows a
repository-fixable failure. If one check cannot become `10 / 10` because of
history, platform policy, or contributor makeup, document that blocker with
evidence instead of pretending the gate passed.

Hard implementation rules under this gate:

- do not keep GitHub Actions `write` permissions at the workflow top level
- move required `write` permissions down to the job that actually needs them
- keep action refs pinned by full SHA
- keep Docker `FROM` lines pinned by digest when Scorecard scans them
- keep a detectable fuzzing signal in the repo; this tree uses `fast-check` plus `.clusterfuzzlite/Dockerfile`, and any workflow that drives `dashboard encode` / `dashboard decode` must install the Perl runtime first
- keep `Signed-Releases` backed by a real GitHub release that contains the release tarball and its detached signature asset
- keep workflow coverage gates matching the `Devel::Cover` `Total` summary line by regex instead of fixed-width spacing, because host upgrades can change padding without changing the real `100.0 / 100.0 / 100.0` outcome

For this repository, the signed GitHub release path is tag-driven. Push a
version tag in the form `vX.XX` after the local gates are green when the
repository needs a real GitHub release object for Scorecard. The workflow at
`.github/workflows/release-github.yml` then builds the tarball, writes a
checksum, generates a detached signature, and creates or updates the GitHub
release for that tag. That workflow must also install `Devel::Cover` before
it runs the numeric `cover` gate, or the release path will die before the
tarball, checksum, and signature assets are published.

A tag push runs that workflow **as frozen at the tag**, so a fix landed on
`master` afterwards does nothing for a tag that already exists. Both `v4.23`
and `v4.24` were lost that way: each tag carries the pre-DD-449 node20 pin for
`shogo82148/actions-setup-perl`, the runner now forces node24, and re-running
the failed run replays the same frozen file. For that case the workflow takes
an optional `tag` input on `workflow_dispatch`: dispatch it from `master` with
`tag=vX.XX` and it publishes that existing tag under the current definition,
while still checking out the tag's own tree so the artifact comes from the
tagged source rather than from `master`. The input is validated against the
`vX.XX` shape before anything is created, so a dispatch cannot publish a
branch as a release. Leave the input empty and an ordinary tag push behaves
exactly as it always has.

Recovering a tag this way still runs the full suite and the coverage gate
against the tagged tree, so a tag whose code cannot pass those gates stays
unpublishable by design — that is the second, separate reason `v4.24` cannot
be recovered, and it is not something the dispatch path is meant to bypass.

The GitHub-hosted CPAN upload workflow is deliberately manual-only. Do not
wire tag pushes to automatic PAUSE uploads here; ordinary `vX.XX` tags are for
the signed GitHub release path, while CPAN publication stays an explicit
`workflow_dispatch`, local `dashboard pause-release`, or local `dzil release`
operator action. The repository configures `Dist::Zilla::Plugin::UploadToCPAN`
as the real releaser for `dzil release`. Configure credentials only in
`~/.dzil/config.ini` or `~/.pause`, never in tracked repository files. Run
`dzil release` only after all release gates pass and an operator explicitly
intends to upload to PAUSE.

## OWASP Gate

The repository also treats OWASP as a hard release gate.

This is not limited to a baseline ASVS spot check anymore. Before build,
release, or security-sensitive closeout, complete the full OWASP ASVS 5.0.0
applicability review across:

- V1 Architecture, Design and Threat Modeling
- V2 Authentication
- V3 Session Management
- V4 Access Control
- V5 Validation, Sanitization and Encoding
- V6 Stored Cryptography
- V7 Error Handling and Logging
- V8 Data Protection
- V9 Communication
- V10 Malicious Code
- V11 Business Logic
- V12 Files and Resources
- V13 API and Web Service
- V14 Configuration

Treat ASVS Level 2 rigor as the default floor for this repository, and require
Level 3 review when the change touches higher-trust boundaries such as auth,
sessions, cryptographic handling, release signing, or externally callable API
routes.

Also map the change against the OWASP Top 10 2021 categories, with explicit
attention to:

- `A01` Broken Access Control
- `A02` Cryptographic Failures
- `A03` Injection
- `A04` Insecure Design
- `A05` Security Misconfiguration
- `A06` Vulnerable and Outdated Components
- `A07` Identification and Authentication Failures
- `A08` Software and Data Integrity Failures
- `A09` Security Logging and Monitoring Failures
- `A10` Server-Side Request Forgery

Use the commands in `SECURITY_CHECKS.md` as the local repo-side evidence set.
Do not claim the security review is complete merely because the code “looks
fine”; the grep-based audit, focused tests, and release/integration gates are
part of the proof.

The shipped OWASP compliance SOW is also part of that proof. Keep the
chapter-by-chapter evidence record current and do not upgrade the public
wording from `OWASP-aligned` / `OWASP-gated` to blanket `OWASP compliant`
until the SOW closure criteria and the remaining governance gates are
actually closed.

## Local Update

## Next-Version Checklist