← All docs
This document maps Afunana's security controls to three widely used frameworks:
- OWASP Top 10 (2021) — application-security risk categories
- ISO/IEC 27001:2022 — Annex A information-security controls
- SOC 2 Type II — AICPA Trust Service Criteria
Read this first — what these mappings are, and are not. The tables below are documented control mappings: for each framework item, they state how Afunana's implemented controls address it. They are an engineering self-assessment to help a customer's security, audit, and GRC teams evaluate the platform and slot it into their own control environment. They are not a certification or an attestation. Afunana is mapped to these frameworks; it is not certified against them. Third-party certification and a SOC 2 Type II examination are in progress, not complete. Wherever this document says "addresses," "supports," or "mapped to," read it as an implementation claim to be verified against the customer's own deployment — never as independent assurance.
The underlying controls are described in full in Security Architecture. This document shows how those controls line up with each framework, so the same control inventory is written once and referenced by all three mappings.
The compliance API surface
Afunana exposes an admin-only compliance API that turns these controls into operations an auditor or administrator can actually run:
| Capability |
What it does |
| Audit query |
Filter recent audit events by type, actor, and severity. |
| Audit export |
Export the audit log (JSON or CSV) over a chosen window, for external review or archival. The export action is itself audited. |
| Integrity verification |
Run an on-demand integrity check of the audit hash chain and get back whether the chain is intact and, if not, where it first breaks. |
| Session revocation |
Immediately invalidate all sessions for one user, or every session system-wide. |
| Data export / portability |
Export a collection's documentation, metadata, and chat history as a single JSON package (supports ISO/IEC 27001 A.8.10 portability/deletion workflows). |
| Compliance status dashboard |
A status endpoint summarizes which controls are enabled (audit logging, SIEM forwarding, hash chain, SSO, session policy, retention). |
Caveat on the status dashboard. The status endpoint reports several transport/encryption flags (for example TLS-enabled and DB-connection-encrypted) as asserted configuration values, not live probes — they reflect the intended deployment posture, not a real-time measurement of the customer's actual network path. Treat the dashboard as a configuration summary for operators, not as proof of a customer's transport security. Independent verification of TLS and at-rest encryption must come from the customer's own infrastructure evidence (proxy/TLS configuration and, for external databases, their TDE configuration).
OWASP Top 10 (2021)
| Category |
How Afunana addresses it |
Cadence |
| A01 Broken Access Control |
JWT authentication + RBAC (admin, qa, user, viewer) + per-collection ACLs. Backend decorators enforce role on every endpoint (frontend guards are convenience only); unauthorized requests return 403; per-token and per-user revocation invalidate sessions immediately. |
Every request |
| A02 Cryptographic Failures |
TLS in transit (Caddy auto-HTTPS + HSTS; DB Encrypt=yes; OIDC/SIEM/LLM over TLS); SQL Server TDE (AES-256) at rest, auto in bundled-DB mode / customer-configured for external DB; bcrypt password hashes; HS256 JWT with a mandatory ≥256-bit key validated at startup; layered secret resolution, secrets never logged. |
Continuous (TLS); startup (key validation) |
| A03 Injection |
Parameterized SQL via pyodbc throughout — no string-built queries. User-supplied identifiers validated; API inputs validated by Pydantic models. The PL/SQL quality checks additionally flag dynamic-SQL injection patterns in analyzed code. |
Every query |
| A04 Insecure Design |
Defense-in-depth: independent layers for authentication, authorization, transport, input, output, rate limiting, CSRF, audit, secrets, and container hardening. Fail-loud on missing bootstrap secrets. No single control failure compromises the system. |
Architecture review |
| A05 Security Misconfiguration |
Secure defaults seeded on first start; security headers (CSP, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy) applied at the proxy; data services internal-only; no build tools in the production image; non-root appuser. |
Every response |
| A06 Vulnerable & Outdated Components |
Every deploy runs pip-audit (Python), npm audit (JS), and Bandit (Python SAST); base image receives vendor security updates. |
Every deploy |
| A07 Identification & Authentication Failures |
Persisted account lockout (5 attempts / 5-min window → 15-min lockout, survives restart); password complexity; idle + absolute session limits; per-token revocation on logout; OIDC/SSO with MFA delegated to the identity provider. |
Every auth event |
| A08 Software & Data Integrity Failures |
SHA-256 audit hash chain with a database immutability trigger and hourly/daily verification; software distributed as versioned, authenticated private images pulled over TLS. |
Hourly + daily |
| A09 Security Logging & Monitoring Failures |
Seven audit categories with full attribution; tamper-evident hash chain; real-time SIEM forwarding (syslog CEF/JSON over TLS, or HTTPS webhook); automated integrity scheduler. |
Continuous |
| A10 Server-Side Request Forgery |
No general-purpose URL-fetching capability is exposed to users. The one place a URL is fetched — OIDC discovery/JWKS — is SSRF-guarded (HTTPS-only, must resolve to a public IP; private/loopback/link-local/reserved addresses refused). Other outbound calls go only to administrator-configured LLM, SIEM, and source-system (IBM i / Oracle) endpoints — never user-supplied URLs. |
By design + every discovery fetch |
ISO/IEC 27001:2022 — Annex A Control Mapping
| Control |
Name |
How Afunana addresses it |
| A.5.1 |
Policies for information security |
Security policy expressed as auditable configuration settings — password complexity, session timeouts, lockout thresholds, audit categories, retention. |
| A.5.15 |
Access control |
JWT authentication with RBAC and per-collection ACLs; backend decorator checks are authoritative, frontend guards convenience. |
| A.5.17 |
Authentication information |
Bcrypt password hashing; enforced complexity; hashed, expiring reset tokens; federated identity via OIDC/SSO. |
| A.5.24 |
Information security incident management |
Events written to a tamper-evident, INSERT-only audit log with a SHA-256 hash chain; real-time SIEM forwarding; automated integrity verification; on-demand session revocation for containment. |
| A.5.25 |
Assessment of security events |
Seven-category event model (auth, authz, data, chat, admin, system, integrity) with severities and a queryable/exportable log API. |
| A.8.1 |
User endpoint devices |
Idle session timeout, absolute session lifetime, cross-tab logout propagation. |
| A.8.2 |
Privileged access rights |
admin separated from qa/user/viewer; admin-only endpoints for user management, configuration, and operations; SSO auto-provisioning can never assign admin. |
| A.8.3 |
Information access restriction |
Per-collection ACLs; users see only assigned collections; the API enforces the collection boundary on data, chat, and export. |
| A.8.4 |
Access to source code |
Analyzed source is viewable only by authorized users for their assigned collections. |
| A.8.5 |
Secure authentication |
Persisted account lockout, idle + absolute timeouts, per-token and per-user revocation, OIDC state/nonce protection. |
| A.8.6 |
Capacity management |
Setup-time resource checks (RAM, disk, CPU) that warn but never block, by design. |
| A.8.9 |
Configuration management |
Centralized configuration; layered secret resolution — an external secret vault (CyberArk CCP or HashiCorp Vault) first when configured, then a writable on-box admin-UI layer, then mounted container secrets, then the database, with the environment as a final fallback; bootstrap keys use a mounted secret then environment only, never the database; configurable per-check quality severities; all changes audited. |
| A.8.10 |
Information deletion |
Configurable audit retention (default 365 days) with automated daily purge; expired-token cleanup; per-collection data export for portability/deletion workflows. |
| A.8.15 |
Logging |
Tamper-evident SHA-256 hash chain with a DB immutability trigger; seven categories; hourly + daily integrity verification with checkpoint export. |
| A.8.16 |
Monitoring activities |
Integrity scheduler; SIEM forwarding of all events in real time; critical alert on any hash-chain failure. |
| A.8.20 |
Networks security |
Reverse proxy with TLS; data services internal-only; container network isolation. |
| A.8.23 |
Web filtering / outbound control |
SSRF guard on OIDC discovery; outbound traffic limited to administrator-configured LLM, SIEM, and source-system endpoints. |
| A.8.24 |
Use of cryptography |
TLS in transit; SQL Server TDE (AES-256) at rest (auto in bundled mode; customer-configured for external DB); bcrypt; HS256 JWT signing; SHA-256 audit hash chain; OIDC JWKS signature validation. |
| A.8.25 |
Secure development lifecycle |
pip-audit, npm audit, and Bandit on every deploy; parameterized SQL; input validation. |
| A.8.28 |
Secure coding |
Bandit SAST on every deploy; parameterized SQL (no ORM string-building); input-validation and CSP headers. |
Notes. MFA is delegated to the identity provider via OIDC/SSO. Resource checks warn but never block, by design. Audit retention defaults to 365 days and is configurable for organizations with longer requirements. At-rest encryption is automatic only in bundled-DB deployments; external-DB customers configure TDE on their own instance.
SOC 2 Type II — Trust Service Criteria
The mappings below indicate how Afunana's controls support each criterion. A SOC 2 Type II report is issued by an independent auditor over an observation period; that examination is on the roadmap and has not been performed. These tables are inputs to such a process, not a substitute for it.
CC1–CC5 — Control environment, communication, risk, monitoring, control activities
| Criteria |
Afunana control |
| CC1.1–1.5 Control environment |
Defense-in-depth architecture; RBAC with clear privilege separation; automated vulnerability scanning; every action tied to an authenticated identity in a tamper-evident audit trail. |
| CC2.1–2.3 Communication & information |
Analysis results and build history stored as structured data; audit log surfaced in the admin UI and exportable; SIEM forwarding and checkpoint exports for external review. |
| CC3.1–3.4 Risk assessment |
Auditable configuration; automated code-quality and dependency/vulnerability checks; account lockout and tamper detection; deploy pipeline records version, timestamp, and scan results. |
| CC4.1–4.2 Monitoring |
Integrity scheduler runs hourly (recent) and daily (full) hash-chain verification; failures raise events that forward to the SIEM. |
| CC5.1–5.3 Control activities |
Layered controls (auth, authz, rate limiting, CSRF, headers, audit); container isolation and non-root execution; audited layered secret/configuration resolution. |
CC6 — Logical and physical access controls
| Criteria |
Afunana control |
| CC6.1 Logical access security |
JWT (HS256, ≥256-bit key), RBAC, per-collection ACLs. |
| CC6.2 Register / authorize users |
Admin-gated user creation; OIDC auto-provisioning with a non-admin default role and domain allow-list. |
| CC6.3 Restrict access to assets |
Per-token and per-user session revocation; data services not externally exposed; container network isolation. |
| CC6.5 Data disposal |
Per-collection data export and retention-driven purge support deletion/portability workflows. |
| CC6.6 Manage credentials |
Bcrypt hashing; layered secret resolution — an external secret vault (CyberArk CCP or HashiCorp Vault) first when configured, then on-box and mounted secrets, then the database, with bootstrap keys from a mounted secret or environment only; secrets never logged; client secret masked in the admin API. |
| CC6.7 Restrict transmission |
TLS for all external communication; HSTS; internal services on the container network only. |
| CC6.8 Protect against threats |
Rate limiting, CSRF origin validation, CSP headers, persisted account lockout, SSRF-guarded discovery, input validation. |
CC7–CC9 — Operations, change management, risk mitigation
| Criteria |
Afunana control |
| CC7.1–7.5 System operations |
Seven audit categories; integrity scheduler; hash-chain verification; checkpoint exports; lockout, revocation, and SIEM alerting for detection and response. |
| CC8.1–8.3 Change management |
Version-controlled codebase; deploy pipeline with automated scanning; build history; production updates via authenticated private-image pull — no direct production shell access to change the app. |
| CC9.1–9.2 Risk mitigation |
Multi-provider LLM router with fallback chains (no single-vendor dependency); local Ollama option for fully air-gapped operation; secrets via Docker secrets; no vendor lock-in. |
Availability & Confidentiality
| Criteria |
Afunana control |
| A1.1–1.2 Availability |
Container health checks with automatic restart; configuration in the DB enables rapid redeployment; checkpoint exports preserve audit state; daily backups in bundled mode. |
| C1.1–1.2 Confidentiality |
Per-collection data isolation; TLS in transit; TDE at rest (bundled mode; customer-configured for external DB); Docker secrets for sensitive config; configurable retention with automated purge; on-premise operation with zero vendor access. |
Continuous monitoring summary
| Check |
Frequency |
Scope |
| Hash-chain integrity |
Hourly |
Recent audit records |
| Full hash-chain verification |
Daily |
All audit records |
| Checkpoint export |
Daily |
Audit-state snapshot |
| Log purge |
Daily |
Records beyond retention (default 365 days; forwarded-only when SIEM is enabled) |
| Token cleanup |
Daily |
Expired session-revocation entries |
| Vulnerability scan |
Every deploy |
Python deps, JS deps, Python source |
