Security Compliance
Lens implements comprehensive security controls aligned with industry best practices and regulatory requirements. This page provides security teams, auditors, and partners with a transparent view of Lens security architecture, controls, and compliance posture.
Compliance Basis
Lens security compliance is based on the C2PA Security Considerations v2.2 and C2PA Harms Modelling v2.2 specifications. These documents provide the foundational framework for our security architecture, threat modeling, and harm mitigation strategies.
Primary References:
- C2PA Security Considerations v2.2 — Threat model, security features, and implementation guidance
- C2PA Harms Modelling v2.2 — Human rights considerations, misuse scenarios, and stakeholder guidance
All security controls, threat mitigations, and privacy protections documented on this page align with the guidance and recommendations provided in these C2PA specifications.
Compliance Summary
Security Architecture
Lens follows a defense-in-depth security model with multiple layers of protection.
Security Layers
1. Device Security
| Control | Implementation | Status |
|---|---|---|
| Secure Enclave Integration | Hardware-backed P-256 keys, non-extractable | Active |
| Keychain Services | iOS Keychain for credential storage | Active |
| App Sandboxing | iOS App Sandbox isolation | Active |
| Code Signing | Apple Developer certificate validation | Active |
| Runtime Protection | ASLR, stack canaries, code signing | Active |
2. Data Protection
| Control | Implementation | Status |
|---|---|---|
| Encryption at Rest | iOS Data Protection API (Class A) | Active |
| Encryption in Transit | TLS 1.3 for all network communications | Active |
| File System Encryption | iOS File Protection API | Active |
| Key Management | Secure Enclave hardware keys | Active |
| Certificate Pinning | Not implemented | Optional (planned) |
3. Network Security
| Control | Implementation | Status |
|---|---|---|
| TLS Configuration | TLS 1.3 minimum, perfect forward secrecy | Active |
| Certificate Validation | Full chain validation with OCSP | Active |
| Network Isolation | No direct internet access required | Active |
| Offline-First | Core functionality works offline | Active |
| Rate Limiting | Client-side (feedback); server-side depends on third-party APIs | Client-side only |
4. Application Security
| Control | Implementation | Status |
|---|---|---|
| Input Validation | All user inputs sanitized and validated | Active |
| Output Encoding | XSS prevention via output encoding & content sanitization | Active |
| SQL Injection Prevention | Parameterized queries (if applicable) | N/A |
| Memory Safety | Swift memory safety, ARC | Active |
| Dependency Management | Regular security updates, vulnerability scanning | Active |
Data Protection & Privacy
Lens implements privacy by design principles throughout the application.
Privacy Principles:
- Data Minimization: Only collects data necessary for core functionality
- Purpose Limitation: Data used only for stated purposes
- Storage Limitation: Data retained only as long as necessary
- User Control: Users control what data is captured and stored
- Transparency: Clear privacy policy and data handling disclosures
GDPR & CCPA Compliance
User Rights
| Right | Implementation | Status |
|---|---|---|
| Right to Access | Export functionality for user data | Implemented |
| Right to Deletion | Delete all app data via settings | Implemented |
| Right to Portability | Export media files with metadata | Implemented |
| Right to Rectification | Edit metadata before export | Implemented |
| Right to Object | Opt-out of analytics and telemetry | Implemented |
| Right to Restriction | Pause data processing | Implemented |
Cryptographic Security
Key Management
Keys are generated in hardware (Secure Enclave); password-based key derivation is not used.
| Aspect | Implementation | Standard |
|---|---|---|
| Key Generation | Secure Enclave hardware RNG | Platform (Apple); NIST SP 800-90A aligned per vendor documentation |
| Key Storage | Secure Enclave, non-extractable | Apple Secure Enclave (see Apple platform security) |
| Key Rotation | Per-device certificates, revocation support | Industry best practice |
| Key Backup | Device-only; no key export or iCloud backup | N/A |
Encryption Standards
| Use Case | Algorithm | Key Size | Status |
|---|---|---|---|
| C2PA Signing | ECDSA P-256 | 256-bit | Active |
| TLS | ECDHE + AES-256-GCM | 256-bit | Active |
| File Protection | AES-256 | 256-bit | Active |
Vulnerability Management
Security Testing
| Test Type | Frequency | Status |
|---|---|---|
| Static Analysis | Pre-commit, CI/CD | Active |
| Dependency Scanning | Weekly automated scans | Active |
| Penetration Testing | Annual third-party audits | Planned |
| Code Review | All changes reviewed | Active |
| Security Audits | Quarterly internal reviews | Active |
OWASP Mobile Top 10 Coverage
| Threat | Mitigation | Status |
|---|---|---|
| M1: Improper Platform Usage | iOS HIG compliance, secure APIs | Mitigated |
| M2: Insecure Data Storage | iOS Data Protection, encryption | Mitigated |
| M3: Insecure Communication | TLS 1.3, certificate pinning | Mitigated |
| M4: Insecure Authentication | Secure Enclave, biometric auth | Mitigated |
| M5: Insufficient Cryptography | Industry-standard algorithms | Mitigated |
| M6: Insecure Authorization | App sandbox, permission model | Mitigated |
| M7: Client Code Quality | Swift memory safety, code review | Mitigated |
| M8: Code Tampering | Code signing, runtime checks | Mitigated |
| M9: Reverse Engineering | Code obfuscation (optional) | Partial |
| M10: Extraneous Functionality | Minimal dependencies, code audit | Mitigated |
Vulnerability Disclosure:
- Responsible Disclosure: lens@field-notes.dev
- Response Time: 48 hours acknowledgment, 90 days resolution target
- CVE Assignment: For critical vulnerabilities
- Public Disclosure: After patch deployment and user notification
Dependency vulnerability management
We are committed to remediating Critical and High CVEs in our dependencies within 90 days. Our process (SCA, SBOM, policy, and runbook) is documented in our Product Security Architecture and dependency-vulnerability-management runbook. We use GitHub Dependency Graph and Dependabot for visibility and alerts, and Trivy in CI for vulnerability scanning and CycloneDX SBOM generation. For dependency CVE reports or questions: lens@field-notes.dev.
Compliance Certifications
| Certification | Status | Notes |
|---|---|---|
| ISO 27001 | Not Certified | Aligned with controls |
| SOC 2 Type II | Not Certified | Planned for future |
| GDPR | Compliant | Self-assessment |
| CCPA | Compliant | Self-assessment |
| HIPAA | Not Applicable | Not a healthcare app |