> For the complete documentation index, see [llms.txt](https://framework.aic.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://framework.aic.io/technical-guidelines-code-standards-and-tech-stack/secure-engineering-standards/owasp-asvs-and-top-10-mapping.md).

# 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