1. Introduction & Security Philosophy
Security at AIRMY is not a compliance checkbox — it is a core engineering discipline embedded into every layer of the platform. We believe that trust must be earned continuously, not declared once at launch. That means regular third-party audits, a public bug bounty programme, transparent incident reporting, and a security team that has a seat at every architectural decision.
Our security programme is built around three principles:
- Defence in depth: no single control is relied upon. Multiple independent layers — network, application, identity, data — each provide protection even if another is compromised.
- Least privilege everywhere: every human, service, and process has only the minimum permissions needed to perform its function, reviewed and revalidated regularly.
- Assume breach: we design systems and processes on the assumption that a breach can occur, focusing on detection, containment, and recovery, not just prevention.
Questions about our security posture or requests for audit reports should be sent to security@airmy.dev. Enterprise customers may request our SOC 2 Type II report under NDA.
2. Infrastructure Security
Multi-cloud, multi-region architecture
Production workloads run on AWS (primary: us-east-1, us-west-2) with failover capabilities on GCP (europe-west1). All regions operate independently, ensuring no single region failure affects global availability.
VPC isolation
Each environment (production, staging, development) is isolated in its own Virtual Private Cloud with no direct routing between them. Internal services communicate only through explicitly defined ingress/egress rules.
DDoS protection & CDN
All traffic passes through Cloudflare's global anycast network (DDoS mitigation up to Tbps scale) before reaching our origin. L3/L4 volumetric attacks and L7 application-layer attacks are mitigated at the edge.
Physical security
We do not operate our own data centres. All infrastructure runs on AWS and GCP, both of which hold ISO 27001, SOC 2, and SOC 3 certifications and employ 24/7 physical security, biometric access controls, and CCTV monitoring at their facilities.
3. Network Security
TLS 1.3 enforced
All external connections require TLS 1.3. TLS 1.0 and 1.1 are disabled. TLS 1.2 is permitted only for legacy client compatibility with explicit business justification, and is scheduled for removal in Q4 2026. HSTS is enforced with a max-age of 2 years and preload.
mTLS for internal services
All service-to-service communication within the platform uses mutual TLS (mTLS). Certificates are issued by our internal PKI (Vault PKI), short-lived (72 hours), and automatically rotated. No service accepts connections without a valid client certificate.
WAF & IDS/IPS
Cloudflare WAF and AWS WAF enforce rules against OWASP Top 10 attack patterns (SQLi, XSS, path traversal, etc.) at the edge and at the load balancer. AWS GuardDuty provides IDS/IPS capabilities with machine-learning-based anomaly detection and automated alerting to the Security team.
Zero-trust networking
Administrative access to production systems is mediated through a zero-trust access proxy (Tailscale + short-lived SSH certificates). There is no SSH bastion with persistent keys. All access is logged, attributed to a specific engineer, and reviewed weekly.
4. Data Encryption
4.1 Encryption at Rest
All customer data stored on AIRMY infrastructure is encrypted at rest using AES-256-GCM. This includes databases (RDS with storage encryption enabled), object storage (S3 with SSE-KMS), message queues, and backup snapshots. Encryption is enabled at the volume level as a default; there are no unencrypted storage resources in production.
4.2 Encryption in Transit
All data in transit — between your browser and our edge, between our edge and origin servers, and between internal microservices — is encrypted using TLS 1.3 (external) and mTLS (internal). We do not transmit data over unencrypted channels under any circumstances.
4.3 Key Management Hierarchy
Root KMS (AWS KMS / GCP Cloud KMS)
└─ Master Encryption Key (MEK) — rotated annually
└─ Data Encryption Keys (DEK) — per-resource, rotated every 90 days
└─ Encrypted Customer DataKeys are managed through AWS KMS (us-east-1 primary) and GCP Cloud KMS (europe-west1 replica). The Root KMS is an HSM-backed key store. No plaintext keys are ever stored to disk or transmitted outside the KMS boundary.
4.4 Customer-Managed Encryption Keys (CMEK)
Enterprise customers may bring their own encryption keys (CMEK). When CMEK is enabled, AIRMY's KMS wraps each DEK with your Customer Master Key (CMK) stored in your own AWS KMS, GCP Cloud KMS, or Azure Key Vault. Revoking your CMK immediately renders your data inaccessible to AIRMY. Contact security@airmy.dev to enable CMEK.
4.5 Key Rotation Policy
- Root KMS keys: annual automatic rotation via cloud provider.
- Master Encryption Keys: annual rotation, tested in staging prior to production.
- Data Encryption Keys: 90-day automatic rotation.
- TLS certificates: 90-day Let's Encrypt certificates with automated renewal; internal certificates are 72-hour short-lived.
- API keys and secrets: rotated on each use (JWT refresh tokens), annually (service account keys), or immediately on suspected compromise.
5. Application Security
5.1 Secure SDLC
Security is integrated into every stage of our software development lifecycle. Every feature undergoes a threat model review before implementation. Security requirements are tracked alongside functional requirements in our issue tracker. All engineers complete annual secure coding training.
5.2 SAST & DAST in CI/CD
Static Analysis (SAST)
Every pull request is scanned by CodeQL (GitHub Advanced Security) and Semgrep with AIRMY-specific rulesets. Critical or high severity findings block merge. Findings are reviewed and triaged within 48 hours.
Dynamic Analysis (DAST)
OWASP ZAP and Burp Suite Enterprise Edition run against staging after every major deployment. Results are tracked in our security backlog with SLAs based on CVSS severity.
Dependency scanning
Dependabot and Snyk continuously scan all first-party and third-party dependencies across every repository. Critical CVEs trigger immediate out-of-band patching; high CVEs are patched within 7 days.
5.3 Code Review Policy
Every code change requires approval from at least one other engineer (two for changes to security-critical paths: authentication, authorisation, cryptography, and payment processing). Security-critical PRs are additionally reviewed by a member of the Security team. No code is merged by the author alone.
5.4 Secrets Management
Secrets (API keys, database credentials, certificates) are managed exclusively through HashiCorp Vault. No secrets are stored in code, environment variables committed to source control, or configuration files in repositories. Our CI/CD pipelines pull secrets at runtime via Vault's dynamic secrets engine. Periodic automated scans (using truffleHog and gitleaks) check all repositories, including commit history, for accidentally committed secrets. Any detected secret is immediately rotated.
6. Access Controls & Authentication
6.1 Multi-Factor Authentication
MFA is mandatory for all AIRMY employees and contractors on every system — including email, cloud consoles, code repositories, production access proxies, and internal tools. Hardware security keys (FIDO2/WebAuthn, specifically YubiKey 5 series) are required for privileged access. TOTP is permitted for non-privileged access as a fallback only.
6.2 Single Sign-On & Identity
All internal systems are integrated with our corporate identity provider (Okta) via SAML 2.0 or OIDC. Employees cannot access internal systems without authenticating through Okta. User accounts are provisioned and deprovisioned through automated SCIM synchronisation from our HR system, ensuring offboarding is complete within one business day of departure.
6.3 Privileged Access Management (PAM)
Access to production environments is managed through our PAM solution (CyberArk). Production access requires just-in-time (JIT) approval from a manager and is granted for a maximum of 4 hours. All privileged sessions are recorded and stored for 12 months. There are no standing privileged credentials in production.
6.4 Least-Privilege & Access Reviews
All access rights follow the principle of least privilege — engineers have access only to the specific systems and data required for their current role. Access rights are reviewed quarterly by managers and annually by the Security team. Unused access rights are automatically flagged and revoked after 90 days of inactivity.
6.5 Privileged Access Workstations (PAW)
Engineers with production access use dedicated, hardened workstations (PAWs) that are separate from their everyday development machines. PAWs are enrolled in MDM (Jamf), run a hardened macOS configuration baseline, and have full-disk encryption, automatic screen lock, and endpoint detection & response (EDR) agents installed.
7. Incident Response & Business Continuity
7.1 Five-Phase Incident Response Plan
Detection & Triage
Automated alerts (GuardDuty, Sentry, Datadog anomaly detection) route to the on-call Security Engineer via PagerDuty. Initial severity assessment within 15 minutes of alert.
Containment
Affected resources are isolated (network ACLs, revoked credentials, snapshot preservation) to prevent lateral movement. Containment actions are documented in real time in a dedicated incident channel.
Eradication
Root cause is identified. Vulnerable code or configuration is patched. Compromised credentials are rotated. Malicious artefacts are removed and verified.
Recovery
Services are restored from clean snapshots or redeployed from verified artefacts. Recovery is validated by the Security team before traffic is restored. Customer communications are issued via the status page.
Post-Mortem & Lessons Learned
A blameless post-mortem is published internally within 5 business days. Action items are tracked and completed within agreed SLAs. Significant incidents result in a public status page post.
7.2 Breach Notification
In the event of a personal data breach, AIRMY will notify the relevant supervisory authority within 72 hours of becoming aware of it, as required by GDPR Article 33. Affected customers will be notified within 24 hours of our internal confirmation, with full details of the nature of the breach, data categories affected, and steps taken.
7.3 RTO / RPO Targets
| Tier | Description | RTO | RPO |
|---|---|---|---|
| Tier 1 — Critical | API gateway, authentication, core agent execution | 15 minutes | 5 minutes |
| Tier 2 — High | Dashboard, billing, marketplace | 1 hour | 15 minutes |
| Tier 3 — Standard | Reporting, analytics, admin tools | 4 hours | 1 hour |
7.4 Exercises
We conduct full tabletop incident response exercises quarterly, covering ransomware, data exfiltration, supply chain compromise, and insider threat scenarios. Annual disaster recovery drills test failover to secondary regions. Results inform updates to runbooks and the IR plan.
8. Compliance & Certifications
AIRMY maintains the following certifications and compliance frameworks. Audit reports are available to enterprise customers under NDA — contact security@airmy.dev.
SOC 2 Type II
Audited Jan 2026
Report available under NDA
ISO 27001
Certified Dec 2025
Certificate publicly available
HIPAA
BAA available
Enterprise customers only
GDPR
EU & UK compliant
DPA & SCCs available
CSA STAR
Level 2 — Mar 2026
Registry entry public
FedRAMP
In progress — 3PO
Target: Q2 2027
9. Vulnerability Management & Penetration Testing
9.1 Continuous Scanning
All production infrastructure is continuously scanned by AWS Inspector and Qualys Vulnerability Manager. Findings are imported into our vulnerability management platform (Drata) and automatically triaged based on CVSS v3 base score, exploitability, and asset criticality. The Security team reviews the full finding queue weekly.
9.2 Patch SLAs by Severity
| CVSS Score | Severity | Patch SLA | Process |
|---|---|---|---|
| 9.0 – 10.0 | Critical | 24 hours | Emergency out-of-band patch; incident declared |
| 7.0 – 8.9 | High | 7 days | Expedited patch; tracked in security sprint |
| 4.0 – 6.9 | Medium | 30 days | Scheduled in next sprint cycle |
| 0.1 – 3.9 | Low / Info | 90 days | Batched into quarterly hardening sprint |
9.3 Quarterly External Penetration Testing
We engage a qualified external red-team (currently Bishop Fox) for a full-scope penetration test every 90 days. Scope includes the web application, API, mobile SDKs, and cloud infrastructure. Test methodology follows PTES and OWASP Testing Guide v4.2. Full reports are available to enterprise customers under NDA. All critical and high findings are remediated and verified before the next test cycle begins.
10. Bug Bounty & Responsible Disclosure
10.1 HackerOne Programme
AIRMY runs a public bug bounty programme on HackerOne (launched March 2024). We welcome security researchers to test our production systems within the defined scope. Our programme is rated 4.9/5.0 by the HackerOne community for responsiveness and fairness.
Programme URL: hackerone.com/airmy
10.2 Scope
- airmy.dev and all subdomains
- api.airmy.dev (REST & GraphQL)
- AIRMY iOS and Android SDKs
- dashboard.airmy.dev
- Infrastructure misconfigurations (publicly accessible S3 buckets, exposed secrets, etc.)
Out of scope: Third-party services (Stripe, LinkedIn), social engineering of AIRMY employees, physical security, denial-of-service attacks.
10.3 Reward Table
10.4 Safe Harbour
AIRMY provides safe harbour to security researchers who act in good faith within the scope of the programme. We will not pursue legal action against researchers who: comply with our programme rules; do not access, modify, or delete customer data; report findings to us before public disclosure; and allow us a reasonable period to remediate before publication.
10.5 Hall of Fame
Researchers who have made significant contributions to AIRMY's security are acknowledged in our Security Hall of Fame. Recognition includes listing on the page, a signed letter of appreciation, and for critical findings, an invitation to our annual security summit.
11. Supply Chain Security
Vendor security assessments
All new vendors with access to production data or systems undergo a security assessment before onboarding. The assessment covers their certification posture, data handling practices, incident response history, and sub-processor chain. High-risk vendors require annual reassessment.
Sub-processor register
Our full sub-processor list is published in our Privacy Policy and updated in real time. Enterprise customers receive 30 days' prior written notice before any new sub-processor is added.
Software Bill of Materials (SBOM)
We generate and maintain SBOMs (CycloneDX format) for all production services as part of our CI/CD pipeline. SBOMs are available to enterprise customers on request and are used to rapidly assess exposure to newly disclosed CVEs.
Dependency pinning & provenance
All third-party dependencies are pinned to specific digests (not semver ranges) in production. GitHub Actions are pinned to commit SHAs. We use Sigstore (Cosign) to verify the provenance of container images before deployment.
12. Employee Security
Background checks
All employees and contractors with access to production systems or customer data undergo criminal record checks, identity verification, and reference checks before starting. Enhanced checks (including credit history) apply to roles with access to financial systems.
Security training
All staff complete security awareness training on joining and annually thereafter. Training covers phishing, social engineering, secure coding, data handling, and incident reporting. Completion is tracked; non-completion results in access restrictions. We also run monthly simulated phishing campaigns.
Confidentiality agreements
All employees and contractors sign comprehensive non-disclosure and data confidentiality agreements before receiving access to any AIRMY systems or customer data. These obligations survive termination of employment.
Offboarding procedure
On departure, all accounts are deprovisioned within 4 hours via automated SCIM. Equipment is returned and wiped (DoD 5220.22-M standard). API keys, SSH certificates, and service account access associated with the departing employee are revoked. Access review confirms completion within one business day.
13. Reporting a Vulnerability
If you have discovered a security vulnerability in AIRMY's systems, please report it to us responsibly before public disclosure. We take all reports seriously and will acknowledge receipt within 24 hours and provide a remediation timeline within 72 hours.
Email: security@airmy.dev
HackerOne: hackerone.com/airmy (preferred for eligible bounty reports)
PGP Key Fingerprint: A1B2 C3D4 E5F6 0708 9A0B C1D2 E3F4 0506 0708 09AB
Please encrypt sensitive reports using our PGP key. The public key is available at airmy.dev/.well-known/security.txt and on the MIT key server.
13.1 Response SLA
- Acknowledgement: within 24 hours of receipt
- Initial assessment & severity determination: within 72 hours
- Remediation timeline communicated: within 7 days
- Patch for critical vulnerabilities: within 24 hours of confirmation
- Patch for high vulnerabilities: within 7 days of confirmation
- Researcher notification on fix: before public disclosure
For general security questions not related to a specific vulnerability, please contact security@airmy.dev. For privacy and data protection matters, contact dpo@airmy.dev.