What the controls are mapped to
Each page answers the same question for a different vocabulary: which clauses the 13 controls in the active pack carry, how each result is established, what passing requires, and what stays uncovered. None of them summarises the standard itself. The standards bodies did that better and their documents are free.
The number beside each one is how many controls reference it. It is worth reading before the page: eleven controls behind a vocabulary and one control behind a vocabulary are not the same kind of claim.
A NIST SSDF assessment when you are a team of four
SSDF describes how software is produced, so its relationship to evidence from a running system is indirect. Which practices these controls provide evidence toward, why evidence toward a practice is not conformance, and what a team without a compliance function can honestly do with it.
What a CWE identifier on a finding does and does not tell you
CWE is a taxonomy of weakness types, not a standard you comply with. What a CWE identifier on a finding means, how it differs from a CVE, why nobody can be CWE certified, and the exact weaknesses these thirteen controls carry.
What an OWASP ASVS assessment can and cannot automate
ASVS is a verification standard, not a vulnerability list, and that difference decides what a tool can do with it. Which requirements are automatable at all, which need a person, the exact ASVS 5.0.0 clauses these thirteen controls carry, and what stays uncovered.
The Web Security Testing Guide describes a person testing, which decides what automates
WSTG is a testing methodology rather than a requirements list, written for somebody with a browser and time. Which of its twelve categories these thirteen controls execute, how each result is established, and the six categories nothing here touches.
The API Top 10 is mostly an authorisation list, and that decides what a tool can do
Seven of the ten entries are about authorisation or resource consumption rather than injectable patterns, which is why scanners do badly on this list. Which entries these thirteen controls carry, how each is settled, and what stays uncovered.
Mapped, with no page of its own
SLSA, on 1 control. A page needs enough behind it to say something specific, and one control is a row in the catalogue rather than a reference page.
In the SLSA case this is about what the pack tests rather than about effort. SLSA is a build track: it describes the provenance and hardening of the system that produced an artifact. This pack examines the application and its deployment, so mapping more controls to it would be claiming coverage of something nothing here looks at. The one mapping it carries sits on the dependency control, where the resolved graph is evidence about build inputs.
A mapping is not a certification
A mapping means a StackAttest control references a clause in that vocabulary. It is not a claim that StackAttest, or any product it validates, is certified, accredited, approved or reviewed by OWASP, NIST, MITRE or anyone else. None of those organisations endorses this work, and most of them run no certification scheme at all.
Evidence toward a practice is not conformance with it. A control that maps to an ASVS clause does not award an ASVS level, and executing one test inside a WSTG category does not cover that category.