External Mapping Model

This section defines how awoss should relate to external standards, frameworks, guidance, vulnerability scoring systems, and threat taxonomies. It is informative in this working draft.

awoss should map to and complement existing work. It should not claim equivalence to an external source unless a future detailed crosswalk, release process, and claim rule explicitly support that statement.

10.1 Mapping Record Fields

Each detailed mapping record SHOULD include:

• awoss family or candidate requirement
• external source name
• source owner or publisher
• source version, status, publication date, or maturity state where available
• source URL or stable reference
• access date
• source signal or requirement summary
• mapping posture
• awoss layer
• primary responsibility owner
• evidence angle
• claim limit

Mapping records should be traceable to primary sources when current maturity, version, status, certification posture, or regulatory meaning matters.

10.2 Mapping Postures

awoss uses the following mapping postures.

Informs:

• the source shaped design thinking or vocabulary
• no row-by-row control relationship is claimed
• acceptable phrasing: " awoss is informed by this source"

Candidate control:

• the source contains a requirement, control objective, threat, mitigation, or assurance pattern that can shape a candidate awoss requirement
• acceptable phrasing: "this source maps to a candidate awoss control"

Supports evidence for:

• the source helps define useful proof artifacts, evidence state, review cadence, or governance records
• acceptable phrasing: "this artifact supports evidence for selected candidate controls"

Advisory input:

• the source is useful for threat framing, design review, prioritization, or scenario testing, but should not be treated as a direct requirement
• acceptable phrasing: "this source informs review scenarios"

Out of scope:

• the source topic does not materially apply to the scoped awoss boundary, or belongs to a separate legal, sectoral, model-training, enterprise-security, or governance domain
• acceptable phrasing: "not mapped for this scoped system"

Implementation-specific mapping:

• a concrete system implements, produces evidence for, or inherits selected controls
• acceptable phrasing: "implements selected controls for the named scoped system"

10.3 Initial Mapping Sources

The first working-draft mapping baseline distinguishes mapped sources from context-only sources.

Mapped sources currently represented in Appendix C rows:

• OWASP Artificial Intelligence Security Verification Standard
• OWASP Agentic Skills Top 10
• OWASP AI Vulnerability Scoring System
• Cloud Security Alliance Autonomous Action Runtime Management
• Cloud Security Alliance AI Controls Matrix
• Cloud Security Alliance MAESTRO
• NIST AI Risk Management Framework
• NIST AI 600-1
• ISO/IEC 42001
• ISO/IEC 23894
• AIUC-1
• Five Eyes guidance on careful adoption of agentic AI services
• MITRE ATLAS
• EU AI Act

Context-only sources currently used for orientation, analogy, or source discovery until specific family-level mapping rows are added:

• CryptoCurrency Security Standard
• OWASP Agentic AI Threats and Mitigations
• NIST AI Agent Standards Initiative

These lists are not claims that every source is equally normative, equally current, or fully covered. Detailed mapping rows must preserve source status and claim limits.

10.4 Mapping Use Rules

Mapping rows SHOULD be used to:

• explain how awoss candidate controls relate to existing work
• identify external source signals that shaped candidate requirements
• identify evidence artifacts that could support selected controls
• preserve claim limits for legal, certification, management-system, or source-specific statements
• find gaps where awoss should defer to an external standard rather than duplicate it

Mapping rows MUST NOT be used to claim:

• full external-framework coverage
• legal compliance
• certification under an external program
• endorsement by an external standards body
• equivalence between awoss and any mapped source
• complete security effectiveness for a scoped system

10.5 Mapping Maintenance

Mappings SHOULD be rechecked when:

• an external source changes maturity, version, release status, or claim posture
• an awoss control family changes materially
• a new release profile is proposed
• a public claim depends on the mapping
• a legal, regulatory, or certification statement could be inferred from the mapping

Access dates should remain visible in mapping notes and source registers. Where a source is paywalled, high-level, or not fully public, the mapping must state that limitation.