Gitleaks vs Gecko Security

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round to Gecko Security
   Gitleaks—none0/10

   A direct probe found no llms.txt file (404) and no agent-oriented docs/openapi endpoints, so there is no evidence Gitleaks provides machine-readable docs for AI agents.

   • [probe] “PROBE llms.txt: HTTP 404 at https://gitleaks.io/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://gitleaks.io/openapi.json, https://gitleaks.io/swagger.json, https://gitleaks.io/api/openapi.…”

   proof ↗⚑ flag

   Gecko Security✓fullprobed9/10

   Direct probes confirm Gecko serves both llms.txt (HTTP 200) and a docs.md aggregate at the docs root, plus an OpenAPI spec and documented MCP/AI-tool integration for agents to consume — exactly the agent-oriented docs surface the story asks for. Missing for 10: no independent/community confirmation that an agent actually consumed llms.txt successfully in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://gecko.security/llms.txt # Gecko Security > Gecko Security is an AI security engineer that finds exploit…”
   • [probe] “PROBE docs-md: HTTP 200 at https://gecko.security/docs.md --- title: "Gecko Security - Gecko Security" description: "An AI security engineer…”
   • [probe] “PROBE openapi: HTTP 200 at https://gecko.security/openapi.json — contains "openapi" key”
   • [claimed-docs] “Connect it to an AI tool and the tool can list your repositories and scans, pull full vulnerability evidence (proof of concept, call chain, …”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round to Gitleaks
   Gitleaks✓fullclaimed8/10

   Gitleaks is a CLI that scans repos, directories, or stdin, is installable via Homebrew/Docker/Go, and has an official GitHub Action (gitleaks-action) for automated CI scanning on PRs/commits with exit-code-based pass/fail reporting, making it well-suited for headless CI automation. Missing for 10: evidence of non-GitHub CI integrations (GitLab CI, Jenkins, CircleCI) and JSON/SARIF output examples for machine-readable pipeline consumption.

   • [github] “The `git` command lets you scan local git repos.”
   • [github] “The `dir` (aliases include `files`, `directory`) command lets you scan directories and files.”
   • [github] “You can also stream data to gitleaks with the `stdin` command.”
   • [github] “Gitleaks can be installed using Homebrew, Docker, or Go.”
   • [claimed-docs] “Enable **Gitleaks-Action** in your GitHub workflows to be alerted when secrets are leaked as soon as they happen.”
   • [claimed-docs] “You can use it to automatically run a gitleaks scan on all your team's pull requests and commits, or run on-demand scans.”
   • [github] “➜ git commit -m "this commit contains a secret" Detect hardcoded secrets.................................................Failed”

   proof ↗⚑ flag

   Gecko Security✓fullprobed7/10

   Gecko exposes a v1 API to trigger scans and read/triage results, dedicated CI/CD-labeled API keys, PR-check integration with configurable fail-on-severity thresholds that post pass/fail status back to GitHub/GitLab, and webhooks for automation pipelines — all enabling headless operation in CI. Missing for 10: independent/hands-on verification that CI pipelines actually work end-to-end, and no explicit example CI configs (e.g., GitHub Actions YAML) are shown.

   • [claimed-docs] “Gecko's v1 API lets you trigger scans, read scan, repository, and vulnerability data, triage findings, manage scan schedules, rotate your Gi…”
   • [claimed-docs] “Give the key a descriptive name, such as `CI/CD Pipeline` or `Production`.”
   • [claimed-docs] “Gecko posts a pass/fail check back to GitHub or GitLab so reviewers see the security status inline.”
   • [claimed-docs] “**Fail-on severity**: the severity threshold that fails the check (for example, fail on High and above).”
   • [claimed-docs] “Gecko can push events to your systems as scans run and findings change: page a channel when a scan fails, open a workflow when a critical la…”
   • [probe] “PROBE openapi: HTTP 200 at https://gecko.security/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

3. ai-native userUse an official CLI

   weight 2 · round to Gitleaks
   Gitleaks✓fullprobed8/10

   Gitleaks ships a first-party CLI (git, dir, stdin subcommands) that is well documented with usage examples and is the primary interface for the tool, making it fully scriptable/automatable for agentic workflows. Missing for 10: no explicit agent/LLM-oriented docs (e.g., llms.txt returns 404) or structured JSON-output guidance tailored to AI consumers.

   • [github] “The `git` command lets you scan local git repos.”
   • [github] “The `dir` (aliases include `files`, `directory`) command lets you scan directories and files.”
   • [github] “You can also stream data to gitleaks with the `stdin` command.”
   • [github] “Gitleaks is a tool for detecting secrets like passwords, API keys, and tokens in git repos, files, and whatever else you wanna throw at it v…”
   • [probe] “official CLI documented at https://github.com/gitleaks/gitleaks”

   proof ↗⚑ flag

   Gecko Security—none0/10

   No evidence of an official CLI; Gecko offers a GitHub App, REST API, webhooks, and an MCP server for AI tools, but nothing in the docs, changelog, or probes mentions a CLI tool for AI-native workflows.

   ⚑ flag

4. ai-native userDrive the product through a documented public API

   weight 3 · round to Gecko Security
   Gitleaks—none0/10

   Gitleaks is a CLI/scanner tool with no documented public API for programmatic/agentic access; probes confirm no llms.txt and no OpenAPI/swagger endpoint exist, and the CLI/GitHub Action docs don't constitute a public API.

   • [probe] “PROBE llms.txt: HTTP 404 at https://gitleaks.io/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://gitleaks.io/openapi.json, https://gitleaks.io/swagger.json, https://gitleaks.io/api/openapi.…”
   • [probe] “official CLI documented at https://github.com/gitleaks/gitleaks”

   proof ↗⚑ flag

   Gecko Security✓fullprobed8/10

   Gecko documents a public v1 API (trigger scans, read scan/repo/vulnerability data, triage findings, manage schedules, rotate tokens, webhooks) with a live OpenAPI spec confirmed by probe, plus API key management and per-request logging. missing for 10: independent third-party developer confirmation of API usage/reliability beyond docs and probes, and more detail on API rate limits/versioning stability.

   • [claimed-docs] “Gecko's v1 API lets you trigger scans, read scan, repository, and vulnerability data, triage findings, manage scan schedules, rotate your Gi…”
   • [claimed-docs] “API keys are now visible to the whole team with owner attribution and per-request usage logging”
   • [claimed-docs] “Gecko can push events to your systems as scans run and findings change: page a channel when a scan fails, open a workflow when a critical la…”
   • [claimed-docs] “Give the key a descriptive name, such as `CI/CD Pipeline` or `Production`.”
   • [probe] “PROBE openapi: HTTP 200 at https://gecko.security/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

5. ai-native userSubscribe to events via webhooks

   weight 2 · round to Gecko Security
   Gitleaks—none0/10

   Gitleaks is a CLI secret-scanning tool with CI integrations (GitHub Action, PR comments, alerts) but no evidence of a webhook subscription mechanism for events; probes for API/openapi specs returned 404s, and no webhook docs exist.

   • [probe] “PROBE llms.txt: HTTP 404 at https://gitleaks.io/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://gitleaks.io/openapi.json, https://gitleaks.io/swagger.json, https://gitleaks.io/api/openapi.…”
   • [claimed-docs] “Enable **Gitleaks-Action** in your GitHub workflows to be alerted when secrets are leaked as soon as they happen.”
   • [claimed-docs] “A list of GitHub accounts that should be alerted when **gitleaks-action** detects a leak.”

   proof ↗⚑ flag

   Gecko Security✓fullclaimed8/10

   Docs explicitly describe webhook subscriptions for scan/finding lifecycle events (scan fail, critical finding) and the API reference lists webhook events as a first-class capability alongside the API. This directly matches the story's ask for event subscription via webhooks. Missing for 10: independent/hands-on confirmation that webhook delivery works reliably and no detail on payload schema/retry semantics.

   • [claimed-docs] “Gecko can push events to your systems as scans run and findings change: page a channel when a scan fails, open a workflow when a critical la…”
   • [claimed-docs] “Gecko's v1 API lets you trigger scans, read scan, repository, and vulnerability data, triage findings, manage scan schedules, rotate your Gi…”

   proof ↗⚑ flag

Agentic features

1. ai-native userGet AI-generated insights and suggestions from my data inside the product

   weight 2 · round to Gecko Security
   Gitleaks—none0/10

   Gitleaks is a rule-based secret-detection scanner with no evidence of AI-generated insights, summaries, or suggestions; probes for llms.txt and API/OpenAPI endpoints returned 404, and all documented features are deterministic regex/rule-based scanning, alerting, and CI integration.

   • [probe] “PROBE llms.txt: HTTP 404 at https://gitleaks.io/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://gitleaks.io/openapi.json, https://gitleaks.io/swagger.json, https://gitleaks.io/api/openapi.…”
   • [github] “Gitleaks offers a configuration format you can follow to write your own secret detection rules”
   • [github] “Gitleaks is a tool for detecting secrets like passwords, API keys, and tokens in git repos, files, and whatever else you wanna throw at it v…”

   proof ↗⚑ flag

   Gecko Security!disputedcontradicted5/10

   Gecko generates AI insights (severity, confidence score, call chain, PoC, suggested patch, AI-written repo wiki, endpoint map, PR review summaries) directly from scanned code data, per docs-2/17/18/19. However, hands-on community reports show these AI-generated findings can be inaccurate — 100%-confidence 'vulnerabilities' that weren't real, missed real issues a competing tool caught, and a trivial/irrelevant finding on another scan — directly contradicting the reliability of the insights. Missing for 10: independent validation of insight accuracy at scale, resolution of the false-positive/false-negative reports.

   • [claimed-docs] “Each finding includes a severity (CVSS 4.0), a confidence score, the full source-to-sink call chain, a proof of concept, and a suggested pat…”
   • [claimed-docs] “Repository wiki: An AI-written map of your app: architecture, routing, and security model.”
   • [claimed-docs] “Endpoint map: The HTTP attack surface Gecko discovered in your code.”
   • [claimed-docs] “PR reviews & fixes: On pull requests, a security review summary and one-click fixes.”
   • [community] “Tool gave 100% confidence for two vulnerabilities (severity 9.4 and 6.5) that turned out not to be real.”
   • [community] “Ran Gecko on a C project after Semgrep AI flagged a minor real issue; Gecko found nothing. After removing the fix and recreating the project…”
   • [community] “Uploaded a project (sydbox) to scan; took 10 minutes and found only one vulnerability, an 'RCE: IRC Message Command Execution Bypass' in an …”

   proof ↗⚑ flag

2. ai-native userSet up automations that run autonomously in the background

   weight 2 · round to Gecko Security
   Gitleaks~partialclaimed6/10

   Gitleaks-action lets teams wire secret scanning to run automatically in the background on every push/PR (and pre-commit hooks trigger locally) without manual intervention, satisfying the 'runs autonomously' spirit of the story. Missing for 10: no evidence of scheduled/cron-based or event-driven automation beyond git hooks/CI triggers, and no AI-agent-specific orchestration or self-triggering capability.

   • [claimed-docs] “Enable **Gitleaks-Action** in your GitHub workflows to be alerted when secrets are leaked as soon as they happen.”
   • [claimed-docs] “You can use it to automatically run a gitleaks scan on all your team's pull requests and commits, or run on-demand scans.”
   • [github] “You can run Gitleaks as a pre-commit hook by copying the example `pre-commit.py` script into your `.git/hooks/` directory.”
   • [claimed-docs] “There are no changes to inputs, outputs, or behavior. The upgrade is a one-line change in your workflow file”

   proof ↗⚑ flag

   Gecko Security✓fullclaimed7/10

   Gecko documents autonomous background workflows: scheduled scans via the API ('manage scan schedules'), automatic PR-triggered scans with pass/fail checks, auto-fix PR generation and re-verification, ticket creation, and webhook events pushed to external systems as scans run — all without manual intervention once configured. This directly matches the 'automations that run autonomously in the background' story for a security-scanning product. missing for 10: independent/hands-on confirmation that scheduled scans and auto-fix loops run reliably unattended over time, and more detail on configuring recurring schedules beyond a brief API mention.

   • [claimed-docs] “Gecko's v1 API lets you trigger scans, read scan, repository, and vulnerability data, triage findings, manage scan schedules, rotate your Gi…”
   • [claimed-docs] “Gecko can push events to your systems as scans run and findings change: page a channel when a scan fails, open a workflow when a critical la…”
   • [claimed-docs] “Gecko posts a pass/fail check back to GitHub or GitLab so reviewers see the security status inline.”
   • [claimed-docs] “Click Request fix to open a gecko/* pull request with the patch applied, or apply the patch yourself.”
   • [claimed-docs] “Gecko rechecks the finding and marks it Fix verified once the vulnerability is gone.”
   • [claimed-docs] “create a ticket in Jira, Linear, ClickUp, or Shortcut”
   • [claimed-docs] “Commit to an existing PR: For findings from a PR scan, Gecko can commit the fix directly to the PR's head branch so the fix rides along with…”

   proof ↗⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round drawn
   Gitleaks—none0/10

   Gitleaks is a CLI secret-scanning tool with no interactive API reference; probes explicitly show no llms.txt and no OpenAPI/swagger spec found on gitleaks.io, and evidence only documents CLI commands, not a runnable API playground.

   • [probe] “PROBE llms.txt: HTTP 404 at https://gitleaks.io/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://gitleaks.io/openapi.json, https://gitleaks.io/swagger.json, https://gitleaks.io/api/openapi.…”

   proof ↗⚑ flag

   Gecko Security—none0/10

   While Gecko exposes an OpenAPI spec (gecko-security-probe-3) and documents API capabilities (gecko-security-docs-10), there is no evidence of an interactive API reference UI with runnable/try-it examples for developers or AI agents to explore.

   • [probe] “PROBE openapi: HTTP 200 at https://gecko.security/openapi.json — contains "openapi" key”
   • [claimed-docs] “Gecko's v1 API lets you trigger scans, read scan, repository, and vulnerability data, triage findings, manage scan schedules, rotate your Gi…”

   proof ↗⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round to Gecko Security
   Gitleaks—none0/10

   Gitleaks is a CLI secret-scanning tool with no API/web service, and direct probes confirm no OpenAPI or machine-readable spec exists at any expected location.

   • [probe] “PROBE llms.txt: HTTP 404 at https://gitleaks.io/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://gitleaks.io/openapi.json, https://gitleaks.io/swagger.json, https://gitleaks.io/api/openapi.…”

   proof ↗⚑ flag

   Gecko Security✓fullprobed9/10

   A probe confirms a live OpenAPI spec at gecko.security/openapi.json (HTTP 200, contains 'openapi' key), and docs describe a full v1 API for scans, vulnerabilities, webhooks, and integrations. Missing for 10: no independent/community confirmation of the spec's completeness or usage beyond the vendor's own probe.

   • [probe] “PROBE openapi: HTTP 200 at https://gecko.security/openapi.json — contains "openapi" key”
   • [claimed-docs] “Gecko's v1 API lets you trigger scans, read scan, repository, and vulnerability data, triage findings, manage scan schedules, rotate your Gi…”

   proof ↗⚑ flag

3. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round to Gecko Security
   Gitleaks—none0/10

   Gitleaks is a CLI/CI secret-scanning tool with no evidence of a public/versioned API; probes for OpenAPI spec and llms.txt both returned 404s, and there's no mention of an API deprecation policy anywhere in the evidence.

   • [probe] “PROBE llms.txt: HTTP 404 at https://gitleaks.io/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://gitleaks.io/openapi.json, https://gitleaks.io/swagger.json, https://gitleaks.io/api/openapi.…”

   proof ↗⚑ flag

   Gecko Security~partialprobed3/10

   Gecko documents a versioned v1 API with an OpenAPI spec and a release/channel/version resolution endpoint (digest-pinned image refs), showing some notion of API versioning, but there is no documented deprecation policy, version sunset timeline, or migration guidance for API consumers. missing for 10: explicit deprecation policy, version support lifecycle/EOL dates, migration guides between API versions.

   • [claimed-docs] “Gecko's v1 API lets you trigger scans, read scan, repository, and vulnerability data, triage findings, manage scan schedules, rotate your Gi…”
   • [claimed-docs] “resolves a version to its release... the response includes the digest-pinned image_ref to pull”
   • [claimed-docs] “GET /releases/{channel}/{version} resolves a version to its release.”
   • [probe] “PROBE openapi: HTTP 200 at https://gecko.security/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round to Gitleaks
   Gitleaks~partialclaimed6/10

   Gitleaks natively scans across many items at once — entire directories/file trees via the `dir` command and full git commit history via `git log -p` with the `git` command, and gitleaks-action can scan all PRs/commits automatically in CI. However, there's no evidence of a broader batch/programmatic API for bulk operations beyond directory/repo scanning (e.g., processing many repos, bulk config management, or structured bulk output for agentic pipelines). Missing for 10: multi-repo/bulk-target orchestration, programmatic batch API beyond CLI file/dir args, and evidence of AI-native bulk workflows.

   • [github] “The `git` command lets you scan local git repos.”
   • [github] “The `git` command lets you scan local git repos. Under the hood, gitleaks uses the `git log -p` command to scan patches.”
   • [github] “The `dir` (aliases include `files`, `directory`) command lets you scan directories and files.”
   • [github] “The `dir` (aliases include `files`, `directory`) command lets you scan directories and files. Example: `gitleaks dir -v path_to_directory_or…”
   • [claimed-docs] “You can use it to automatically run a gitleaks scan on all your team's pull requests and commits, or run on-demand scans.”
   • [claimed-docs] “Enable **Gitleaks-Action** in your GitHub workflows to be alerted when secrets are leaked as soon as they happen.”

   proof ↗⚑ flag

   Gecko Security~partialclaimed5/10

   The v1 API and AI-tool integration let a user programmatically list repositories/scans, pull vulnerability data, triage findings, and trigger scans across many items, which supports scripted bulk-style automation, but there is no documented bulk-fix, bulk-triage, or multi-select UI action for operating on many findings/repos simultaneously. missing for 10: a dedicated bulk-action endpoint or UI (e.g., bulk fix/triage/dismiss across many findings at once), independent evidence of bulk workflows in practice.

   • [claimed-docs] “Connect it to an AI tool and the tool can list your repositories and scans, pull full vulnerability evidence (proof of concept, call chain, …”
   • [claimed-docs] “Gecko's v1 API lets you trigger scans, read scan, repository, and vulnerability data, triage findings, manage scan schedules, rotate your Gi…”
   • [claimed-docs] “Gecko can push events to your systems as scans run and findings change: page a channel when a scan fails, open a workflow when a critical la…”

   proof ↗⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round drawn
   Gitleaks~partialclaimed5/10

   Gitleaks supports custom detection rules (regex-based) and can trigger automatic actions on events—pre-commit hook blocks commits containing secrets, and gitleaks-action runs on GitHub push/PR events to alert accounts and comment on PRs. However this is limited to secret-scanning triggers tied to git/CI events, not a general-purpose rule/action automation engine. Missing for 10: evidence of arbitrary event types or custom action definitions beyond GitHub-specific alerting/commenting, and no AI-native/agentic trigger framework.

   • [github] “You can run Gitleaks as a pre-commit hook by copying the example `pre-commit.py` script into your `.git/hooks/` directory.”
   • [github] “Gitleaks offers a configuration format you can follow to write your own secret detection rules”
   • [claimed-docs] “Enable **Gitleaks-Action** in your GitHub workflows to be alerted when secrets are leaked as soon as they happen.”
   • [claimed-docs] “A list of GitHub accounts that should be alerted when **gitleaks-action** detects a leak.”
   • [claimed-docs] “**gitleaks-action** uses this token to call [a GitHub API] to comment on PRs.”
   • [github] “➜ git commit -m "this commit contains a secret" Detect hardcoded secrets.................................................Failed”

   proof ↗⚑ flag

   Gecko Security~partialclaimed5/10

   Gecko supports some event-driven automation—webhooks that fire on scan completion/finding changes, configurable fail-on-severity thresholds for PR checks, and automatic ticket/ PR creation on findings—but these are fixed, product-defined triggers rather than a user-configurable rules engine where arbitrary conditions map to arbitrary actions. missing for 10: a general-purpose rule/condition builder, support for chaining multiple custom actions per event, and evidence of user-defined logic beyond severity thresholds.

   • [claimed-docs] “Gecko can push events to your systems as scans run and findings change: page a channel when a scan fails, open a workflow when a critical la…”
   • [claimed-docs] “**Fail-on severity**: the severity threshold that fails the check (for example, fail on High and above).”
   • [claimed-docs] “create a ticket in Jira, Linear, ClickUp, or Shortcut”
   • [claimed-docs] “Click Request fix to open a gecko/* pull request with the patch applied, or apply the patch yourself.”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round to Gecko Security
   Gitleaks—none0/10

   Evidence shows Gitleaks integrates with git hooks and GitHub Actions triggered by commits/PRs, but nothing describes scheduling recurring/cron-based scans or workflows as a distinct capability. The axis applies (CI security tools commonly support scheduled scans) but no evidence confirms this for Gitleaks.

   ⚑ flag

   Gecko Security~partialclaimed4/10

   The v1 API reference states it lets you 'manage scan schedules,' implying recurring scan jobs can be configured programmatically, but there is no dedicated doc page, UI walkthrough, or example showing how to set cadence, or evidence this extends to broader 'workflows' beyond scanning. missing for 10: dedicated scheduling documentation/UI, example of setting recurring cadence, evidence of scheduling beyond scans (e.g., recurring triage/ticket workflows), independent confirmation it works as claimed.

   • [claimed-docs] “Gecko's v1 API lets you trigger scans, read scan, repository, and vulnerability data, triage findings, manage scan schedules, rotate your Gi…”

   proof ↗⚑ flag

Agent scanning

1. ai-native userHave an agent run a scan headlessly via the CLI, parse machine-readable results, and file issues for real findings

   weight 3 · round to Gitleaks
   Gitleaks~partialclaimed5/10

   Gitleaks CLI supports headless scanning of repos/dirs/stdin and can output baseline reports like findings.json, giving a machine-readable artifact an agent could parse; gitleaks-action also automates PR-based alerting. However there's no explicit documentation of a structured JSON/SARIF report flag, and no evidence of automated issue-filing (only PR comments/alerts to accounts, not issue tracker integration). Missing for 10: explicit machine-readable output format docs (e.g. --report-format json/sarif), and evidence of automated issue creation for real findings.

   • [github] “The `git` command lets you scan local git repos. Under the hood, gitleaks uses the `git log -p` command to scan patches.”
   • [github] “The `dir` (aliases include `files`, `directory`) command lets you scan directories and files. Example: `gitleaks dir -v path_to_directory_or…”
   • [github] “You can also stream data to gitleaks with the `stdin` command. Example: `cat some_file | gitleaks -v stdin`”
   • [github] “After running the detect command with the --baseline-path parameter, report output (findings.json) will only contain new issues.”
   • [claimed-docs] “Enable **Gitleaks-Action** in your GitHub workflows to be alerted when secrets are leaked as soon as they happen.”
   • [claimed-docs] “**gitleaks-action** uses this token to call [a GitHub API] to comment on PRs.”
   • [claimed-docs] “A list of GitHub accounts that should be alerted when **gitleaks-action** detects a leak.”

   proof ↗⚑ flag

   Gecko Security~partialcommunity4/10

   Gecko exposes a v1 API and webhooks that can trigger scans, pull machine-readable vulnerability data, triage findings, and file tickets in Jira/Linear/ClickUp/Shortcut, and an MCP/AI-tools connector for agents to do the same — satisfying the 'headless, parse, file issues' intent via API rather than a literal CLI. However, no dedicated CLI binary/command is documented anywhere in the evidence, and community reports raise concrete concerns about false positives (100% confidence findings that weren't real, missed real issues) undermining 'file issues for real findings'. Missing for 10: an actual CLI tool/subcommand documented, and independent confirmation that AI-driven ticket filing acts only on validated/real findings rather than the false positives community testers observed.

   • [claimed-docs] “Connect it to an AI tool and the tool can list your repositories and scans, pull full vulnerability evidence (proof of concept, call chain, …”
   • [claimed-docs] “Gecko's v1 API lets you trigger scans, read scan, repository, and vulnerability data, triage findings, manage scan schedules, rotate your Gi…”
   • [claimed-docs] “create a ticket in Jira, Linear, ClickUp, or Shortcut”
   • [claimed-docs] “Gecko can push events to your systems as scans run and findings change: page a channel when a scan fails, open a workflow when a critical la…”
   • [community] “Tool gave 100% confidence for two vulnerabilities (severity 9.4 and 6.5) that turned out not to be real.”
   • [community] “Uploaded a project (sydbox) to scan; took 10 minutes and found only one vulnerability, an 'RCE: IRC Message Command Execution Bypass' in an …”

   proof ↗⚑ flag

2. ai-native userWire the scanner into my coding agent so AI-generated code is scanned for issues before it lands

   weight 2 · round to Gecko Security
   Gitleaks~partialclaimed4/10

   Gitleaks offers generic mechanisms (pre-commit hook script, CLI `dir`/`git`/`stdin` scanning, CI action) that a user could wire into an AI coding agent's workflow to scan generated code before it lands, but there is no documented agent-specific integration (no MCP server, no Claude Code/Cursor plugin, no explicit guidance for AI-native pipelines). missing for 10: dedicated AI-agent integration docs, MCP/agent-hook examples, evidence of use specifically for AI-generated code review.

   • [github] “You can run Gitleaks as a pre-commit hook by copying the example `pre-commit.py` script into your `.git/hooks/` directory.”
   • [github] “You can also stream data to gitleaks with the `stdin` command. Example: `cat some_file | gitleaks -v stdin`”
   • [github] “The `dir` (aliases include `files`, `directory`) command lets you scan directories and files. Example: `gitleaks dir -v path_to_directory_or…”
   • [claimed-docs] “Enable **Gitleaks-Action** in your GitHub workflows to be alerted when secrets are leaked as soon as they happen.”

   proof ↗⚑ flag

   Gecko Security~partialprobed6/10

   Gecko documents an MCP/AI-tool integration that lets an agent list repos/scans, pull vulnerability evidence, triage findings, and file tickets, plus PR/CI checks that fail builds above a severity threshold — together enabling a coding-agent workflow to scan AI-generated code before merge. However, independent hands-on reports raise real accuracy concerns (false positives at 100% confidence, missed real bugs, UI/scan bugs), which undercuts confidence that the scanning is reliable enough for a pre-merge gate. Missing for 10: independent corroboration that the MCP/agent wiring works smoothly in practice, and evidence addressing the accuracy complaints specifically in an agent-driven pre-commit/pre-merge context.

   • [claimed-docs] “Connect it to an AI tool and the tool can list your repositories and scans, pull full vulnerability evidence (proof of concept, call chain, …”
   • [probe] “official MCP server documented at https://gecko.security/docs/ai-tools/overview”
   • [claimed-docs] “Gecko posts a pass/fail check back to GitHub or GitLab so reviewers see the security status inline.”
   • [claimed-docs] “**Fail-on severity**: the severity threshold that fails the check (for example, fail on High and above).”
   • [community] “Tool gave 100% confidence for two vulnerabilities (severity 9.4 and 6.5) that turned out not to be real.”
   • [community] “Ran Gecko on a C project after Semgrep AI flagged a minor real issue; Gecko found nothing. After removing the fix and recreating the project…”
   • [community] “Uploaded a project (sydbox) to scan; took 10 minutes and found only one vulnerability, an 'RCE: IRC Message Command Execution Bypass' in an …”

   proof ↗⚑ flag

Ci gates

1. devops-leadRun scans in CI on every pull request and fail the build on new findings via exit codes

   weight 3 · round drawn
   Gitleaks✓fullclaimed8/10

   Gitleaks-Action enables scanning on GitHub PR workflows with alerts/comments, and the CLI's detect command exits non-zero on findings (shown by failed commit hook example), which is the mechanism CI systems use to fail builds. missing for 10: explicit documentation of CI-specific exit code semantics (e.g., non-zero exit on new findings vs baseline) and non-GitHub CI examples (GitLab/Jenkins) beyond the GitHub Action.

   • [claimed-docs] “Enable **Gitleaks-Action** in your GitHub workflows to be alerted when secrets are leaked as soon as they happen.”
   • [claimed-docs] “You can use it to automatically run a gitleaks scan on all your team's pull requests and commits, or run on-demand scans.”
   • [github] “➜ git commit -m "this commit contains a secret" Detect hardcoded secrets.................................................Failed”
   • [github] “After running the detect command with the --baseline-path parameter, report output (findings.json) will only contain new issues.”
   • [github] “gitleaks will ignore any old findings that are present in the baseline”

   proof ↗⚑ flag

   Gecko Security✓fullclaimed8/10

   Docs describe PR-triggered scans that post a pass/fail check to GitHub/GitLab, with a configurable fail-on-severity threshold and separation of new vs pre-existing findings, which together enable failing a PR build on new findings. This matches the CI/PR-gating story closely, though it's implemented as a GitHub/GitLab check status rather than an explicit CLI exit code and lacks independent hands-on confirmation of build-failing behavior. Missing for 10: independent verification that the pass/fail check actually blocks merges/builds in practice, and explicit mention of CLI exit-code semantics for non-GitHub CI runners.

   • [claimed-docs] “Gecko posts a pass/fail check back to GitHub or GitLab so reviewers see the security status inline.”
   • [claimed-docs] “Findings introduced by the PR are separated from pre-existing ones, so reviewers focus on what the change adds.”
   • [claimed-docs] “**Fail-on severity**: the severity threshold that fails the check (for example, fail on High and above).”
   • [claimed-docs] “install the Gecko GitHub App and pick repositories”

   proof ↗⚑ flag

2. developerSee scan findings surfaced as pull-request comments or checks in GitHub or GitLab

   weight 2 · round drawn
   Gitleaks✓fullclaimed8/10

   Gitleaks-Action explicitly integrates into GitHub workflows and uses the GitHub API to post PR comments/reviews when secrets are detected, and it can also fail CI checks on findings; it's a well-documented first-party GitHub Action. Missing for 10: GitLab-specific MR comment/check integration is not evidenced (only GitHub is covered), and no independent/hands-on confirmation of the PR-comment behavior beyond vendor docs.

   • [claimed-docs] “Enable **Gitleaks-Action** in your GitHub workflows to be alerted when secrets are leaked as soon as they happen.”
   • [claimed-docs] “**gitleaks-action** uses this token to call [a GitHub API] to comment on PRs.”
   • [claimed-docs] “**gitleaks-action** uses this token to call [a GitHub API](https://octokit.github.io/rest.js/v18#pulls-create-review-comment) to comment on …”
   • [claimed-docs] “gitleaks-action uses this token to call a GitHub API to comment on PRs.”
   • [claimed-docs] “A list of GitHub accounts that should be alerted when **gitleaks-action** detects a leak.”
   • [claimed-docs] “Enable this **gitleaks-action** and copy `<img alt="gitleaks badge" src="https://img.shields.io/badge/protected%20by-gitleaks-blue">` to you…”

   proof ↗⚑ flag

   Gecko Security✓fullclaimed8/10

   Docs describe a GitHub/GitLab App integration that posts pass/fail checks and PR security review summaries, separates new vs pre-existing findings, supports fail-on-severity thresholds, and can auto-commit fixes to the PR — a fairly complete PR-check/comment workflow (gecko-security-docs-5, -19, -28, -29, -30). Missing for 10: independent/hands-on confirmation that PR comments/checks actually render as described (community evidence only discusses finding accuracy, not the PR-check UX itself).

   • [claimed-docs] “Gecko posts a pass/fail check back to GitHub or GitLab so reviewers see the security status inline.”
   • [claimed-docs] “PR reviews & fixes: On pull requests, a security review summary and one-click fixes.”
   • [claimed-docs] “Findings introduced by the PR are separated from pre-existing ones, so reviewers focus on what the change adds.”
   • [claimed-docs] “**Fail-on severity**: the severity threshold that fails the check (for example, fail on High and above).”
   • [claimed-docs] “Commit to an existing PR: For findings from a PR scan, Gecko can commit the fix directly to the PR's head branch so the fix rides along with…”

   proof ↗⚑ flag

Pre commit

1. developerRun the scanner as a pre-commit hook so secrets and issues never enter my git history

   weight 3 · round to Gitleaks
   Gitleaks✓fullclaimed8/10

   Gitleaks documents running as a pre-commit hook via the example pre-commit.py script copied into .git/hooks, and demonstrates it blocking a commit containing a secret ("git commit ... Detect hardcoded secrets.................................................Failed"), confirming secrets are caught before entering history. Missing for 10: no mention of official pre-commit-framework (.pre-commit-hooks.yaml) integration or independent hands-on confirmation beyond the vendor repo.

   • [github] “You can run Gitleaks as a pre-commit hook by copying the example `pre-commit.py` script into your `.git/hooks/` directory.”
   • [github] “➜ git commit -m "this commit contains a secret" Detect hardcoded secrets.................................................Failed”
   • [github] “Detect hardcoded secrets.................................................Failed”

   proof ↗⚑ flag

   Gecko Security—none0/10

   Gecko's documented workflow is GitHub App/PR-based scanning with pass/fail PR checks, not a local pre-commit git hook that blocks commits before they enter history — no evidence of a pre-commit hook, CLI hook script, or local git-hook integration exists in the evidence pack.

   ⚑ flag

Coverage

1. developerScan projects across all the major languages and package ecosystems my organization uses

   weight 2 · round to Gitleaks
   Gitleaks~partialclaimed6/10

   Gitleaks scans git repos, directories/files, and stdin using regex-based pattern matching, which is inherently language-agnostic and works on any text-based source file or config regardless of the language or package ecosystem in use. However, there is no explicit evidence of ecosystem-specific coverage claims, testing across specific language/package manager formats, or documentation asserting broad multi-language validation. missing for 10: explicit language/ecosystem coverage claims, evidence of testing across specific ecosystems (npm, pip, maven, etc.), independent corroboration of coverage breadth.

   • [github] “The `git` command lets you scan local git repos.”
   • [github] “The `dir` (aliases include `files`, `directory`) command lets you scan directories and files.”
   • [github] “You can also stream data to gitleaks with the `stdin` command.”
   • [github] “Gitleaks is a tool for detecting secrets like passwords, API keys, and tokens in git repos, files, and whatever else you wanna throw at it v…”
   • [github] “The `dir` (aliases include `files`, `directory`) command lets you scan directories and files. Example: `gitleaks dir -v path_to_directory_or…”
   • [github] “You can also stream data to gitleaks with the `stdin` command. Example: `cat some_file | gitleaks -v stdin`”

   proof ↗⚑ flag

   Gecko Security~partialcommunity5/10

   Docs list a defined set of 'compiler-accurate' languages (TypeScript, JavaScript, Python, Go, Java, Scala, C#, Rust) supporting cross-file analysis, but there is no mention of package/dependency-ecosystem scanning (npm, pip, Maven, Cargo, etc.) or of broader language coverage (C/C++, Ruby, PHP, Kotlin, Swift). Community testing on a C project (unsupported language) found nothing, reinforcing that coverage is limited to the stated language list rather than 'all major languages and ecosystems.' Missing for 10: explicit package/dependency-ecosystem scanning support, broader language list, and independent verification of coverage breadth.

   • [claimed-docs] “Compiler-accurate (precise cross-file analysis) | TypeScript · JavaScript · Python · Go · Java · Scala · C# · Rust”
   • [community] “Ran Gecko on a C project after Semgrep AI flagged a minor real issue; Gecko found nothing. After removing the fix and recreating the project…”

   proof ↗⚑ flag

Output formats

1. developerEmit scan results in machine-readable formats like JSON or SARIF for downstream tooling

   weight 2 · round to Gitleaks
   Gitleaks~partialclaimed5/10

   Evidence shows Gitleaks writes findings to a JSON report file (e.g., findings.json via --baseline-path) confirming JSON output support, but there is no mention in the evidence pack of SARIF or other machine-readable formats. missing for 10: explicit SARIF output support, documentation of --report-format flag or other structured formats, independent confirmation of downstream tooling integration.

   • [github] “After running the detect command with the --baseline-path parameter, report output (findings.json) will only contain new issues.”
   • [github] “gitleaks will ignore any old findings that are present in the baseline”

   proof ↗⚑ flag

   Gecko Security~partialprobed4/10

   Gecko's v1 API lets developers read scan, repository, and vulnerability data programmatically (implying JSON responses) and an OpenAPI spec is published, but there is no explicit documentation of a SARIF export format or dedicated 'JSON report' output for CI pipelines. Missing for 10: explicit SARIF format support, documented JSON report export command, and any CI-integration example showing machine-readable output being consumed downstream.

   • [claimed-docs] “Gecko's v1 API lets you trigger scans, read scan, repository, and vulnerability data, triage findings, manage scan schedules, rotate your Gi…”
   • [probe] “PROBE openapi: HTTP 200 at https://gecko.security/openapi.json — contains "openapi" key”
   • [claimed-docs] “Gecko can push events to your systems as scans run and findings change: page a channel when a scan fails, open a workflow when a critical la…”

   proof ↗⚑ flag

1. ai-native userRead the product's source under an open license

   weight 2 · round to Gitleaks
   Gitleaks✓fullprobed7/10

   Gitleaks' source code is openly hosted and directly referenced across many citations (e.g. gitleaks-gh-1, gitleaks-probe-3), confirming it is a publicly readable GitHub repository that anyone, including AI-native users, can inspect. However, the evidence pack never explicitly cites a license file or license name (e.g. MIT), so full confirmation of an 'open license' designation is inferred rather than directly documented. Missing for 10: an explicit license statement/citation (e.g. LICENSE file content) and independent corroboration of the license terms.

   • [github] “The `git` command lets you scan local git repos.”
   • [probe] “official CLI documented at https://github.com/gitleaks/gitleaks”
   • [github] “Gitleaks can be installed using Homebrew, Docker, or Go.”

   proof ↗⚑ flag

   Gecko Security—none0/10

   No evidence that Gecko Security's source code is published or licensed openly; it is a proprietary SaaS/security scanning product with documented APIs and hybrid deployment, but nothing indicates its codebase is open source.

   ⚑ flag

2. ai-native userSelf-host the core product

   weight 3 · round to Gitleaks
   Gitleaks✓fullclaimed8/10

   Gitleaks is a fully open-source CLI (installable via Homebrew, Docker, or Go) that runs entirely locally against git repos, directories, or stdin, requiring no cloud service — a clear self-hostable core product. Missing for 10: no explicit self-hosting deployment guide (e.g., server/container orchestration docs) beyond basic install instructions.

   • [github] “Gitleaks can be installed using Homebrew, Docker, or Go.”
   • [github] “The `git` command lets you scan local git repos.”
   • [github] “The `dir` (aliases include `files`, `directory`) command lets you scan directories and files.”
   • [github] “You can also stream data to gitleaks with the `stdin` command.”
   • [github] “Gitleaks is a tool for detecting secrets like passwords, API keys, and tokens in git repos, files, and whatever else you wanna throw at it v…”

   proof ↗⚑ flag

   Gecko Security~partialclaimed6/10

   Docs confirm a 'hybrid' deployment where the scanner, S3 storage, and AI inference all run inside the customer's AWS account, and the pricing page lists an 'On-prem / self-hosted / private cloud' tier — both indicating genuine self-hosting options exist. However, the same hybrid docs state Gecko still hosts the dashboard, database, and scan orchestration, so the core control plane is not actually self-hostable in the standard offering, and no architecture/setup docs for the full on-prem tier are provided. Missing for 10: detailed on-prem deployment guide/architecture for the fully self-hosted tier, and confirmation that dashboard/orchestration can also run on customer infrastructure.

   • [claimed-docs] “the scanner, S3 storage, and all AI inference run inside your AWS account. Gecko hosts only the dashboard, database, and scan orchestration.”
   • [claimed-docs] “the scanner, S3 storage, and all AI inference run inside your AWS account.”
   • [claimed-docs] “Unlimited scanning * On-prem / self-hosted / private cloud”

   proof ↗⚑ flag

1. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   Gitleaks—none0/10

   No evidence in the pack addresses telemetry collection or an opt-out mechanism for Gitleaks or gitleaks-action; the docs cover scanning commands, CI integration, and config but never mention data collection or privacy controls.

   ⚑ flag

   Gecko Security—none0/10

   No evidence anywhere in the pack of a telemetry/usage-tracking opt-out setting, privacy policy control, or data-collection toggle; the docs focus on scanning, PR fixes, API keys, and deployment but never mention telemetry opt-out.

   ⚑ flag

Custom rules

1. security-engineerWrite custom static-analysis rules in a simple syntax and share them across repositories

   weight 2 · round to Gitleaks
   Gitleaks~partialclaimed7/10

   Gitleaks documents a TOML-based config format for writing custom secret-detection rules, including composite rules and allowlists, and this config can be centralized as a `gitleaks.toml` or referenced via `GITLEAKS_CONFIG` so it can be reused across repos (e.g. gitleaks-action auto-detecting it). This is more of a config-file sharing mechanism than a purpose-built 'rule sharing' feature, and there's no independent corroboration of ease-of-use or a rule marketplace/registry. Missing for 10: independent hands-on evidence of rule syntax simplicity, evidence of a shared rule registry/marketplace, and confirmation of seamless cross-repo rule versioning.

   • [github] “Gitleaks offers a configuration format you can follow to write your own secret detection rules”
   • [github] “Gitleaks introduced composite rules, which are made up of a single "primary" rule and one or more auxiliary or `required` rules.”
   • [github] “In v8.28.0 Gitleaks introduced composite rules, which are made up of a single "primary" rule and one or more auxiliary or `required` rules.”
   • [github] “You can define multiple allowlists for a rule to reduce false positives. A finding will be ignored if _ANY_ [[rules.allowlists]] matches.”
   • [claimed-docs] “You can use `GITLEAKS_CONFIG` to explicitly set a config path _or_ create a `gitleaks.toml` at the root of the repo which will be automatica…”
   • [claimed-docs] “you can use GITLEAKS_CONFIG to explicitly set a config path or create a gitleaks.toml at the root of the repo which will be automatically de…”

   proof ↗⚑ flag

   Gecko Security—none0/10

   Gecko Security is an AI-driven vulnerability scanner using compiler-accurate cross-file analysis, not a rule-based SAST engine; there is no evidence of a custom rule-writing syntax (e.g., YAML/DSL rules like Semgrep) or any mechanism to define and share such rules across repositories.

   • [claimed-docs] “Compiler-accurate (precise cross-file analysis) | TypeScript · JavaScript · Python · Go · Java · Scala · C# · Rust”
   • [claimed-docs] “Repository wiki: An AI-written map of your app: architecture, routing, and security model.”

   proof ↗⚑ flag

Fix suggestions

1. developerApply suggested or automatic code fixes for findings instead of only reading reports

   weight 2 · round to Gecko Security
   Gitleaks—none0/10

   Gitleaks is purely a secret-detection tool that reports findings (via CLI, git hooks, or gitleaks-action PR comments); no evidence anywhere in the pack of suggested or automatic remediation/fixes for detected secrets—only detection, alerting, allowlisting, and baseline suppression are described.

   • [github] “Gitleaks is a tool for detecting secrets like passwords, API keys, and tokens in git repos, files, and whatever else you wanna throw at it v…”
   • [github] “You can define multiple allowlists for a rule to reduce false positives. A finding will be ignored if _ANY_ [[rules.allowlists]] matches.”
   • [claimed-docs] “Enable **Gitleaks-Action** in your GitHub workflows to be alerted when secrets are leaked as soon as they happen.”
   • [github] “After running the detect command with the --baseline-path parameter, report output (findings.json) will only contain new issues.”

   proof ↗⚑ flag

   Gecko Security✓fullclaimed8/10

   Docs describe a full remediation loop: suggested patches with 'Request fix' opening a gecko/* PR, ability to commit fixes directly to an existing PR's head branch, and automatic re-scan marking 'Fix verified' once resolved — this goes beyond read-only reporting into applied/automatic fixes. missing for 10: independent/hands-on confirmation that generated fixes actually work correctly (community evidence focuses on detection false positives, not fix application quality).

   • [claimed-docs] “Click Request fix to open a gecko/* pull request with the patch applied, or apply the patch yourself.”
   • [claimed-docs] “Gecko rechecks the finding and marks it Fix verified once the vulnerability is gone.”
   • [claimed-docs] “Commit to an existing PR: For findings from a PR scan, Gecko can commit the fix directly to the PR's head branch so the fix rides along with…”
   • [claimed-docs] “PR reviews & fixes: On pull requests, a security review summary and one-click fixes.”
   • [claimed-docs] “Click **Request fix** to open a `gecko/*` pull request with the patch applied, or apply the patch yourself.”
   • [claimed-docs] “When the fix merges, Gecko rechecks the finding and marks it **Fix verified** once the vulnerability is gone.”

   proof ↗⚑ flag

Custom detection

1. security-engineerDefine custom detection rules for my organization's internal token and secret formats

   weight 2 · round to Gitleaks
   Gitleaks✓fullclaimed8/10

   Gitleaks documents a configuration format for writing custom secret-detection rules, plus advanced features like composite rules and allowlists to reduce false positives, directly enabling org-specific token/secret pattern definitions. Missing for 10: no independent hands-on example of a custom rule being validated in production, and no dedicated deep-dive docs beyond the config-format mention.

   • [github] “Gitleaks offers a configuration format you can follow to write your own secret detection rules”
   • [github] “Gitleaks introduced composite rules, which are made up of a single "primary" rule and one or more auxiliary or `required` rules.”
   • [github] “In v8.28.0 Gitleaks introduced composite rules, which are made up of a single "primary" rule and one or more auxiliary or `required` rules.”
   • [github] “You can define multiple allowlists for a rule to reduce false positives. A finding will be ignored if _ANY_ [[rules.allowlists]] matches.”
   • [github] “Gitleaks introduced composite rules, which are made up of a single "primary" rule and one or more auxiliary or required rules.”

   proof ↗⚑ flag

   Gecko Security—none0/10

   Gecko Security is a vulnerability-scanning tool focused on code security review (SAST-style findings, PR checks, fixes), and none of the evidence mentions custom secret/token pattern detection rules or any mechanism for defining organization-specific secret formats.

   ⚑ flag

Secret scanning

1. developerScan a repository and its full git history for hardcoded secrets and credentials

   weight 3 · round to Gitleaks
   Gitleaks✓fullclaimed9/10

   Gitleaks' `git` command explicitly scans full git history via `git log -p`, and `dir`/`stdin` commands cover directory/file/stdin scanning for secrets like passwords, API keys, and tokens, with hands-on example output showing detection working. missing for 10: no independent third-party benchmark of detection accuracy across large real-world repos.

   • [github] “The `git` command lets you scan local git repos. Under the hood, gitleaks uses the `git log -p` command to scan patches.”
   • [github] “The `git` command lets you scan local git repos.”
   • [github] “Gitleaks is a tool for detecting secrets like passwords, API keys, and tokens in git repos, files, and whatever else you wanna throw at it v…”
   • [github] “➜ git commit -m "this commit contains a secret" Detect hardcoded secrets.................................................Failed”
   • [github] “The `dir` (aliases include `files`, `directory`) command lets you scan directories and files. Example: `gitleaks dir -v path_to_directory_or…”

   proof ↗⚑ flag

   Gecko Security—none0/10

   Gecko's documented capability is AI-driven vulnerability discovery (source-to-sink call chains, CVSS scoring, PoCs, patches) for application code, not secret/credential scanning or git-history scanning. Missing for 10: any mention of secret/credential detection, hardcoded key scanning, or scanning git commit history for leaked secrets.

   • [claimed-docs] “Each finding includes a severity (CVSS 4.0), a confidence score, the full source-to-sink call chain, a proof of concept, and a suggested pat…”
   • [claimed-docs] “Repository wiki: An AI-written map of your app: architecture, routing, and security model.”
   • [claimed-docs] “Compiler-accurate (precise cross-file analysis) | TypeScript · JavaScript · Python · Go · Java · Scala · C# · Rust”
   • [probe] “PROBE llms.txt: HTTP 200 at https://gecko.security/llms.txt # Gecko Security > Gecko Security is an AI security engineer that finds exploit…”

   proof ↗⚑ flag

Ai triage

1. ai-native userUse AI to triage findings — explaining them, deduplicating, and flagging likely false positives

   weight 3 · round to Gecko Security
   Gitleaks—none0/10

   No evidence of any AI-based triage, explanation, deduplication, or false-positive flagging feature; Gitleaks only offers manual allowlists, baselines, and composite rules for reducing noise, none of which use AI.

   • [github] “You can define multiple allowlists for a rule to reduce false positives. A finding will be ignored if _ANY_ [[rules.allowlists]] matches.”
   • [github] “When using a baseline, gitleaks will ignore any old findings that are present in the baseline.”
   • [github] “After running the detect command with the --baseline-path parameter, report output (findings.json) will only contain new issues.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://gitleaks.io/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://gitleaks.io/openapi.json, https://gitleaks.io/swagger.json, https://gitleaks.io/api/openapi.…”

   proof ↗⚑ flag

   Gecko Security!disputedcontradicted4/10

   Docs describe confidence scores, severity, call chains, and PR-introduced vs pre-existing separation, plus an AI-tools API explicitly for triaging findings (gecko-security-docs-2, -9, -28), which maps to explaining/deduplicating/flagging false positives. However, hands-on community reports directly contradict the false-positive flagging claim: the tool assigned 100% confidence to two non-existent vulnerabilities and flagged an implausible 'RCE' in a CTF IRC bot script as high severity, while missing a real issue found by another scanner (gecko-security-comm-3, gecko-security-comm-5, gecko-security-comm-4). Missing for 10: independent validation that confidence scoring reliably suppresses false positives, and resolution of the reported inaccurate high-confidence findings.

   • [claimed-docs] “Each finding includes a severity (CVSS 4.0), a confidence score, the full source-to-sink call chain, a proof of concept, and a suggested pat…”
   • [claimed-docs] “Connect it to an AI tool and the tool can list your repositories and scans, pull full vulnerability evidence (proof of concept, call chain, …”
   • [claimed-docs] “Findings introduced by the PR are separated from pre-existing ones, so reviewers focus on what the change adds.”
   • [community] “Tool gave 100% confidence for two vulnerabilities (severity 9.4 and 6.5) that turned out not to be real.”
   • [community] “Uploaded a project (sydbox) to scan; took 10 minutes and found only one vulnerability, an 'RCE: IRC Message Command Execution Bypass' in an …”
   • [community] “Ran Gecko on a C project after Semgrep AI flagged a minor real issue; Gecko found nothing. After removing the fix and recreating the project…”

   proof ↗⚑ flag

Fp management

1. security-engineerBaseline or ignore existing and false-positive findings so only new issues alert

   weight 3 · round to Gitleaks
   Gitleaks✓fullclaimed8/10

   Gitleaks explicitly supports baseline files via --baseline-path so only new findings appear in reports, and allowlists let users suppress known false positives per-rule. This directly matches the triage-noise story of ignoring existing/false-positive findings so only new issues alert. Missing for 10: no evidence of a centralized/dashboard-based suppression workflow or independent third-party validation of baseline accuracy at scale.

   • [github] “When using a baseline, gitleaks will ignore any old findings that are present in the baseline.”
   • [github] “After running the detect command with the --baseline-path parameter, report output (findings.json) will only contain new issues.”
   • [github] “gitleaks will ignore any old findings that are present in the baseline”
   • [github] “You can define multiple allowlists for a rule to reduce false positives. A finding will be ignored if _ANY_ [[rules.allowlists]] matches.”

   proof ↗⚑ flag

   Gecko Security~partialcommunity6/10

   Docs show PR scans separate pre-existing findings from new ones so reviewers focus on what changed (docs-28), and the API supports 'triage findings' (docs-10), implying some noise-reduction workflow. However, there's no explicit documentation of a false-positive marking/ignore mechanism or a persistent baseline snapshot feature, and community reports flag inaccurate high-confidence findings (comm-3) without confirming a suppression workflow exists. missing for 10: explicit 'mark as false positive'/dismiss UI, documented baseline snapshotting across scans, independent confirmation that dismissed findings stay suppressed on rescans.

   • [claimed-docs] “Findings introduced by the PR are separated from pre-existing ones, so reviewers focus on what the change adds.”
   • [claimed-docs] “Gecko's v1 API lets you trigger scans, read scan, repository, and vulnerability data, triage findings, manage scan schedules, rotate your Gi…”
   • [claimed-docs] “create a ticket in Jira, Linear, ClickUp, or Shortcut”
   • [community] “Tool gave 100% confidence for two vulnerabilities (severity 9.4 and 6.5) that turned out not to be real.”

   proof ↗⚑ flag

2. developerFilter and gate on findings by severity or confidence so low-value noise does not block builds

   weight 2 · round to Gecko Security
   Gitleaks—none0/10

   Gitleaks evidence shows allowlists to suppress false positives and baseline diffing to ignore old findings, but there is no mention of a severity or confidence scoring/classification system, nor any flag to gate builds based on such levels. This axis is a fair ask for a secret-scanning tool but the evidence pack shows no severity/confidence triage mechanism.

   • [github] “You can define multiple allowlists for a rule to reduce false positives. A finding will be ignored if _ANY_ [[rules.allowlists]] matches.”
   • [github] “When using a baseline, gitleaks will ignore any old findings that are present in the baseline.”
   • [github] “After running the detect command with the --baseline-path parameter, report output (findings.json) will only contain new issues.”

   proof ↗⚑ flag

   Gecko Security~partialclaimed6/10

   Docs confirm a 'fail-on severity' threshold for PR checks (e.g., fail on High and above) and that findings carry both severity and confidence scores, supporting build-gating by severity. However, there's no documented mechanism to gate/filter specifically by confidence score, only severity threshold is described as configurable. Missing for 10: explicit confidence-based filtering/gating controls, and independent verification that severity gating reliably suppresses low-value noise.

   • [claimed-docs] “Each finding includes a severity (CVSS 4.0), a confidence score, the full source-to-sink call chain, a proof of concept, and a suggested pat…”
   • [claimed-docs] “**Fail-on severity**: the severity threshold that fails the check (for example, fail on High and above).”
   • [claimed-docs] “Findings introduced by the PR are separated from pre-existing ones, so reviewers focus on what the change adds.”

   proof ↗⚑ flag