When a security team evaluates Aikido Security as a vendor, the first stop is almost always the Aikido Security trust center at aikido.dev/trust-center. It's a reasonably well-organized page: SOC 2 Type II and ISO 27001:2022 badges up top, a GDPR statement, a pentest summary, and a link to a bug bounty program hosted on Intigriti. For a platform that reads your source code, git history, and cloud configuration, that page is doing a lot of work — it's the artifact most procurement teams will screenshot into a vendor risk spreadsheet and never look at again. The problem is that a trust center is a marketing surface first and an audit surface second. It tells you what a vendor wants you to conclude, not necessarily what you'd find if you pulled the underlying SOC 2 report, the pentest letter, and the subprocessor list. Here's what's actually on Aikido's trust center, what it implies, and what it leaves for you to ask about directly.
What certifications does Aikido Security actually hold?
Aikido holds SOC 2 Type II (AICPA) and ISO 27001:2022, and states it is in full compliance with GDPR; FedRAMP is listed as "actively implementing," meaning it is not yet authorized. That's a legitimate baseline — SOC 2 Type II in particular means an auditor observed controls operating over a period (typically 6-12 months), not just a point-in-time design review, which is the more common (and weaker) SOC 2 Type I. The trust center also references alignment with NIS2, OWASP Top 10, and CIS v8, though these are framework mappings rather than independent certifications — nobody "gets certified" in OWASP Top 10. If FedRAMP matters to your deal (federal, defense-adjacent, or agencies-as-customers work), Aikido is not there yet, and "actively implementing" carries no committed date on the public page. Ask directly for a target authorization quarter before you build a roadmap around it.
How often does Aikido pentest its own platform?
Aikido states it runs an annual external pentest, supplemented by a continuous bug bounty program on Intigriti. Once-a-year third-party testing is the industry floor, not a differentiator — it's what SOC 2 and ISO 27001 effectively require, and it means a vulnerability introduced in month two of the cycle could sit for up to ten months before the next scheduled test catches it. The Intigriti program partially offsets that gap: it's continuous, covers the core web app and, per recent program updates, the VS Code extension at the same (Tier 2) bounty tier, and Aikido pays researchers up to €50 to verify a fix once an issue is resolved. That's a healthy signal of engagement with the researcher community, but bug bounty coverage depends on which researchers show up and what they choose to test — it's not a substitute for a structured pentest against a defined scope. The trust center doesn't publish the pentest firm's name, the report date, or a redacted summary of findings; those normally require an NDA request through sales.
What happens to your source code when Aikido scans it?
Per Aikido's published documentation, code is cloned into a fresh, isolated Docker container per repository for the duration of analysis, then the container is destroyed and the data wiped — Aikido states it does not persistently store your code after a scan completes. GitHub/GitLab refresh and access tokens are described as not being stored in Aikido's database, and integrations default to read-only scope, meaning the platform can't push commits or modify branch protections unless you explicitly grant more. For a code-and-cloud scanner with 50,000+ organizations and 100,000+ developers reportedly connected, this is the right default posture, and it mirrors what most competent SAST/SCA vendors now do. What's harder to verify from the trust center alone is retention of derived data — the SBOMs, dependency graphs, secrets findings, and vulnerability metadata generated from your code, which by definition persist in Aikido's database indefinitely unless you delete the account. Ephemeral source code storage is meaningfully different from ephemeral findings storage, and the two get conflated in vendor pitches more often than they should.
What does Aikido's trust center leave out?
It leaves out a published subprocessor list, a data residency commitment, and an uptime SLA on the public-facing page — all three are standard line items on trust centers built on platforms like Vanta or SafeBase, and their absence (or gating behind an NDA/request form) means you can't do a quick subprocessor diff against your own vendor list without opening a support ticket. It also doesn't state data center regions (EU vs. US hosting matters if you're a GDPR-bound company insisting on EU data residency), retention periods for scan findings after contract termination, or whether customer data is used to train any AI features — a live question given Aikido's AI-powered pentest and AI triage features. None of this means the answers are bad; it means the trust center is a summary, not a substitute for the underlying SOC 2 report (which will list actual subprocessors in the system description) and a direct security questionnaire.
How should a buyer actually use the Aikido Security trust center?
Use it as a starting checklist, not a closing argument: confirm the SOC 2 Type II report date and audit period, request the ISO 27001 certificate and its scope statement, and ask for the pentest firm name plus report date rather than accepting "annual pentest" as sufficient detail. A SOC 2 Type II report issued in, say, Q1 2025 covering an audit window through late 2024 tells you something different than one refreshed last month — trust centers frequently display a badge without a visible "as of" date, and badges don't expire visibly the way certificates do. The practical move: request the full report under NDA, check the audit period end date, check for any noted exceptions in the auditor's opinion, and cross-reference the subprocessor list against your own DPA requirements before signing anything.
How Safeguard Helps
Safeguard was built on the premise that the trust center itself shouldn't be the thing you're auditing manually — the evidence behind it should be continuously verifiable, not a static PDF refreshed once a year. Where Aikido's public page states an annual pentest cadence and a same-container-wiped code handling model as claims, Safeguard's supply chain security platform is built to generate and expose live, continuously updated evidence: real-time SBOM generation and diffing so you can see exactly what changed between scan windows, continuous dependency and vulnerability monitoring rather than a once-a-year snapshot, and audit-ready compliance mappings for SOC 2, ISO 27001, and emerging frameworks like NIS2 and DORA that update as controls actually run — not as a marketing page gets refreshed on someone's quarterly checklist. For teams evaluating either platform as part of a vendor risk review, the questions in this walkthrough — pentest cadence, data retention scope, subprocessor transparency, certification audit periods — are exactly the ones Safeguard's own trust posture is designed to answer without a follow-up email. If you're building a comparison matrix for your next vendor security review, ask both vendors for the underlying SOC 2 report and pentest letter, not just the badge, and see which one hands it over in the same day.