OWASP ASVS and Top 10 Mapping

Purpose

AIC uses OWASP ASVS as a structured application security verification reference and OWASP Top 10 as an awareness baseline for common web risks.

How AIC Uses OWASP

AIC does not blindly copy every OWASP control into every project. Instead, the project security lead and technical lead agree the applicable verification scope based on:

• data sensitivity

• user population

• exposure to the internet

• classification

• customer security requirements

• regulatory obligations

• integration complexity

• authentication and authorization model

Mapping Table

OWASP risk area	AIC engineering control
Broken access control	RBAC/ABAC design, authorization tests, deny by default
Cryptographic failures	approved crypto, TLS, secure key storage, no custom crypto
Injection	parameterised queries, validation, safe serializers, no string SQL construction
Insecure design	threat modelling, ADRs, abuse cases, design reviews
Security misconfiguration	hardened defaults, environment controls, config validation
Vulnerable components	dependency scanning, approved packages, SBOM
Authentication failures	standard identity provider integration, MFA where required, token validation
Software and data integrity failures	signed packages, CI controls, provenance, branch protection
Logging and monitoring failures	structured security logs, alerts, incident evidence
SSRF	allowlists, outbound controls, URL validation, metadata endpoint protection

ASVS Evidence Model

For high-assurance APIs, maintain a verification matrix:

Requirement	Applicable	Control	Evidence	Owner	Status
Access control	Yes	Policy-based auth	Test report	Tech Lead	Pass
Input validation	Yes	Validators	Test results	Developer	Pass

Security Test Requirements

At minimum, security-sensitive APIs need tests for:

• unauthenticated access

• authenticated but unauthorized access

• object-level authorization

• invalid input

• injection-like payloads where relevant

• error response leakage

• rate limit or abuse controls where relevant