STABLE PROFILE / 1.0.0
Common foundation for security auditability
Reference requirements, methods and evidence. Specification stability does not mean that a particular system has passed an audit.
English reading view of the same profile and control identifiers. The canonical versioned artifact is preserved; this translation does not create new requirements.
Subject, purpose and assessment boundaries
- Requirement
- Every assessment clearly defines the object, its capabilities, use, time scope and exclusions.
- Applicability
- Always.
- Method
- Compare the plan with available functions and select a representative sample. Justify each omitted area.
- Evidence
- Assessment plan, public snapshot identifier, list of capabilities and exclusions.
- Pass criterion
- The scope is unambiguous and no declared capability lacks an applicability decision.
- Limitations
- A scope description is not a security test. A public snapshot may not allow independent verification of an internal deployment.
- NIST AI Risk Management Framework 1.0, NIST AI 100-1, January 2023 — MAP 1.1, MAP 2.1, MAP 2.2. Relationship: contextual support.
Identity and access to protected functions
- Requirement
- Protected functions require documented user authentication; alternative login and recovery paths do not bypass required factors.
- Applicability
- When the system contains accounts or restricted functions.
- Method
- In an agreed environment, assess valid, invalid and recovery login paths, including required MFA.
- Evidence
- Sanitized test record with expected and actual states; no passwords, tokens or MFA secrets.
- Pass criterion
- All included paths follow the documented authentication policy.
- Limitations
- A successful login alone establishes neither secure password storage nor resilience against every attack.
- OWASP Application Security Verification Standard 5.0.0 — 6.3.3, 6.3.4, 6.4.3. Relationship: selected partial mapping.
Session lifetime and termination
- Requirement
- Sessions are validated on the trusted side and cannot be reused after termination.
- Applicability
- When the system uses user sessions.
- Method
- Check session change on login, termination and repetition of a protected request after logout.
- Evidence
- Scenario results with anonymized identifiers; a validity record without the token value.
- Pass criterion
- A terminated session has no further access, and limits match the declared policy.
- Limitations
- An unauthenticated public test does not cover every session management mechanism.
- OWASP Application Security Verification Standard 5.0.0 — 7.2.1, 7.2.4, 7.4.1. Relationship: selected partial mapping.
Authorization of functions, objects and fields
- Requirement
- A trusted application layer enforces permissions for the operation, data and exposed fields.
- Applicability
- Always; even a public system has a disclosure boundary.
- Method
- Build a role and operation matrix. Test both an allowed and a denied operation in each selected class.
- Evidence
- Sanitized matrix and records of negative and positive tests.
- Pass criterion
- The sample matches the matrix and client manipulation does not change authorization.
- Limitations
- An HTTP 401 response or a hidden button alone does not cover all authorization.
- OWASP Application Security Verification Standard 5.0.0 — 8.2.1, 8.2.2, 8.2.3, 8.3.1. Relationship: selected partial mapping.
Minimization and protection of disclosed data
- Requirement
- Output contains only data permitted for the relevant audience; secrets and internal operational details remain separate.
- Applicability
- Always.
- Method
- Review the field allowlist and test negative samples containing sensitive values, including error responses.
- Evidence
- Public schema, redaction test results and description of disclosure boundaries.
- Pass criterion
- Unknown and prohibited fields do not reach public output.
- Limitations
- Redaction may reduce verifiability. Missing evidence must be acknowledged, not replaced with a claim of success.
- OWASP Application Security Verification Standard 5.0.0 — 14.1.1, 14.1.2, 14.2.6. Relationship: selected partial mapping.
Input and contract validation
- Requirement
- Types, sizes and logical input boundaries are validated on the trusted side.
- Applicability
- Interfaces accepting data.
- Method
- Submit permitted, missing, extra and boundary values within an approved test sample.
- Evidence
- Versioned contract and boundary test results.
- Pass criterion
- The valid sample is processed and the invalid sample rejected without a side effect.
- Limitations
- Valid syntax establishes neither input truth nor safe textual meaning.
- OWASP Application Security Verification Standard 5.0.0 — 2.1.1, 2.2.1, 2.2.2. Relationship: selected partial mapping.
Operation order, limits and repetition
- Requirement
- The process follows mandatory gates and limits; a repeated request does not cause an unintended second effect.
- Applicability
- When the system performs multi-stage or cost-incurring operations.
- Method
- In a safe environment, assess skipped steps, concurrency, repetition and limit exceedance.
- Evidence
- Record of state before and after the attempt, idempotency and the applied limit, without sensitive values.
- Pass criterion
- Gates cannot be skipped and the effect matches the declared repetition policy.
- Limitations
- This is an AI CORE operationalization; the ASVS reference alone does not prescribe a particular idempotency mechanism.
- OWASP Application Security Verification Standard 5.0.0 — 2.3.1, 2.3.2, 2.3.3, 2.3.4. Relationship: selected partial mapping.
Evidence provenance and linkage
- Requirement
- Evidence has an identity, provenance, acquisition time and links to a control and subject; a derived output identifies its supporting material.
- Applicability
- Whenever a control result is presented.
- Method
- Select a sample of results and trace the chain from finding to observation and available artifact.
- Evidence
- Evidence manifest, originator type and links to sanitized artifacts.
- Pass criterion
- Links are traceable and do not silently substitute the supporting material or subject.
- Limitations
- A hash establishes byte equality, not the truth, independence or completeness of evidence.
- W3C PROV-O W3C Recommendation 30 April 2013 — 3.1 Starting Point Terms: Entity, Activity, Agent, wasGeneratedBy, used, wasAttributedTo. Relationship: conceptual inspiration.
- NIST OSCAL Assessment Results Model Concept documentation, page updated 2025-03-03, accessed 2026-11-15 — Assessment Results Organization: Observation, Finding, Back Matter. Relationship: conceptual inspiration.
Record retention and protection
- Requirement
- Relevant security events and results have defined retention, timestamps and protection against unauthorized modification.
- Applicability
- When audit or security records are created.
- Method
- Examine a selected record lifecycle, including access, correction and end of retention.
- Evidence
- Retention policy, sanitized timeline and evidence of protection.
- Pass criterion
- The record remains correlatable and changes or integrity limitations are explained.
- Limitations
- A public summary without internal evidence does not establish immutability of the entire store.
- OWASP Application Security Verification Standard 5.0.0 — 16.1.1, 16.2.1, 16.2.2, 16.2.5, 16.4.2. Relationship: selected partial mapping.
Safe failure
- Requirement
- An error does not bypass a protective gate, and a public response does not disclose sensitive internal information.
- Applicability
- Always.
- Method
- Simulate unavailable supporting material or a rejected dependency without interfering with live production.
- Evidence
- Expected and observed error states, with confirmation that the effect did not occur.
- Pass criterion
- The system follows its documented safe state and does not present an incomplete operation as successful.
- Limitations
- One simulation does not cover every possible failure.
- OWASP Application Security Verification Standard 5.0.0 — 16.5.1, 16.5.2, 16.5.3. Relationship: selected partial mapping.
Interpretation, independence and incompleteness
- Requirement
- A result distinguishes observation, operator statement and independent assessment, and identifies untested areas.
- Applicability
- Always.
- Method
- The assessor checks a sample of conclusions against the evidence and records their relationship to the operator.
- Evidence
- Sample scope, missing evidence list, assessor type and reasoning supporting the result.
- Pass criterion
- No conclusion exceeds available verification, and missing evidence is not labeled as success.
- Limitations
- Publishing a self-assessment does not create an independent audit.
- NIST AI Risk Management Framework 1.0, NIST AI 100-1, January 2023 — MEASURE 1.1, MEASURE 1.3, MEASURE 2.1. Relationship: contextual support.
Remediation and reassessment
- Requirement
- A finding has a correction and reassessment process; a newer result does not erase the earlier trail.
- Applicability
- When there are findings, changes or follow-up assessments.
- Method
- Select a remediated finding and compare the original scope with the new verification; do not present a planned fix as completed.
- Evidence
- Link to the previous record, remediation status and new evidence.
- Pass criterion
- A reader can distinguish an open finding, an implemented fix and a verified fix.
- Limitations
- This is not automatic confirmation of operational recovery.
- NIST AI Risk Management Framework 1.0, NIST AI 100-1, January 2023 — MANAGE 4.1, MANAGE 4.3. Relationship: contextual support.
AI CORE texts are its own operationalizations of selected requirements. Partial mapping is not a claim of full equivalence or endorsement by OWASP, NIST or W3C.
Profile license: CC BY-SA 4.0. Adaptations and methodological additions: AISYSTEMS s. r. o. Source attribution.