# Gecko > Gecko is an AI security engineer. It learns what your software is for, finds the vulnerabilities that matter as code is written, proves each one with a working exploit, and fixes the class it belongs to, not just the instance, with guardrails so it cannot return. Sold to enterprise security teams. The metric is recurrence, not MTTR. [Website](https://www.gecko.security) ## Audience - Security leadership (CISO / VP of Security): Personally accountable for breach risk in a regulated enterprise. Buys on whether vulnerabilities stop coming back, not on how fast tickets close. Wants proof, data control, and no absolutes that make engineers wince. - Engineering leadership (Head of AppSec / Engineering Manager): Owns security outcomes alongside delivery, often without a dedicated AppSec team. Needs findings that are real and fixes that land in the existing workflow without stalling the roadmap. ## Pages - [About](https://www.gecko.security/about): Gecko is built by two security practitioners, JJ Jutla and Artemiy Malyshau, and backed by Y Combinator, Liquid 2, Ritual Capital, Rebel Fund, Garage and Z Fellows, with advisors who have run security at large enterprises. - [Book a Demo](https://www.gecko.security/book-a-demo): Book a 30-minute demo of Gecko Security: a walkthrough of real findings, root-cause fixes, and how a POC on your own code would work. - [Contact](https://www.gecko.security/contact): Send a message to the people who build Gecko. Questions about how it works, what it costs, or whether it fits your stack are answered by the team, and a demo is thirty minutes with real findings on real code. The page also carries approved customer quotes from Chevron, Cal.com and a Fortune 500 financial institution. - [Glossary](https://www.gecko.security/glossary): Plain definitions of fifteen terms behind how Gecko works, each leading with a direct answer and then the mechanism underneath: class of vulnerability, variant analysis, semantic graph, trust boundary, reachability, name resolution, taint tracking, root cause, remediation, false positive, triage, coverage, recurrence, business logic vulnerability and trust gradient. - [Home](https://www.gecko.security): Gecko traces every vulnerability to the design decision that created it, fixes the whole class across every repo, and sets guardrails so the pattern cannot return. First findings typically arrive within the hour. - [Integrations](https://www.gecko.security/integrations): Gecko integrates with Jira, ClickUp, Slack, Wiz, and GitLab’s security dashboard, plus AI agents over MCP including Claude Desktop, Claude Code, ChatGPT, Codex, Devin, and Corridor. Every fix is verified back in Gecko. - [Pricing](https://www.gecko.security/pricing): Start free with 10 scans on your own code. Pro is $100 a month for 100 scans, integrations and custom rules. Enterprise adds unlimited scanning, SSO with SCIM, audit logs and on-premise or hybrid deployment. - [Privacy Policy](https://www.gecko.security/privacy-policy): Gecko Security’s privacy policy, version 2.0, effective 28 April 2026: the personal data collected from users and visitors, how it is used and shared, retention periods, subprocessors, and the data protection rights of EU and UK users. - [Resources](https://www.gecko.security/resources): Research, guides and CVE disclosures from the Gecko team on eliminating vulnerability classes, measuring recurrence instead of MTTR, and securing code written at AI speed. - [Terms of Service](https://www.gecko.security/terms-of-service): The Cloud Service Agreement, last revised 13 May 2026, governing use of the Gecko Security site and cloud services: access and use, restrictions, payment, warranties, liability and dispute resolution. ## Optional ### Blog posts - [How Cal.com Rebuilt AppSec After Going Closed Source](https://www.gecko.security/resources/how-cal-com-rebuilt-appsec-after-going-closed-source): Cal.com is one of the fastest-growing scheduling platforms in the world, used by over a million people and trusted by companies like Vercel, Coinbase, and Ramp. It spent five years as one of the most visible open-source companies on the internet, until April 2026, when it went closed source to protect its customers from a wave of AI-driven security threats aimed at its code. Matt Johansen sits down with Cal.com CEO Bailey Pumfleet to talk through the move to closed source and how Cal.com uses Gecko to secure every pull request. - [n8n Cross-user Authorization Bypass in Dynamic Credential OAuth Endpoints](https://www.gecko.security/resources/n8n-dynamic-credential-oauth-bypass): The enterprise dynamic-credentials OAuth endpoints allow any authenticated n8n user to operate on another user’s OAuth credential by supplying its ID. The controller loads credentials through an unscoped lookup and never verifies that the caller has permission on the target credential. This affects the authorize and revoke endpoints used by the dynamic-credentials feature. A low-privilege authenticated user can initiate or revoke OAuth binding flows for credentials they do not own, enabling unauthorized OAuth rebinding, token revocation, and persistent takeover of shared integrations. This issue affects enterprise instances with the dynamic credentials feature enabled. - [CVE-2026-42227: n8n Public API Variables IDOR Allows Cross-Project Secret Disclosure](https://www.gecko.security/resources/cve-2026-42227): An IDOR in the public variables API allows authenticated users to read project variables outside their authorized project scope. ts) directly queries VariablesRepository with a user-controlled projectId, instead of enforcing membership checks through VariablesService. In enterprise/team setups with multiple projects, a regular member with variable:list scope can read variables from projects they do not belong to, including sensitive values. This issue only affects licensed enterprise or team deployments with multiple projects and the variables feature enabled. user has access to the requested project. - [API Scanning: Complete Guide to Automated Security Testing](https://www.gecko.security/resources/api-scanning-complete-guide-automated-security-testing): Most security teams find API vulnerability scanning tools generate thousands of alerts, most of which turn out to be false positives or low-priority findings you’ll never fix. The real problem isn’t the noise, though that’s painful enough. It’s that rules-based detection fundamentally can’t catch business logic flaws. Your scanner sees individual endpoints in isolation, not the call chains that span microservices or the authorization model that should apply consistently but doesn’t. It flags suspicious patterns while completely missing the logic bugs that actually threaten your system. API scanning is the automated process of testing application programming interfaces for security vulnerabilities, from technical flaws like broken authentication to business logic issues that allow unauthorized access. - [Automated Pentest: Complete Guide to Tools and Best Practices](https://www.gecko.security/resources/automated-pentest-guide-tools-best-practices): Your security team probably runs automated pentests after major releases and calls it good. Meanwhile, your application ships new code daily with authorization checks that work exactly as written but completely bypass intended access controls. Traditional scanners miss these because they match syntax patterns instead of understanding semantic relationships across your codebase. The gap between what automation promises and what it delivers comes down to one thing: whether tools can reason about application behavior or just grep for dangerous strings. Let’s look at what actually works. Automated penetration testing uses software-driven agents to simulate real-world attacks against your applications and infrastructure. - [Best AI-Powered Application Security Testing Tools](https://www.gecko.security/resources/best-ai-powered-application-security-testing-tools): You’ve probably run Semgrep or Snyk and felt pretty good about the results. But here’s the problem: they can’t tell you if your authorization logic is broken. There’s no signature for a missing permission check, no taint flow for an IDOR vulnerability hiding in your service mesh. AI vulnerability scanning that actually reasons about code semantics is what catches these. We ranked every tool by whether it can find what pattern matching fundamentally can’t. Traditional security scanners work by matching patterns. They look for known signatures, track data flows through taint analysis, and flag code that resembles something dangerous. - [14 Best AI Security Tools: Features, Pricing, and Comparisons](https://www.gecko.security/resources/best-ai-security-tools): You need an ai security tool that finds real vulnerabilities without burying your team in false positives. The market’s crowded with options, and most of them excel at catching injection bugs while completely missing broken access controls, IDOR, and privilege escalation chains across your microservices. Whether you’re securing AI systems themselves or using AI to scan code, knowing which category you’re shopping in makes the difference between a tool that gets adopted and one that gets ignored after the first week. Here’s what’s worth your time in March 2026. AI security tools fall into two broad camps. - [Claude Code Review: What Code Scanners Cannot Tell You About Real Risk](https://www.gecko.security/resources/claude-code-review-changed-ai-development): Finding vulnerabilities in code has never been the hard part. Knowing which ones are exploitable in your specific system is what breaks security teams. And it’s exactly what every code scanner, including Claude Code Review and Claude Code Security, cannot tell you. Both products read source files. Neither has visibility into your deployment, your trust model, or your infrastructure. A buffer overflow behind two layers of internal auth is a different risk than the same bug on a public endpoint. Code alone doesn’t contain that information. Your trust model lives in architecture documents. - [Claude Code Security Review: Complete Guide for Developers](https://www.gecko.security/resources/claude-code-security-review-guide): The Claude Code Security Review GitHub Action shows up in your PR checks, flags some vulnerabilities, and maybe suggests a fix. You’re probably wondering whether it actually catches the authorization bugs and logic flaws that slip past your existing SAST tools. The short answer: sometimes, but with specific blind spots you need to know about. Here’s what’s really happening when Claude analyzes your code for security issues, and where you’ll need different tooling to cover the gaps. Claude Code Security Review is Anthropic’s AI-powered code analysis feature built into Claude Code, the company’s development environment. - [Cloud-Native Security Platform: A Complete Guide](https://www.gecko.security/resources/cloud-native-security-platform-complete-guide): The best cloud-native security platforms today consolidate what used to be five separate products into unified coverage across your cloud stack. That sounds great until you realize 97% of organizations still reported a security incident in the past year, and only 39% have a mature strategy backing their tools. The problem goes beyond configuration drift or missing policies. Traditional tooling can’t reason about whether your code does what it’s supposed to do. We’ll cover how CNAPP fits into your stack, what the core components actually secure, and where you still need something that understands application logic instead of scanning for known patterns. - [Codex Security: Complete Guide to Codex Security’s Code Vulnerability Scanner](https://www.gecko.security/resources/codex-security-complete-guide-openai-code-vulnerability-scanner): Most vulnerability scanners tell you whether dangerous functions get called with user input, but they can’t tell you whether your authorization logic actually works. Codex Security flips this model by asking semantic questions about your code: Does this execution path include a permission check? Should this parameter be validated but isn’t? 2 million commits and identified 10,561 high-severity vulnerabilities by reasoning about intent instead of matching patterns. But threat modeling against source code carries a fundamental risk: when the code is the only input, the scanner treats all existing behavior as expected behavior. - [Cross-Domain Authentication: A Complete Guide](https://www.gecko.security/resources/cross-domain-authentication-complete-guide): When you authenticate users across multiple domains, you’re passing tokens between services and creating trust boundaries where authentication context needs to persist through redirects, API calls, and service-to-service communication. At Gecko Security, we analyze cross-domain authentication vulnerabilities in distributed systems and find the same gap: developers validate credentials at entry points but internal services skip verification because they assume requests from other services are already authenticated. This guide walks through how authentication actually flows across domains, where the security model breaks down, and what proper verification looks like at every service boundary. - [How to Fix ‘This Environment Is Externally Managed’ Error in Python](https://www.gecko.security/resources/fix-environment-externally-managed-python-error): When pip says “environment is externally managed”, it’s blocking you from installing packages into the system Python. You’ll see this on Ubuntu, macOS with Homebrew, Raspberry Pi, inside Docker, pretty much any modern OS that uses a package manager to control Python installations. The error originated with PEP 668 as a way to prevent pip from overwriting packages that system tools depend on, which used to cause silent breakage that was nearly impossible to debug. The solution isn’t always the same though, because what works for a throwaway CI container will break a long-lived server, and what makes sense for a development project doesn’t fit CLI tools you want available globally. - [Gecko Security vs ZeroPath: Which Is Better?](https://www.gecko.security/resources/gecko-security-vs-zeropath): When you’re comparing Gecko and ZeroPath, the real question is which tool gives you findings you can actually act on. Gecko ingests runtime data, architecture diagrams, and design documents alongside code, so every finding comes with proven exploitability conditions, a Proof of Concept, and mapped business impact, each backed by real evidence beyond a raw code location. Gecko also uses language servers to resolve complex call chains in dynamically typed languages like Python and JavaScript, where objects shift at runtime and AST-based parsing loses the thread entirely. That accuracy is what lets Gecko scan across microservices and multi-repo architectures, including repos that import shared libraries, catching vulnerabilities single-repo tools miss. - [GHCR: Complete Guide to GitHub Container Registry](https://www.gecko.security/resources/ghcr-github-container-registry-guide): You switched to GHCR because storage is free and you’re tired of Docker Hub’s pull limits breaking your builds. Then you spend an afternoon figuring out why docker push fails with permission denied even though you authenticated successfully, why your organization packages need SSO authorization on tokens, and which combination of read:packages, write:packages, and repo scopes you actually need. The authentication system connects to GitHub’s existing permissions in ways that create non-obvious failure modes. io. If you’re already using GitHub for source control, GHCR lets you store and distribute OCI-compliant container images in the same ecosystem where your code lives. - [SAST vs DAST: Complete Guide to Application Security Testing](https://www.gecko.security/resources/sast-vs-dast-guide): Everyone talks about combining SAST and DAST for complete security testing, but if you’re actually running both tools, you’ve noticed something frustrating. You catch SQL injection and XSS early with static scans, validate runtime configurations with live testing, and still ship authorization bugs that neither method detected. The problem isn’t your tooling choices or configuration settings. It’s that pattern matching can’t answer whether your code enforces the security properties it should, which is exactly what business logic vulnerabilities exploit. SAST (Static Application Security Testing) analyzes your source code, bytecode, or binaries without executing the application. - [Securing AI-Generated Code: A Complete Framework](https://www.gecko.security/resources/securing-ai-generated-code-complete-framework): The code your AI assistant generates usually works, which is exactly why the security problems slip through. Securing AI-generated code requires different analysis than what traditional SAST tools provide because the vulnerabilities aren’t structural, they’re semantic. An endpoint that returns user data without checking ownership, an update function that skips authorization, a deletion route that doesn’t verify permissions all look syntactically correct. Your security tools need to understand execution paths across files and services, tracing whether authorization checks actually happen before sensitive operations run, beyond matching code patterns to known vulnerability signatures. - [SQLi CVE Database: A Complete List of SQL Injection Vulnerabilities](https://www.gecko.security/resources/sqli-cve-database): Three new SQLi CVEs dropped in April 2026, and at least one is already seeing active exploitation in the wild. If you’re trying to understand whether your code has similar SQLi CVE bypass risks, the pattern is pretty clear: attackers are targeting authentication flows where input validation happens at the wrong layer, ORM raw query methods that developers assume are safe, and second-order injection points that never get flagged by signature-based tools. We’re covering what makes CVE-2026-34612, CVE-2026-34717, and CVE-2026-34934 worth immediate attention and what detection gaps let them through in the first place. - [SSRF in File Upload Processing: Complete Prevention Guide](https://www.gecko.security/resources/ssrf-file-upload-processing-prevention-guide): Your upload handler passes every security scan, validates file types, and restricts extensions. But SSRF in file upload processing doesn’t care about any of that because the attack happens when ImageMagick or your PDF renderer resolves an external reference you never explicitly called. 254 and your IAM credentials are gone. This is a semantic problem where intent diverged from implementation, and catching it requires understanding what your code is supposed to do, beyond what it does. File upload features seem straightforward: user picks a file, server stores it. But many applications go further, fetching remote content by URL, processing linked images, or pulling documents from external sources. - [Transitive Dependencies Explained: A Complete Guide](https://www.gecko.security/resources/transitive-dependencies-explained-complete-guide): Your Maven or npm project contains way more packages than you remember adding. That’s because transitive dependencies in Maven and other package managers automatically pull in nested libraries whenever you import something new. The concept is straightforward: if your code depends on Package A, and Package A depends on Package B, then B becomes your transitive dependency. The same principle exists in database normalization, where it describes non-key attributes depending on other non-key attributes instead of the primary key. Both scenarios create indirect relationships that cause specific problems: data anomalies in databases, and security blind spots in your software supply chain.