Add AISVS 1.0 mappings

[ottosulin]

Hi!

Attached files have two alternative proposals of adding AISVS mappings to OpenCRE. This took longer than expected and for the same reason there are now several attachments.

At this point I have been looking at these too long and would appreciate maintainers second pair of eyes having a look at the proposals.

Attachment contents

File	Purpose
AISVS-1.0-OpenCRE-mapping-v2-CONSOLIDATED.xls	The actual submission. CRE mapping template with AISVS columns appended.
AISVS-1.0-OpenCRE-mapping-v2-CONSOLIDATED.csv	Same data as CSV, for diffing.
new_cre_proposals_v2.csv	The 6 proposed new CREs: driving requirements, chapters, suggested parent, full text.
MAPPING-READABLE-v2.md	Full mapping as per-chapter tables, for review without a spreadsheet.
AISVS-1.0-OpenCRE-mapping-v2-FORCED.xls	Fallback variant with zero new CREs.
AISVS-1.0-OpenCRE-mapping-v2-FORCED.csv	Same as CSV again.
FORCED-MAPPING-RATIONALE-v2.md	What forcing the remaining gaps onto existing CREs costs.

Conventions

Modelled after ASVS entries in OpenCRE:

• OWASP AISVS|name has the full requirement sentence (same way ASVS uses section).
• OWASP AISVS|id has the native requirement ID, for example 1.1.1.
• OWASP AISVS|hyperlink is a section-level deep link into the frozen chapter file. AISVS has no per-requirement anchors, same limitation as ASVS. All anchors were verified against GitHub's rendered HTML.
• OWASP AISVS|description has the AISVS level and our confidence rating, plus a forced: <rating> suffix on rows where the mapping was a substitute. Drop the column if unwanted.
• New CRE names follow the observed house style: sentence-case noun phrases, two to five words, domain-qualified, vendor-neutral, suggested as leaves under 663-200 Technical AI security controls.

The 6 proposed new CREs

Proposed CRE	Drives	Chapter
Agent action reversibility gating	9.2.3, 9.2.4, 9.2.10	C9
Agent action approval integrity	9.2.2, 9.2.8	C9
Agent tool capability declaration and enforcement	9.3.3, 9.3.4	C9
Agent action chain non-repudiation	9.4.2	C9
Token passthrough prohibition in AI tool servers	10.2.7	C10
AI tool definition change detection	10.4.8	C10

All six are in the agentic-chapters (C9/C10) that postdate most standards currently in OpenCRE. Forcing any of these into an existing CRE creates just noise for users of CREs.

FORCED-MAPPING-RATIONALE-v2.md walks through each, but the short version is: least privilege does not express reversibility, privacy consent does not express canonicalised action parameters, an SDLC audit trail does not express cryptographic binding of a runtime chain, and OAuth revocation does not express confused-deputy prevention.

Deferred proposals

Following AISVS controls I decided to now intentionally force-fit rather than propose new CREs. Maintainer input is welcome on the deferred four.

Withdrawn proposal	Now maps to	Awkwardness
AI compute environment attestation (4.1.3, 4.2.1, 4.2.3)	347-352, 171-222, 307-507	strained
AI compute tenant isolation (5.3.2, 8.1.1)	515-021, 273-600	wrong / strained
AI-generated content provenance marking (7.4.4)	810-884	acceptable
AI input drift detection (12.3.1, 12.3.4)	058-083, 418-853	acceptable / strained

One of these (5.3.2 → 515-021 network isolation) is still a wrong forced fit: network isolation cannot stop GPU-memory side channels. I am flagging it here because withdrawing the proposal is a scoping decision, not a claim that the gap disappears. If a later CREs adds compute-isolation coverage, that mapping could be added.

new_cre_proposals_v2.csv
forced_mapping_v2.csv
MAPPING-READABLE-v2.md
FORCED-MAPPING-RATIONALE-v2.md
AISVS-1.0-OpenCRE-mapping-v2-FORCED.xls
AISVS-1.0-OpenCRE-mapping-v2-FORCED.csv
AISVS-1.0-OpenCRE-mapping-v2-CONSOLIDATED.xls
AISVS-1.0-OpenCRE-mapping-v2-CONSOLIDATED.csv