ASVS 5.0.0 re-map: all three files, schema v2, translated from the ASVS project's own mapping

[emmanuelgjr]

Item 3 — #22, green-lit with widened scope. Do not merge yet. Five commits, one per logical unit.

The official mapping exists, so this proceeded

The ASVS project publishes 5.0/mappings/mapping_v4.0.3_to_v5.0.0.yml — 278 entries with verbs (MOVED TO, MODIFIED, SPLIT TO, MERGED TO, COVERED BY, DELETED, …). Every identifier change here comes from that file; requirement text comes from the v5.0.0 release. None of it is our judgment.

Two corrections to what I reported earlier

1. All three files were legacy tier, not just Agentic_ASVS.md — 0 of 151 ASVS rows carried a relationship and every one was unreviewed. My earlier claim came from grepping for the word "confidence", which appears in prose.
2. ASVS had the Swapped control_id / control_name: 576 mapping rows hold prose where an identifier belongs #35 swapped-id bug too, and it had to be fixed first (commit 1). ASVS wasn't among the ten frameworks Fix #35: parse control identifiers by framework grammar, not by column position #110 covered, so DSGAI_ASVS.md rows like | V8.1.1 — … | V8 Data Protection | still put the chapter in control_id: 67 of 151 rows had no requirement id to translate.

Result

	ids	rows
Translated to a 5.0.0 identifier	39	127
Retained at 4.0.3 — 5.0.0 deleted them	11	24

Per file: LLM 36 translated / 4 retained · DSGAI 51 / 16 · Agentic 40 / 4. docs/ASVS_4_TO_5_TRANSLATION.md lists every old → new identifier with its official disposition, row count and affected entries.

You asked for reports/asvs-4-to-5-translation.md; the generator writes there too, but reports/ is gitignored, so the committed copy is in docs/. Say if you'd rather amend the ignore rule.

A trap, and a bug I shipped into CI and then fixed

The trap: several deleted 4.0.3 numbers exist in 5.0.0 as an entirely different requirement (V1.1.2 among them). Renumbering them silently, or titling them from 5.0.0 data, would assert a mapping nobody made. Retained rows therefore keep their 4.0.3 id, carry a DRAFT marker with the official disposition, get source_status in the registry, and read ASVS 4.0.3 in their Framework ver. column.

The bug: my first migration matched rows rather than tables, so a maturity-roadmap table that merely lists ids was treated as a mapping table — it gained v2 columns it shouldn't have, and one cell had its text overwritten. Markdown lint caught it on the column count, which is the check doing its job. The migration now parses whole tables and only treats one as a mapping table if a column holds a single requirement id on at least two rows. Roadmap tables get their ids translated but no v2 columns, so no file cites 4.0.3 numbers beside 5.0.0 ones.

What is DRAFT, and why

Every migrated row's relationship, rationale type and confidence read DRAFT. The identifier translation is mechanical; whether a 5.0.0 requirement still addresses the GenAI risk the row claims is expert judgment (C4). Reviewer: ASVS leadership, per STRAT-04. Column layout matches the ISO 27001 schema-v2 template.

Other effects

• Registry rebuilt against 5.0.0: 82 → 78 items, titles from the release.
• framework-sources: mapped_version 4.0.3 → 5.0.0, so freshness reads 4 current · 1 behind (was 3 · 2).
• Warnings 88 → 87.

Verification

• Baseline before: 0 errors, 88 warnings, 327 passed; 85/85 tests. After: 0 errors, 87 warnings, 327 passed; 85/85.
• All six CI checks green, including both markdown lint jobs.
• Table column counts verified consistent across all three files; no prose line I added exceeds 120 columns.
• The prerequisite registry migration was re-run across all eleven grammar frameworks: 0 added, 0 unresolved for the other ten, confirming it touched only ASVS.

🤖 Generated with Claude Code