Semgrep vs Trivy

Agent access

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

   weight 2 · round to Semgrep
   Semgrep✓fullprobed8/10

   Semgrep hosts a working llms.txt at docs.semgrep.dev/llms.txt (HTTP 200, confirmed by probe) plus per-page .md agent-friendly docs (e.g. semgrep-docs-49, semgrep-docs-50), showing an agent can be pointed directly at machine-readable docs. missing for 10: independent/community confirmation that agents actually consume this llms.txt successfully, and no evidence of a broader agent-oriented docs index beyond the single llms.txt file.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.semgrep.dev/llms.txt # Semgrep ## Home - [Semgrep Docs](https://docs.semgrep.dev/index.md): Get s…”
   • [claimed-docs] “scan your first project, which can be any codebase, repository, or folder within a monorepo, for security issues, and view your findings”
   • [claimed-docs] “You can run local Semgrep CLI scans with the Semgrep command-line tool.”
   • [probe] “official CLI documented at https://docs.semgrep.dev/getting-started/cli”

   proof ↗⚑ flag

   Trivy—none0/10

   Probes confirm no llms.txt exists (404) and no agent-oriented docs format is available; while an MCP server exists (separate axis), there's no evidence of llms.txt or agent-native documentation being served.

   • [probe] “PROBE llms.txt: HTTP 404 at https://trivy.dev/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://trivy.dev/docs/latest/guide/.md”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Semgrep✓fullcommunity9/10

   Semgrep has a well-documented CLI (`semgrep ci`, `semgrep scan`) designed for headless/CI use, with dedicated CI provider integrations, pre-commit hooks, SARIF export, no-login/dry-run modes, and an API for programmatic access to findings—clearly supporting automated, non-interactive pipelines. Independent evidence (Zulip, Microsoft SARIF+LLM triage pipeline) confirms real-world CI/automation usage at scale. Missing for 10: no first-party benchmark of CI runtime performance at scale beyond anecdotal community complaints about slowness.

   • [claimed-docs] “navigate to the root of your project, and run your first scan: semgrep ci”
   • [claimed-docs] “This guide walks you through creating a Semgrep job in the following CI providers, which are explicitly supported in Semgrep AppSec Platform”
   • [claimed-docs] “your development cycle benefits from the automated scanning of repositories at various events, such as: Push events; Pull requests or merge …”
   • [claimed-docs] “Semgrep is integrated into CI environments by creating a **job** that is run by the CI provider. After a scan, findings are sent to Semgrep …”
   • [claimed-docs] “The pre-commit framework can run semgrep when you commit changes. This is helpful in preventing secrets and security issues from leaking int…”
   • [claimed-docs] “The `--dry-run` flag ensures that your scans are not uploaded to the Semgrep web app.”
   • [claimed-docs] “You do **not** need to be logged in to run a scan.”
   • [claimed-docs] “To export the results to a SARIF file: semgrep ci --sarif --sarif-output=semgrep.sarif”
   • [claimed-docs] “Semgrep AppSec Platform provides an API that enables you to list deployments, gather findings created by Semgrep”
   • [community] “Built a tool using Semgrep's SARIF output plus prompted LLMs to help prioritize triage; used at Microsoft for the past year to help surface …”
   • [community] “We've used Semgrep for Zulip's Python codebase for months and really appreciate the semantic checks, especially for security lint rules - it…”

   proof ↗⚑ flag

   Trivy✓fullprobed9/10

   Trivy is a CLI-first tool distributed via brew/docker/binary with commands like `trivy image`, `trivy k8s --report summary`, designed for scripted/automated scanning, and community evidence confirms it's widely integrated into CI/CD pipelines ('super easy to integrate in every ci/cd pipeline', 'very easy to write automation around'). Missing for 10: no first-party CI-specific docs (e.g., GitHub Actions integration guide) cited in the pack, though community corroboration is strong.

   • [github] “trivy k8s --report summary cluster”
   • [github] “Trivy is available in most common distribution channels. ... `brew install trivy` ... `docker run aquasec/trivy`”
   • [community] “I've had a great experience with Trivy, very solid tool, very easy to write automation around.”
   • [community] “we use AquaSec and it's absolutely the same engine. Trivy is so good we were tempted to drop AquaSec entirely as we only use it in our CI an…”
   • [community] “it's super easy to integrate in every ci/cd pipeline”
   • [probe] “official CLI documented at https://github.com/aquasecurity/trivy”

   proof ↗⚑ flag

3. ai-native userConnect an agent via an official MCP server

   weight 3 · round to Trivy
   Semgrep✓fullprobed6/10

   Semgrep is not itself an agent, so a first-party MCP server for connecting external agents is a fair axis, and evidence confirms one exists at docs.semgrep.dev/mcp. However, the evidence pack only shows the URL's existence via a probe with no detail on the tools/capabilities exposed or independent corroboration. Missing for 10: detailed documentation of what MCP tools/resources are exposed, setup instructions, and independent/hands-on confirmation of usage.

   • [probe] “official MCP server documented at https://docs.semgrep.dev/mcp”

   proof ↗⚑ flag

   Trivy✓fullprobed8/10

   Trivy ships an official trivy-mcp plugin that starts a Model Context Protocol server integrating Trivy's scanning with VS Code and other MCP-enabled tools, enabling natural-language security queries — directly matching the story. Missing for 10: independent/hands-on third-party corroboration of the MCP server's reliability beyond vendor docs.

   • [claimed-docs] “This plugin starts a Model Context Protocol (MCP) server that integrates Trivy's security scanning capabilities with VS Code and other MCP-e…”
   • [claimed-docs] “Natural Language Scanning: Ask questions about security issues in natural language”
   • [claimed-docs] “**Natural Language Scanning**: Ask questions about security issues in natural language”
   • [probe] “official MCP server documented at https://github.com/aquasecurity/trivy-mcp”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round drawn
   Semgrep✓fullprobed8/10

   Semgrep ships a well-documented, installable official CLI (pipx/uv install, `semgrep scan`/`semgrep ci`, SARIF export, autofix, dry-run, no-login mode) that is fully scriptable and thus usable by AI agents, and this is corroborated by community usage reports and a dedicated probe confirming the CLI docs page. Missing for 10: explicit documentation of machine-readable (e.g., JSON) output tailored for programmatic/agent consumption and independent evidence of AI agents specifically driving the CLI.

   • [claimed-docs] “pipx install semgrep # preferred: install through uv (https://docs.astral.sh/uv/) uv tool install semgrep”
   • [claimed-docs] “semgrep scan - This is the recommended command for scanning local codebases or scanning a project when you don't have a Semgrep account”
   • [claimed-docs] “navigate to the root of your project, and run your first scan: semgrep ci”
   • [claimed-docs] “The `--dry-run` flag ensures that your scans are not uploaded to the Semgrep web app.”
   • [claimed-docs] “You do **not** need to be logged in to run a scan.”
   • [claimed-docs] “To export the results to a SARIF file: semgrep ci --sarif --sarif-output=semgrep.sarif”
   • [probe] “official CLI documented at https://docs.semgrep.dev/getting-started/cli”
   • [community] “We've used Semgrep for Zulip's Python codebase for months and really appreciate the semantic checks, especially for security lint rules - it…”

   proof ↗⚑ flag

   Trivy✓fullprobed8/10

   Trivy is fundamentally shipped as an official CLI (trivy image, trivy fs, trivy k8s, trivy aws) distributed via brew/docker/github release, and community reports confirm it is easy to script and integrate into CI/CD pipelines. Missing for 10: dedicated independent benchmarking of CLI ergonomics for AI-agent use cases and any first-party AI-specific CLI flags (the AI-native/natural-language angle is handled by the separate MCP server, not the core CLI itself).

   • [github] “trivy k8s --report summary cluster”
   • [github] “Trivy is available in most common distribution channels. ... `brew install trivy` ... `docker run aquasec/trivy`”
   • [probe] “official CLI documented at https://github.com/aquasecurity/trivy”
   • [claimed-docs] “It detects known vulnerabilities in your container image... `$ trivy image [YOUR_IMAGE_NAME]`”
   • [community] “I've had a great experience with Trivy, very solid tool, very easy to write automation around.”
   • [community] “it's super easy to integrate in every ci/cd pipeline”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Semgrep~partialprobed6/10

   Semgrep AppSec Platform documents a public API for listing deployments, findings, and projects, and the CLI itself is scriptable for automation, but there is no OpenAPI/swagger spec discoverable (probe returned 404s on all candidate paths) and no independent/community corroboration of programmatic API usage. missing for 10: discoverable OpenAPI/schema documentation, broader API surface details (write operations, rate limits), and independent evidence of third-party integrations built against the API.

   • [claimed-docs] “Semgrep AppSec Platform provides an API that enables you to list deployments, gather findings created by Semgrep AppSec Platform, and list p…”
   • [claimed-docs] “Semgrep AppSec Platform provides an API that enables you to list deployments, gather findings created by Semgrep”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.semgrep.dev/openapi.json, https://docs.semgrep.dev/swagger.json, https://docs.semgrep.d…”

   proof ↗⚑ flag

   Trivy~partialprobed6/10

   Trivy exposes a documented CLI and an official MCP server (trivy-mcp) that explicitly targets AI-agent/natural-language driving of scans, which fits the agenticness/AI-native story. However, probes confirm no OpenAPI/REST API or machine-readable API spec (openapi.json, swagger.json all 404) and no llms.txt, so there's no general-purpose documented public API beyond the CLI/MCP surface. Missing for 10: a formal OpenAPI/REST API spec, broader API documentation beyond MCP, and independent confirmation of MCP server reliability/adoption.

   • [claimed-docs] “Natural Language Scanning: Ask questions about security issues in natural language”
   • [claimed-docs] “**Natural Language Scanning**: Ask questions about security issues in natural language”
   • [claimed-docs] “This plugin starts a Model Context Protocol (MCP) server that integrates Trivy's security scanning capabilities with VS Code and other MCP-e…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://trivy.dev/openapi.json, https://trivy.dev/swagger.json, https://trivy.dev/api/openapi.json, …”
   • [probe] “official MCP server documented at https://github.com/aquasecurity/trivy-mcp”
   • [probe] “PROBE llms.txt: HTTP 404 at https://trivy.dev/llms.txt”
   • [github] “Trivy is available in most common distribution channels. ... `brew install trivy` ... `docker run aquasec/trivy`”

   proof ↗⚑ flag

6. ai-native userBuild against official SDKs

   weight 2 · round drawn
   Semgrep—none0/10

   The evidence shows Semgrep offers a CLI, a REST API for the AppSec Platform, and an MCP server, but nowhere is an official client SDK (e.g., Python/JS/Go library for programmatic integration) documented or referenced.

   • [claimed-docs] “Semgrep AppSec Platform provides an API that enables you to list deployments, gather findings created by Semgrep AppSec Platform, and list p…”
   • [claimed-docs] “Semgrep AppSec Platform provides an API that enables you to list deployments, gather findings created by Semgrep”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.semgrep.dev/openapi.json, https://docs.semgrep.dev/swagger.json, https://docs.semgrep.d…”
   • [probe] “official CLI documented at https://docs.semgrep.dev/getting-started/cli”

   proof ↗⚑ flag

   Trivy—none0/10

   Trivy's evidence pack documents a CLI, container/filesystem scanning, SBOM generation, and an MCP server plugin, but no official language SDKs (Go/Python/JS client libraries) for developers to build against are mentioned anywhere; probes for llms.txt/openapi also return 404. missing for 10: any documented official SDK/client library, language-specific package for programmatic integration, API reference for building custom tooling.

   • [probe] “PROBE openapi: all candidate paths 404 (https://trivy.dev/openapi.json, https://trivy.dev/swagger.json, https://trivy.dev/api/openapi.json, …”
   • [probe] “PROBE llms.txt: HTTP 404 at https://trivy.dev/llms.txt”
   • [claimed-docs] “This plugin starts a Model Context Protocol (MCP) server that integrates Trivy's security scanning capabilities with VS Code and other MCP-e…”
   • [github] “Trivy is available in most common distribution channels. ... `brew install trivy` ... `docker run aquasec/trivy`”

   proof ↗⚑ flag

7. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   Semgrep—none0/10

   Evidence shows Semgrep provides a REST API for querying findings/deployments and CI-integration on push/PR events, but nothing describes a webhook subscription mechanism for events; no docs mention webhook endpoints or event-driven notifications to external systems.

   • [claimed-docs] “Semgrep AppSec Platform provides an API that enables you to list deployments, gather findings created by Semgrep AppSec Platform, and list p…”
   • [claimed-docs] “Semgrep AppSec Platform provides an API that enables you to list deployments, gather findings created by Semgrep”
   • [claimed-docs] “your development cycle benefits from the automated scanning of repositories at various events, such as: Push events; Pull requests or merge …”

   proof ↗⚑ flag

   Trivy—none0/10

   Trivy is a CLI security scanner with an MCP server for AI querying, but there is no evidence of webhook subscription/event notification capability anywhere in the docs, GitHub repo, or probes. missing for 10: any webhook API/endpoint, event subscription mechanism, or documentation of push-based notifications.

   • [probe] “PROBE openapi: all candidate paths 404 (https://trivy.dev/openapi.json, https://trivy.dev/swagger.json, https://trivy.dev/api/openapi.json, …”
   • [github] “trivy k8s --report summary cluster”
   • [claimed-docs] “This plugin starts a Model Context Protocol (MCP) server that integrates Trivy's security scanning capabilities with VS Code and other MCP-e…”

   proof ↗⚑ flag

Agentic features

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

   weight 2 · round to Semgrep
   Semgrep~partialcommunity6/10

   Semgrep Code's 'AI-Powered Detection' and 'Semgrep Assistant (AI)' features are documented as generating insights (identifying complex business-logic flaws like IDORs, reducing false-positive noise by ~20%, combining AI reasoning with rule-based analysis for triage/remediation), which matches the story of in-product AI-generated insights. However, independent corroboration is thin — the one relevant community datapoint (semgrep-comm-14) describes a third party building their own external LLM triage layer on top of Semgrep's SARIF output rather than validating Semgrep Assistant itself, and another (semgrep-comm-13) notes an LLM hallucinating semgrep syntax when asked to help write rules, which is tangential. missing for 10: independent/hands-on validation of Semgrep Assistant's own AI suggestions, more detail on scope/accuracy of AI-Powered Detection, and confirmation these AI features are broadly available rather than gated/beta.

   • [claimed-docs] “With AI-Powered Detection, you can automatically identify complex business logic flaws, such as IDORs and broken authorization.”
   • [github] “Contextual post-processing of findings with Semgrep Assistant (AI) to further reduce noise by ~20%”
   • [claimed-docs] “Combine AI reasoning with rule-based analysis for detection, triage, and remediation”
   • [claimed-docs] “Semgrep Code is transparent; you can configure the rules it runs and inspect its syntax to understand how the finding was detected.”
   • [community] “Built a tool using Semgrep's SARIF output plus prompted LLMs to help prioritize triage; used at Microsoft for the past year to help surface …”

   proof ↗⚑ flag

   Trivy~partialprobed5/10

   Trivy ships an official MCP server (trivy-mcp) that lets AI tools query scan results via natural language ('Ask questions about security issues in natural language'), which enables AI-generated interaction with Trivy's data, but the evidence never shows Trivy itself producing AI-generated insights, remediation suggestions, or summaries beyond raw scan results being queryable. missing for 10: evidence of AI-generated remediation/insight suggestions produced by Trivy itself, first-party docs detailing what kind of AI reasoning the MCP server enables beyond Q&A, independent hands-on validation of the natural-language feature.

   • [claimed-docs] “Natural Language Scanning: Ask questions about security issues in natural language”
   • [claimed-docs] “**Natural Language Scanning**: Ask questions about security issues in natural language”
   • [claimed-docs] “This plugin starts a Model Context Protocol (MCP) server that integrates Trivy's security scanning capabilities with VS Code and other MCP-e…”
   • [probe] “official MCP server documented at https://github.com/aquasecurity/trivy-mcp”

   proof ↗⚑ flag

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

   weight 2 · round to Semgrep
   Semgrep~partialclaimed5/10

   Semgrep supports automation via CI triggers on push/PR events, pre-commit hooks, and bulk 'Managed Scans' that run without manual invocation, and it has an AI Assistant/AI-Powered Detection layer for triage — providing real background automation. However, this is rule-based scan automation, not an autonomous agent that independently plans/executes multi-step actions; there's no evidence of scheduled/cron-like agentic orchestration beyond scan-on-event triggers. Missing for 10: evidence of autonomous multi-step agentic decision-making, scheduling/orchestration beyond CI-triggered scans, and independent confirmation that AI-driven remediation runs unattended.

   • [claimed-docs] “your development cycle benefits from the automated scanning of repositories at various events, such as: Push events; Pull requests or merge …”
   • [claimed-docs] “your development cycle benefits from the automated scanning of repositories at various events, such as: Push events, Pull requests or merge …”
   • [claimed-docs] “consider Semgrep Managed Scans, which enables you to bulk onboard and scan your repositories without requiring changes to your CI”
   • [claimed-docs] “The pre-commit framework can run semgrep when you commit changes. This is helpful in preventing secrets and security issues from leaking int…”
   • [claimed-docs] “The pre-commit framework can run `semgrep` when you commit changes. This is helpful in preventing secrets and security issues from leaking i…”
   • [claimed-docs] “With AI-Powered Detection, you can automatically identify complex business logic flaws, such as IDORs and broken authorization.”
   • [github] “Contextual post-processing of findings with Semgrep Assistant (AI) to further reduce noise by ~20%”
   • [claimed-docs] “Combine AI reasoning with rule-based analysis for detection, triage, and remediation”

   proof ↗⚑ flag

   Trivy~partialprobed4/10

   Trivy is a CLI scanner that community evidence shows is easy to wire into CI/CD pipelines (trivy-comm-14) and it ships an MCP server (trivy-docs-13, trivy-probe-4) that lets agentic tools invoke scans via natural language, which supports background/automated invocation by an AI agent. However there is no documented native scheduler, daemon mode, or first-party 'autonomous background job' feature — automation depends entirely on external CI/cron infrastructure. Missing for 10: evidence of built-in scheduling/daemon mode, first-party autonomous trigger/orchestration docs, and independent confirmation of unattended long-running automation.

   • [community] “it's super easy to integrate in every ci/cd pipeline”
   • [claimed-docs] “This plugin starts a Model Context Protocol (MCP) server that integrates Trivy's security scanning capabilities with VS Code and other MCP-e…”
   • [probe] “official MCP server documented at https://github.com/aquasecurity/trivy-mcp”
   • [claimed-docs] “Natural Language Scanning: Ask questions about security issues in natural language”

   proof ↗⚑ flag

3. ai-native userDelegate tasks to a built-in AI assistant inside the product

   weight 3 · round to Semgrep
   Semgrep~partialclaimed5/10

   Semgrep ships 'Semgrep Assistant', a built-in AI feature that performs AI-powered detection of complex logic flaws, contextual post-processing to reduce noise, and combines AI reasoning with rule-based analysis for detection/triage/remediation, which functions as a task-delegable AI assistant within the product. However, this is scoped to security triage/detection only, not a general-purpose conversational assistant, and there's no independent hands-on account confirming quality of delegation. Missing for 10: evidence of a general chat/agent interface for arbitrary task delegation, independent/hands-on validation of Assistant's outputs, and detail on how users interact with/invoke it beyond marketing copy.

   • [claimed-docs] “With AI-Powered Detection, you can automatically identify complex business logic flaws, such as IDORs and broken authorization.”
   • [github] “Contextual post-processing of findings with Semgrep Assistant (AI) to further reduce noise by ~20%”
   • [claimed-docs] “Scan and fix AI-generated code the moment it's written”
   • [claimed-docs] “Combine AI reasoning with rule-based analysis for detection, triage, and remediation”

   proof ↗⚑ flag

   Trivy—none0/10

   Trivy is a CLI/scanner and provides an MCP server (trivy-mcp) so external AI assistants (e.g., in VS Code) can call Trivy's scanning capabilities — this is the reverse relationship of 'delegating tasks to a built-in AI assistant inside the product.' There is no evidence of an assistant embedded within Trivy itself that a user can delegate tasks to.

   • [claimed-docs] “Natural Language Scanning: Ask questions about security issues in natural language”
   • [claimed-docs] “This plugin starts a Model Context Protocol (MCP) server that integrates Trivy's security scanning capabilities with VS Code and other MCP-e…”
   • [probe] “official MCP server documented at https://github.com/aquasecurity/trivy-mcp”

   proof ↗⚑ flag

4. ai-native userOperate the product with natural-language commands

   weight 2 · round to Trivy
   Semgrep~partialprobed3/10

   Semgrep is fundamentally a CLI/rule-based SAST tool; there's no documented natural-language command interface for the core product. The only relevant hook is a documented MCP server (semgrep-probe-3) which would let an AI agent invoke Semgrep via natural language, plus marketing mentions of 'AI reasoning' combined with rule-based detection (semgrep-docs-47/48), but no detail on what commands/actions are exposed or how they map from NL input. missing for 10: documented list of MCP tools/actions, evidence of actual natural-language command usage, hands-on confirmation that AI-native NL control works end-to-end.

   • [probe] “official MCP server documented at https://docs.semgrep.dev/mcp”
   • [claimed-docs] “Scan and fix AI-generated code the moment it's written”
   • [claimed-docs] “Combine AI reasoning with rule-based analysis for detection, triage, and remediation”
   • [github] “Contextual post-processing of findings with Semgrep Assistant (AI) to further reduce noise by ~20%”

   proof ↗⚑ flag

   Trivy~partialprobed6/10

   Trivy ships an official MCP server (trivy-mcp) explicitly advertised for 'Natural Language Scanning: Ask questions about security issues in natural language,' integrating with VS Code and other MCP-enabled tools, which enables natural-language operation via AI assistants. However, this is a separate plugin, not native to the core CLI, and evidence lacks independent hands-on validation of the natural-language experience quality. Missing for 10: independent/hands-on confirmation of natural-language query accuracy, broader detail on supported commands/scope beyond the one-line docs claim.

   • [claimed-docs] “Natural Language Scanning: Ask questions about security issues in natural language”
   • [claimed-docs] “**Natural Language Scanning**: Ask questions about security issues in natural language”
   • [claimed-docs] “This plugin starts a Model Context Protocol (MCP) server that integrates Trivy's security scanning capabilities with VS Code and other MCP-e…”
   • [probe] “official MCP server documented at https://github.com/aquasecurity/trivy-mcp”

   proof ↗⚑ flag

Api quality

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

   weight 2 · round drawn
   Semgrep—none0/10

   Semgrep documents an AppSec Platform API (list deployments, findings, projects) but there is no evidence of an interactive API reference with runnable/try-it examples; the openapi.json/swagger probes returned 404 on all candidate paths, indicating no interactive spec-based docs.

   • [claimed-docs] “Semgrep AppSec Platform provides an API that enables you to list deployments, gather findings created by Semgrep AppSec Platform, and list p…”
   • [claimed-docs] “Semgrep AppSec Platform provides an API that enables you to list deployments, gather findings created by Semgrep”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.semgrep.dev/openapi.json, https://docs.semgrep.dev/swagger.json, https://docs.semgrep.d…”

   proof ↗⚑ flag

   Trivy—none0/10

   Trivy is a CLI security scanner with no public API reference; probes confirm no OpenAPI/Swagger spec exists (trivy-probe-3) and no llms.txt (trivy-probe-1). There is no evidence of any interactive API reference with runnable examples.

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

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Semgrep—none0/10

   Semgrep documents a REST API for the AppSec Platform (semgrep-docs-17/59) but a direct probe for machine-readable OpenAPI/Swagger specs at standard paths returned 404 everywhere (semgrep-probe-2), and no evidence of a published API spec exists elsewhere in the pack.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.semgrep.dev/openapi.json, https://docs.semgrep.dev/swagger.json, https://docs.semgrep.d…”
   • [claimed-docs] “Semgrep AppSec Platform provides an API that enables you to list deployments, gather findings created by Semgrep AppSec Platform, and list p…”
   • [claimed-docs] “Semgrep AppSec Platform provides an API that enables you to list deployments, gather findings created by Semgrep”

   proof ↗⚑ flag

   Trivy—none0/10

   Trivy is a CLI/scanner tool, not an API-driven service, but the story asks specifically for a downloadable machine-readable API spec; probes explicitly confirm no OpenAPI/swagger spec exists at any expected location and no llms.txt either. No evidence of any published API spec anywhere in the evidence pack.

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

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Semgrep—none0/10

   Semgrep documents an AppSec Platform API (semgrep-docs-17/59) but no evidence pack item mentions API versioning scheme or a documented deprecation policy; an OpenAPI spec probe returned 404s (semgrep-probe-2), suggesting no formal API contract is published. missing for 10: versioning scheme documentation, deprecation policy/notice process, changelog or migration guides for API changes.

   • [claimed-docs] “Semgrep AppSec Platform provides an API that enables you to list deployments, gather findings created by Semgrep AppSec Platform, and list p…”
   • [claimed-docs] “Semgrep AppSec Platform provides an API that enables you to list deployments, gather findings created by Semgrep”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.semgrep.dev/openapi.json, https://docs.semgrep.dev/swagger.json, https://docs.semgrep.d…”

   proof ↗⚑ flag

   Trivy—none0/10

   No evidence of versioned APIs or a documented deprecation policy; probes show no OpenAPI spec, and docs evidence never mentions API versioning or deprecation guarantees.

   • [probe] “PROBE openapi: all candidate paths 404 (https://trivy.dev/openapi.json, https://trivy.dev/swagger.json, https://trivy.dev/api/openapi.json, …”

   proof ↗⚑ flag

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

   weight 2 · round to Semgrep
   Semgrep~partialclaimed6/10

   Semgrep supports bulk-style operations such as scanning an entire codebase/monorepo in one command, cross-file/interfile analysis across many files, and 'Managed Scans' explicitly designed to 'bulk onboard and scan your repositories without requiring changes to your CI.' The AppSec Platform API also lets you programmatically list deployments/projects/findings across an organization. However, there is no documented bulk-action tooling (e.g., bulk triage, bulk rule application, batch API calls) beyond onboarding/scanning, so the story is only partially covered. Missing for 10: explicit bulk API endpoints for mass finding triage/remediation, evidence of batch operations beyond scanning/onboarding, and independent confirmation of large-scale bulk workflows in practice.

   • [claimed-docs] “consider Semgrep Managed Scans, which enables you to bulk onboard and scan your repositories without requiring changes to your CI”
   • [claimed-docs] “Learn how to set up Semgrep, scan your first project, which can be any codebase, repository, or folder within a monorepo, for security issue…”
   • [claimed-docs] “scan your first project, which can be any codebase, repository, or folder within a monorepo, for security issues, and view your findings”
   • [claimed-docs] “Semgrep AppSec Platform provides an API that enables you to list deployments, gather findings created by Semgrep AppSec Platform, and list p…”
   • [claimed-docs] “Semgrep AppSec Platform provides an API that enables you to list deployments, gather findings created by Semgrep”
   • [claimed-docs] “To turn on cross-file analysis, which allows you to detect vulnerabilities across files and folders”

   proof ↗⚑ flag

   Trivy~partialcommunity5/10

   Trivy's CLI supports scanning multiple targets (images, filesystems, repos) and cluster-wide scans (e.g., trivy k8s cluster), and community evidence confirms it's easy to script and integrate into CI/CD pipelines for batch automation. However, there's no explicit documentation of a dedicated bulk/batch API, parallel multi-target job orchestration, or native support for processing large lists of items in one invocation beyond shell-level scripting. missing for 10: documented bulk/batch processing API, evidence of parallelized multi-target scanning at scale, first-party guidance on bulk operations beyond single-target CLI invocations.

   • [github] “trivy k8s --report summary cluster”
   • [community] “I've had a great experience with Trivy, very solid tool, very easy to write automation around.”
   • [community] “it's super easy to integrate in every ci/cd pipeline”
   • [claimed-docs] “Trivy will look for vulnerabilities based on lock files such as Gemfile.lock and package-lock.json.”

   proof ↗⚑ flag

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

   weight 3 · round to Semgrep
   Semgrep✓fullclaimed8/10

   Semgrep rules can be configured to run automatically on events (push, PR/MR, pre-commit) and trigger downstream actions such as PR comments, alerts/notifications, ticket creation, and autofix application — all documented as first-class features (semgrep-docs-25/28/16/46/22/30/38/53/57). This directly matches the story of rules triggering automated actions on events. missing for 10: independent/hands-on evidence confirming these automated trigger-action pipelines (e.g., ticket creation, alerting) work reliably in production beyond vendor docs.

   • [claimed-docs] “your development cycle benefits from the automated scanning of repositories at various events, such as: Push events; Pull requests or merge …”
   • [claimed-docs] “your development cycle benefits from the automated scanning of repositories at various events, such as: Push events, Pull requests or merge …”
   • [claimed-docs] “The pre-commit framework can run semgrep when you commit changes. This is helpful in preventing secrets and security issues from leaking int…”
   • [claimed-docs] “The pre-commit framework can run `semgrep` when you commit changes. This is helpful in preventing secrets and security issues from leaking i…”
   • [claimed-docs] “Triage findings * Send alerts and notifications or create tickets to track findings identified by Semgrep Code”
   • [claimed-docs] “Triage findings Send alerts and notifications or create tickets to track findings identified by Semgrep Code”
   • [claimed-docs] “You can apply the Rule-defined fix directly to the file using the `--autofix` flag.”
   • [claimed-docs] “You can apply the Rule-defined fix directly to the file using the --autofix flag.”
   • [claimed-docs] “You can use Semgrep and its GitHub integration to automate PR comments that you frequently make in code reviews.”

   proof ↗⚑ flag

   Trivy—none0/10

   Trivy is a scanner run on-demand or in CI pipelines; the evidence shows no rule-based/event-triggered automation engine (e.g., defining rules that fire actions on events) within Trivy itself—only scan integrations into CI/CD and an MCP server for querying results conversationally. No evidence of a rules engine or event-driven action system.

   ⚑ 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 drawn
   Semgrep~partialcommunity7/10

   Semgrep's CLI clearly supports headless, unauthenticated scanning (`semgrep ci`/`semgrep scan`, no login required, --dry-run) and machine-readable output via SARIF export, which an agent could parse. Community evidence (semgrep-comm-14) shows this pattern used in practice — SARIF output plus LLM triage to surface real findings for human review at Microsoft. Docs also mention 'send alerts/notifications or create tickets to track findings' for Semgrep Code, but this is vague and tied to the platform tier rather than a demonstrated CLI-to-issue-tracker pipeline. Missing for 10: explicit documented JSON/SARIF-to-ticket automation workflow, first-party GitHub/Jira issue-filing integration for CLI findings, and independent hands-on confirmation that filed issues correspond only to 'real' (non-false-positive) findings given community complaints about false positives (semgrep-comm-11).

   • [claimed-docs] “navigate to the root of your project, and run your first scan: semgrep ci”
   • [claimed-docs] “semgrep scan - This is the recommended command for scanning local codebases or scanning a project when you don't have a Semgrep account”
   • [claimed-docs] “The `--dry-run` flag ensures that your scans are not uploaded to the Semgrep web app.”
   • [claimed-docs] “You do **not** need to be logged in to run a scan.”
   • [claimed-docs] “To export the results to a SARIF file:”
   • [claimed-docs] “To export the results to a SARIF file: semgrep ci --sarif --sarif-output=semgrep.sarif”
   • [claimed-docs] “Triage findings * Send alerts and notifications or create tickets to track findings identified by Semgrep Code”
   • [claimed-docs] “Triage findings Send alerts and notifications or create tickets to track findings identified by Semgrep Code”
   • [community] “Built a tool using Semgrep's SARIF output plus prompted LLMs to help prioritize triage; used at Microsoft for the past year to help surface …”

   proof ↗⚑ flag

   Trivy~partialcommunity7/10

   Trivy is a CLI-first scanner explicitly designed for headless CI use, with documented commands (trivy image/fs) and structured output formats like SBOM (CycloneDX/SPDX), and community reports confirm it's 'super easy to integrate in every ci/cd pipeline' and easy to script automation around. However, the evidence pack lacks explicit documentation of JSON/table output flags for machine parsing, and there's no evidence of built-in issue-filing/ticketing integration (that would require external glue code an agent would write). missing for 10: explicit --format json output docs, native issue-tracker filing integration, independent validation of an agent successfully parsing results end-to-end.

   • [claimed-docs] “It detects known vulnerabilities in your container image.”
   • [claimed-docs] “Trivy will look for vulnerabilities based on lock files such as Gemfile.lock and package-lock.json.”
   • [claimed-docs] “Trivy can generate the following SBOM formats. * [CycloneDX](#cyclonedx) * [SPDX](#spdx)”
   • [github] “trivy k8s --report summary cluster”
   • [github] “Trivy is available in most common distribution channels. ... `brew install trivy` ... `docker run aquasec/trivy`”
   • [community] “I've had a great experience with Trivy, very solid tool, very easy to write automation around.”
   • [community] “it's super easy to integrate in every ci/cd pipeline”

   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 Semgrep
   Semgrep✓fullprobed7/10

   Semgrep ships an official MCP server (docs.semgrep.dev/mcp) letting coding agents call the scanner directly, plus first-party messaging on scanning/fixing AI-generated code the moment it's written and combining AI reasoning with rule-based detection, and a pre-commit hook to catch issues before they land in Git history. Missing for 10: independent/hands-on validation that the MCP integration reliably works inside real agent workflows, and detail on latency or false-positive behavior when used inline with AI code generation.

   • [probe] “official MCP server documented at https://docs.semgrep.dev/mcp”
   • [claimed-docs] “Scan and fix AI-generated code the moment it's written”
   • [claimed-docs] “Combine AI reasoning with rule-based analysis for detection, triage, and remediation”
   • [claimed-docs] “The pre-commit framework can run semgrep when you commit changes. This is helpful in preventing secrets and security issues from leaking int…”
   • [claimed-docs] “The pre-commit framework can run `semgrep` when you commit changes. This is helpful in preventing secrets and security issues from leaking i…”

   proof ↗⚑ flag

   Trivy~partialprobed6/10

   Trivy ships an official MCP server (trivy-mcp) that integrates with VS Code and other MCP-enabled tools, letting coding agents invoke Trivy's scanning and query results in natural language — a direct fit for wiring into an AI coding agent. However, evidence is limited to first-party docs with no independent hands-on account of this specific workflow catching AI-generated code issues pre-merge. Missing for 10: independent/hands-on validation of the MCP integration in real agent workflows, and specifics on scanning AI-generated code specifically before it lands (e.g., pre-commit/pre-merge gating via the agent).

   • [claimed-docs] “Natural Language Scanning: Ask questions about security issues in natural language”
   • [claimed-docs] “**Natural Language Scanning**: Ask questions about security issues in natural language”
   • [claimed-docs] “This plugin starts a Model Context Protocol (MCP) server that integrates Trivy's security scanning capabilities with VS Code and other MCP-e…”
   • [probe] “official MCP server documented at https://github.com/aquasecurity/trivy-mcp”

   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 to Semgrep
   Semgrep✓fullcommunity9/10

   Docs explicitly cover running `semgrep ci` in CI pipelines triggered on push/PR events, with dedicated CI provider guides, SARIF export, and exit-code based build behavior implied by 'ci' command design for gating; community evidence corroborates real-world CI usage. missing for 10: explicit documented mention of exit code semantics for failing builds on new findings (implied but not directly quoted).

   • [claimed-docs] “navigate to the root of your project, and run your first scan: semgrep ci”
   • [claimed-docs] “This guide walks you through creating a Semgrep job in the following CI providers, which are explicitly supported in Semgrep AppSec Platform”
   • [claimed-docs] “your development cycle benefits from the automated scanning of repositories at various events, such as: Push events; Pull requests or merge …”
   • [claimed-docs] “Semgrep is integrated into CI environments by creating a **job** that is run by the CI provider. After a scan, findings are sent to Semgrep …”
   • [claimed-docs] “To export the results to a SARIF file: semgrep ci --sarif --sarif-output=semgrep.sarif”
   • [community] “We've used Semgrep for Zulip's Python codebase for months and really appreciate the semantic checks, especially for security lint rules - it…”

   proof ↗⚑ flag

   Trivy~partialcommunity4/10

   Evidence confirms Trivy is widely used in CI/CD pipelines and is 'super easy to integrate' (trivy-comm-14, trivy-comm-11), and its scanning targets (image, filesystem, git) support PR-triggered scans, but the pack lacks any documentation of exit-code flags, fail-on-new-findings logic, or CI-specific configuration (e.g., GitHub Actions, exit-code thresholds). Missing for 10: explicit docs on --exit-code / --exit-on-eol flags, examples of failing CI builds on new vs. baseline findings, and first-party GitHub Actions/pipeline integration guides.

   • [community] “it's super easy to integrate in every ci/cd pipeline”
   • [community] “I've had a great experience with Trivy, very solid tool, very easy to write automation around.”
   • [claimed-docs] “It detects known vulnerabilities in your container image.”
   • [claimed-docs] “Trivy scans any container image, filesystem and git repository to detect exposed secrets like passwords, api keys, and tokens. Secret scanni…”

   proof ↗⚑ flag

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

   weight 2 · round to Semgrep
   Semgrep✓fullclaimed7/10

   Docs confirm Semgrep integrates into CI at push/PR/MR events, posts PR/MR comments for Secrets findings, and offers a GitHub integration for automating PR review comments, with findings sent to the AppSec Platform after scans. missing for 10: explicit first-party documentation of GitHub/GitLab PR status checks (not just comments) for Semgrep Code/Supply Chain findings, and independent hands-on confirmation of the PR-comment UX beyond docs.

   • [claimed-docs] “informs developers of valid secrets in their PRs and MRs by posting comments directly”
   • [claimed-docs] “your development cycle benefits from the automated scanning of repositories at various events, such as: Push events; Pull requests or merge …”
   • [claimed-docs] “your development cycle benefits from the automated scanning of repositories at various events, such as: Push events, Pull requests or merge …”
   • [claimed-docs] “Semgrep is integrated into CI environments by creating a **job** that is run by the CI provider. After a scan, findings are sent to Semgrep …”
   • [claimed-docs] “You can use Semgrep and its GitHub integration to automate PR comments that you frequently make in code reviews.”
   • [claimed-docs] “This guide walks you through creating a Semgrep job in the following CI providers, which are explicitly supported in Semgrep AppSec Platform”

   proof ↗⚑ flag

   Trivy—none0/10

   No evidence in the pack mentions PR/MR comments, GitHub/GitLab checks, or CI annotation integration; the pack only covers scanning targets, SBOM, MCP server, and unrelated security incidents. This is a plausible capability for a scanner (via CI actions), so the axis applies, but absence of evidence means 'none' rather than 'na'.

   ⚑ 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 Semgrep
   Semgrep✓fullclaimed9/10

   Semgrep has explicit first-party documentation for integrating with the pre-commit framework, stating it runs semgrep on commit specifically to prevent secrets and security issues from leaking into git history, matching the story verbatim. Missing for 10: no independent/hands-on community confirmation specifically of the pre-commit hook workflow (community evidence covers CLI/CI use generally, not pre-commit hook experience).

   • [claimed-docs] “The pre-commit framework can run semgrep when you commit changes. This is helpful in preventing secrets and security issues from leaking int…”
   • [claimed-docs] “The pre-commit framework can run `semgrep` when you commit changes. This is helpful in preventing secrets and security issues from leaking i…”
   • [claimed-docs] “The pre-commit framework can run semgr”

   proof ↗⚑ flag

   Trivy—none0/10

   Evidence shows Trivy scans secrets and filesystems and is easy to integrate into CI/CD generally, but no documentation or mention of a pre-commit hook framework integration (e.g., .pre-commit-hooks.yaml) is provided in the evidence pack.

   ⚑ flag

Containers

1. devops-leadScan container images for OS-package and application-layer vulnerabilities before deploying them

   weight 3 · round to Trivy
   Semgrep—none0/10

   The evidence pack covers Semgrep Code (SAST), Secrets, and Supply Chain (dependency/OSS SCA) scanning of source repositories, CI pipelines, and manifests, but contains no mention of scanning container images or detecting OS-package vulnerabilities inside image layers — a capability offered by dedicated container scanners. Since Semgrep explicitly compares itself to AppSec competitors (Checkmarx, Snyk) that do offer this, the axis is a fair comparison point but no evidence shows Semgrep delivers it.

   • [claimed-docs] “Semgrep Supply Chain is a software composition analysis (SCA) tool that detects security vulnerabilities in your codebase introduced by open…”
   • [claimed-docs] “Generate reports and software bills of materials (SBOM) that provide a complete inventory of your open source components”
   • [claimed-docs] “Supply Chain's Dynamic Dependency Resolution provides a complete inventory of your project's dependencies using a combination of manifest pa…”
   • [claimed-docs] “Semgrep Secrets scans code to detect exposed API keys, passwords, and other credentials.”

   proof ↗⚑ flag

   Trivy✓fullcommunity9/10

   Trivy's core, well-documented capability is scanning container images for OS-package vulnerabilities (trivy-docs-1, trivy-docs-17) and application-layer/lock-file vulnerabilities (trivy-docs-2), backed by community corroboration of strong real-world CI/CD scanning use (trivy-comm-11, trivy-comm-12, trivy-comm-14). This directly matches the devops-lead's pre-deployment scanning need. missing for 10: independent benchmark/comparison of detection accuracy beyond community sentiment.

   • [claimed-docs] “It detects known vulnerabilities in your container image.”
   • [claimed-docs] “It detects known vulnerabilities in your container image... `$ trivy image [YOUR_IMAGE_NAME]`”
   • [claimed-docs] “Trivy will look for vulnerabilities based on lock files such as Gemfile.lock and package-lock.json.”
   • [community] “I've had a great experience with Trivy, very solid tool, very easy to write automation around.”
   • [community] “we use AquaSec and it's absolutely the same engine. Trivy is so good we were tempted to drop AquaSec entirely as we only use it in our CI an…”
   • [community] “it's super easy to integrate in every ci/cd pipeline”

   proof ↗⚑ flag

Iac misconfig

1. devops-leadScan Terraform, Kubernetes, and other IaC files for security misconfigurations

   weight 2 · round to Trivy
   Semgrep~partialclaimed3/10

   Semgrep's docs mention that rules can be written to 'scan configuration files' as one use case (docs-21/35), which implies some IaC coverage, but the evidence pack never explicitly names Terraform, Kubernetes, Dockerfile, or IaC misconfiguration scanning as a supported capability. missing for 10: explicit documentation of Terraform/Kubernetes/Dockerfile rule packs, dedicated IaC scanning mode or product tier, and any community/hands-on confirmation of IaC misconfiguration detection.

   • [claimed-docs] “you can write rules that: Automate code review comments. Identify secure coding violations. Scan configuration files.”
   • [claimed-docs] “Automate code review comments. * Identify secure coding violations. * Scan configuration files.”
   • [claimed-docs] “Semgrep uses rules, which encapsulate pattern matching logic and data flow analysis, to scan your code for security issues, style violations…”

   proof ↗⚑ flag

   Trivy✓fullcommunity9/10

   Trivy's docs explicitly state built-in misconfiguration checks for Docker, Kubernetes, Terraform, CloudFormation and more, plus k8s cluster scanning via `trivy k8s`, and community reviews corroborate strong CI/CD IaC scanning usage. Missing for 10: independent hands-on validation specifically of Terraform/K8s misconfig detection accuracy (only Docker/vuln scanning has community corroboration).

   • [claimed-docs] “Trivy provides built-in checks to detect configuration issues in popular Infrastructure as Code files, such as: Docker, Kubernetes, Terrafor…”
   • [github] “trivy k8s --report summary cluster”
   • [community] “I've had a great experience with Trivy, very solid tool, very easy to write automation around.”
   • [community] “it's super easy to integrate in every ci/cd pipeline”

   proof ↗⚑ flag

Coverage

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

   weight 2 · round to Trivy
   Semgrep~partialcommunity6/10

   Docs and community evidence show Semgrep scanning across many languages (Python, JS/TS, Ruby, YAML, HTML, CSS) and separately covering open-source package ecosystems via Semgrep Supply Chain (docs-11,12,13,23,29,44,55), plus a generic-pattern fallback for unsupported languages (docs-39). However there's no explicit doc listing 'all major languages/ecosystems' coverage, and a hands-on report shows Semgrep's parser failing on valid TypeScript syntax (comm-3), plus performance complaints scanning large multi-language codebases (comm-2, comm-7) that temper the breadth claim. missing for 10: an explicit enumerated language/ecosystem coverage matrix, resolution of the TypeScript parser bug, and independent benchmarking across the full claimed language set.

   • [claimed-docs] “If there's a code pattern in the codebase that matches the vulnerability definition, the finding is flagged as reachable.”
   • [claimed-docs] “Generate reports and software bills of materials (SBOM) that provide a complete inventory of your open source components”
   • [claimed-docs] “Supply Chain's Dynamic Dependency Resolution provides a complete inventory of your project's dependencies using a combination of manifest pa…”
   • [claimed-docs] “Detect malicious dependencies associated with Supply Chain attacks”
   • [claimed-docs] “Semgrep Supply Chain is a software composition analysis (SCA) tool that detects security vulnerabilities in your codebase introduced by open…”
   • [claimed-docs] “Semgrep can match generic patterns in languages that it does **not** yet support.”
   • [community] “Semgrep's parser complains that valid TypeScript using a typed catch clause (`catch (error: unknown)`) is invalid and can't be parsed.”
   • [community] “The underlying tree-sitter parser Semgrep uses is amazing - parsing millions of files across JS, TS, Ruby, YAML, HTML, CSS in about half a m…”
   • [community] “Running the CI ruleset on a tiny Django hobby project spun all cores to 100% after 33% progress and made the OS almost unresponsive; had to …”
   • [community] “We've used Semgrep for Zulip's Python codebase for months and really appreciate the semantic checks, especially for security lint rules - it…”

   proof ↗⚑ flag

   Trivy~partialcommunity7/10

   Trivy documents scanning of container images, filesystems, and git repos for vulnerabilities via lock files (e.g., Gemfile.lock, package-lock.json), plus secrets, misconfigurations, licenses, and SBOM generation—covering many languages/ecosystems and package managers broadly. However, the evidence pack lacks an explicit enumerated list of 'all major languages/ecosystems' supported, and one community report notes a runtime panic on a specific scan type (AWS scanning), suggesting coverage gaps or bugs in some scan modes. missing for 10: an authoritative full list of supported languages/package managers, independent verification of breadth across ecosystems, and confirmation that edge-case scans (e.g., cloud scanning) are reliable.

   • [claimed-docs] “It detects known vulnerabilities in your container image.”
   • [claimed-docs] “Trivy will look for vulnerabilities based on lock files such as Gemfile.lock and package-lock.json.”
   • [claimed-docs] “Trivy scans any container image, filesystem and git repository to detect exposed secrets like passwords, api keys, and tokens. Secret scanni…”
   • [claimed-docs] “Trivy provides built-in checks to detect configuration issues in popular Infrastructure as Code files, such as: Docker, Kubernetes, Terrafor…”
   • [claimed-docs] “Trivy scans any container image for license files and offers an opinionated view on the risk associated with the license.”
   • [claimed-docs] “Trivy can generate the following SBOM formats. * [CycloneDX](#cyclonedx) * [SPDX](#spdx)”
   • [community] “Just tried it: ./trivy aws --region us-east-1 -> panic: runtime error: invalid memory address or nil pointer dereference. Posted a Github is…”
   • [community] “I would kill for an all-in-one solution where I work... today we use a different scanner for every single type of scan we perform, and it's …”

   proof ↗⚑ flag

Output formats

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

   weight 2 · round to Semgrep
   Semgrep✓fullcommunity9/10

   Docs explicitly document exporting SARIF output via `semgrep ci --sarif --sarif-output=semgrep.sarif`, and community evidence shows real-world use of Semgrep's SARIF output for downstream tooling (e.g., piping into LLM triage at Microsoft). JSON output is also a standard supported format implied by the CLI's general reporting capabilities, though not separately documented in this pack. missing for 10: explicit docs snippet for --json flag usage.

   • [claimed-docs] “To export the results to a SARIF file:”
   • [claimed-docs] “To export the results to a SARIF file: semgrep ci --sarif --sarif-output=semgrep.sarif”
   • [community] “Built a tool using Semgrep's SARIF output plus prompted LLMs to help prioritize triage; used at Microsoft for the past year to help surface …”

   proof ↗⚑ flag

   Trivy—none0/10

   The evidence pack shows Trivy generates SBOM formats (CycloneDX/SPDX) and integrates well with CI/CD, but nowhere documents the --format flag or explicit JSON/SARIF vulnerability-scan output that this story asks about. missing for 10: explicit documentation of JSON/SARIF output format flags for vulnerability/misconfiguration scan results, any example of SARIF file generation, and confirmation of downstream tool consumption (e.g., GitHub Code Scanning integration).

   • [community] “I would kill for an all-in-one solution where I work... today we use a different scanner for every single type of scan we perform, and it's …”
   • [community] “it's super easy to integrate in every ci/cd pipeline”

   proof ↗⚑ flag

Dependency fixes

1. developerGet concrete upgrade paths or automated fix pull requests that remediate vulnerable dependencies

   weight 2 · round drawn
   Semgrep—none0/10

   Semgrep Supply Chain (SCA) evidence covers dependency vulnerability detection, reachability analysis, SBOM generation, and malicious dependency detection, but nothing in the evidence pack describes generating concrete upgrade paths or automated fix pull requests for vulnerable dependencies. The --autofix flag ([semgrep-docs-38],[semgrep-docs-53]) applies to Semgrep Code's rule-defined fixes for SAST findings, not dependency remediation.

   • [claimed-docs] “If there's a code pattern in the codebase that matches the vulnerability definition, the finding is flagged as reachable.”
   • [claimed-docs] “Generate reports and software bills of materials (SBOM) that provide a complete inventory of your open source components”
   • [claimed-docs] “Supply Chain's Dynamic Dependency Resolution provides a complete inventory of your project's dependencies using a combination of manifest pa…”
   • [claimed-docs] “Detect malicious dependencies associated with Supply Chain attacks”
   • [claimed-docs] “Semgrep Supply Chain is a software composition analysis (SCA) tool that detects security vulnerabilities in your codebase introduced by open…”
   • [claimed-docs] “You can apply the Rule-defined fix directly to the file using the `--autofix` flag.”

   proof ↗⚑ flag

   Trivy—none0/10

   Trivy is purely a scanner/detector—evidence shows it detects vulnerabilities, misconfigurations, secrets, and generates SBOMs, but nothing indicates it suggests upgrade paths, fix versions, or opens automated remediation pull requests. No auto-fix PR or dependency-upgrade feature is documented anywhere in the evidence pack.

   • [claimed-docs] “It detects known vulnerabilities in your container image.”
   • [claimed-docs] “Trivy will look for vulnerabilities based on lock files such as Gemfile.lock and package-lock.json.”
   • [claimed-docs] “Trivy can generate the following SBOM formats. * [CycloneDX](#cyclonedx) * [SPDX](#spdx)”

   proof ↗⚑ flag

Sca scanning

1. developerScan my dependency manifests and lockfiles for packages with known vulnerabilities

   weight 3 · round to Trivy
   Semgrep✓fullcommunity7/10

   Semgrep Supply Chain is explicitly documented as an SCA tool that scans manifests/lockfiles, resolves dependency inventories, flags reachable vulnerabilities, detects malicious packages, and generates SBOMs (semgrep-docs-11,12,13,23,29,55). This directly matches the story of scanning dependency manifests/lockfiles for known vulnerabilities. Missing for 10: independent/hands-on community validation of SCA accuracy or usability (community evidence only covers SAST rule-writing, not the SCA/dependency-scanning feature), and one community comment (semgrep-comm-12) notes SCA isn't open-source and may require uploading data, a caveat not fully addressed in docs.

   • [claimed-docs] “If there's a code pattern in the codebase that matches the vulnerability definition, the finding is flagged as reachable.”
   • [claimed-docs] “Generate reports and software bills of materials (SBOM) that provide a complete inventory of your open source components”
   • [claimed-docs] “Supply Chain's Dynamic Dependency Resolution provides a complete inventory of your project's dependencies using a combination of manifest pa…”
   • [claimed-docs] “Detect malicious dependencies associated with Supply Chain attacks”
   • [claimed-docs] “Semgrep Supply Chain is a software composition analysis (SCA) tool that detects security vulnerabilities in your codebase introduced by open…”
   • [claimed-docs] “Support the enforcement of your business’ open source package licensing requirements”
   • [claimed-docs] “Semgrep Supply Chain is a software composition analysis (SCA) tool that detects security vulnerabilities in”
   • [community] “Regarding Semgrep Supply Chain: "This is not open source, though? It does make a big difference for some whether you're able to run the chec…”

   proof ↗⚑ flag

   Trivy✓fullcommunity9/10

   Trivy explicitly documents scanning lockfiles like Gemfile.lock and package-lock.json for known vulnerabilities, with strong first-party docs and positive independent community feedback on its CI/CD scanning usage. missing for 10: broader independent benchmark of lockfile-specific detection accuracy across more ecosystems.

   • [claimed-docs] “Trivy will look for vulnerabilities based on lock files such as Gemfile.lock and package-lock.json.”
   • [community] “I've had a great experience with Trivy, very solid tool, very easy to write automation around.”
   • [community] “it's super easy to integrate in every ci/cd pipeline”

   proof ↗⚑ flag

2. security-engineerPrioritize dependency alerts by whether the vulnerable code is actually reachable from my code

   weight 2 · round to Semgrep
   Semgrep~partialclaimed6/10

   Semgrep Supply Chain explicitly implements reachability analysis, flagging findings as reachable when a matching code pattern exists in the codebase, which directly supports prioritizing dependency alerts by reachability. However, evidence lacks detail on how reachability is surfaced in triage workflows (e.g., filtering/sorting UI, PR gating specifically by reachability) and no independent/hands-on verification of reachability accuracy is present. missing for 10: evidence of UI/workflow for filtering or sorting alerts by reachability status, independent validation of reachability detection accuracy, detail on false negative/positive rates for reachability analysis.

   • [claimed-docs] “If there's a code pattern in the codebase that matches the vulnerability definition, the finding is flagged as reachable.”
   • [claimed-docs] “If there’s a code pattern in the codebase that matches the vulnerability definition, the finding is flagged as reachable.”
   • [claimed-docs] “Semgrep Supply Chain is a software composition analysis (SCA) tool that detects security vulnerabilities in your codebase introduced by open…”
   • [claimed-docs] “Supply Chain's Dynamic Dependency Resolution provides a complete inventory of your project's dependencies using a combination of manifest pa…”

   proof ↗⚑ flag

   Trivy—none0/10

   Trivy's evidence pack shows vulnerability detection, SBOM generation, secret scanning, and misconfiguration checks, but nothing about reachability analysis or code-path tracing to determine if vulnerable dependency code is actually invoked/exposed. No mention of call-graph analysis, static reachability, or exploitability-based prioritization.

   ⚑ flag

1. ai-native userExport all of my data in open formats and leave

   weight 3 · round drawn
   Semgrep~partialclaimed5/10

   Semgrep supports open-format export of scan results (SARIF) and a platform API to gather findings/projects, plus local CLI scanning that never uploads code by default (dry-run, no login required), which supports data portability and avoiding lock-in. However there's no documented comprehensive 'export all your data' feature covering full platform history, configs, and org data in one open bundle. Missing for 10: explicit bulk/account-level data export documentation, confirmation of open formats beyond SARIF (e.g., JSON schema docs), and independent verification of a full data portability workflow.

   • [claimed-docs] “To export the results to a SARIF file:”
   • [claimed-docs] “To export the results to a SARIF file: semgrep ci --sarif --sarif-output=semgrep.sarif”
   • [claimed-docs] “The `--dry-run` flag ensures that your scans are not uploaded to the Semgrep web app.”
   • [claimed-docs] “You do **not** need to be logged in to run a scan.”
   • [claimed-docs] “Semgrep AppSec Platform provides an API that enables you to list deployments, gather findings created by Semgrep”
   • [github] “Semgrep analyzes code locally on your computer or in your build environment: by default, code is never upload”

   proof ↗⚑ flag

   Trivy~partialclaimed5/10

   Trivy generates SBOMs and scan reports in open, interoperable standards (CycloneDX, SPDX) rather than proprietary formats, and being open-source/self-hosted there is inherently no vendor lock-in to escape from. However, there's no explicit documentation framing this as 'exporting all your data to leave' — it's a scanner tool, not a data-storing platform, so the story is only partially applicable and evidenced. Missing for 10: explicit statement about exporting full scan history/config, independent corroboration that these formats are freely portable across tools, and clarity on what 'all data' means for a stateless CLI scanner.

   • [claimed-docs] “Trivy can generate the following SBOM formats. * [CycloneDX](#cyclonedx) * [SPDX](#spdx)”
   • [claimed-docs] “Trivy can generate the following SBOM formats.”
   • [claimed-docs] “Trivy can generate the following SBOM formats. * CycloneDX * SPDX”
   • [claimed-docs] “Trivy can generate SBOM for local projects.”

   proof ↗⚑ flag

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

   weight 2 · round to Trivy
   Semgrep~partialcommunity5/10

   The core Semgrep engine is hosted on a public GitHub repo (semgrep-gh-1/2/3), showing source code is publicly readable, but no evidence pack item states an explicit open-source license (e.g., LGPL) or points to a LICENSE file. Community evidence also notes that a commercial component, Semgrep Supply Chain, is explicitly 'not open source' (semgrep-comm-12), meaning the broader product is not uniformly open-licensed. missing for 10: explicit license text/citation, confirmation covering all product components, independent verification of license terms.

   • [github] “Semgrep would match x = 1; y = x + 1 when searching for 2”
   • [github] “Semgrep analyzes code locally on your computer or in your build environment: by default, code is never upload”
   • [github] “Contextual post-processing of findings with Semgrep Assistant (AI) to further reduce noise by ~20%”
   • [community] “Regarding Semgrep Supply Chain: "This is not open source, though? It does make a big difference for some whether you're able to run the chec…”

   proof ↗⚑ flag

   Trivy~partialprobed6/10

   Trivy's source is hosted publicly on GitHub (aquasecurity/trivy) and its own site describes it as an 'open source vulnerability scanning' tool, implying an open license, but no evidence pack item explicitly cites a license file (e.g., Apache-2.0) or license text. Missing for 10: explicit license identifier/citation, confirmation of license terms (permissions, redistribution), and independent corroboration of license compliance.

   • [github] “trivy k8s --report summary cluster”
   • [github] “Trivy is available in most common distribution channels. ... `brew install trivy` ... `docker run aquasec/trivy`”
   • [claimed-docs] “After evaluating several leading options for open source vulnerability scanning, Trivy really stood out”
   • [probe] “official CLI documented at https://github.com/aquasecurity/trivy”

   proof ↗⚑ flag

3. ai-native userSelf-host the core product

   weight 3 · round drawn
   Semgrep✓fullclaimed7/10

   Semgrep's core CLI/engine is open source and runs entirely on local infrastructure by default, never uploading code, and works without an account or login, which is effectively self-hosting the core scanning product (semgrep-gh-2, semgrep-docs-33/34/50/51/27). Missing for 10: explicit documentation of self-hosting the full AppSec Platform/server components, and independent hands-on confirmation of a self-hosted enterprise deployment.

   • [github] “Semgrep analyzes code locally on your computer or in your build environment: by default, code is never upload”
   • [claimed-docs] “The `--dry-run` flag ensures that your scans are not uploaded to the Semgrep web app.”
   • [claimed-docs] “You do **not** need to be logged in to run a scan.”
   • [claimed-docs] “You can run local Semgrep CLI scans with the Semgrep command-line tool.”
   • [claimed-docs] “The --dry-run flag ensures that your scans are not uploaded to the Semgrep web app.”
   • [claimed-docs] “semgrep scan - This is the recommended command for scanning local codebases or scanning a project when you don't have a Semgrep account”

   proof ↗⚑ flag

   Trivy✓fullprobed7/10

   Trivy is an open-source CLI/binary distributed via package managers and Docker images, meaning the core scanning engine runs entirely on the user's own infrastructure with no mandatory SaaS dependency, satisfying the self-hosting expectation for an AI-native user who wants full control over the tool. Missing for 10: explicit documentation of a self-hosted 'Trivy Server' mode/architecture for shared caching, and independent hands-on confirmation of air-gapped/offline self-hosted deployments.

   • [github] “Trivy is available in most common distribution channels. ... `brew install trivy` ... `docker run aquasec/trivy`”
   • [probe] “official CLI documented at https://github.com/aquasecurity/trivy”
   • [claimed-docs] “After evaluating several leading options for open source vulnerability scanning, Trivy really stood out”

   proof ↗⚑ flag

1. ai-native userControl data retention and deletion

   weight 2 · round to Semgrep
   Semgrep~partialclaimed4/10

   Docs show privacy-preserving defaults (local-only scanning, --dry-run to avoid upload, no login required), giving users some control over whether data leaves their machine, but there is no evidence of explicit data retention periods, deletion mechanisms, or account/data-erasure controls for data that is uploaded to the Semgrep AppSec Platform. missing for 10: documented retention policy, explicit deletion/erasure controls for platform-stored findings, GDPR/CCPA data handling commitments.

   • [github] “Semgrep analyzes code locally on your computer or in your build environment: by default, code is never upload”
   • [claimed-docs] “The `--dry-run` flag ensures that your scans are not uploaded to the Semgrep web app.”
   • [claimed-docs] “The --dry-run flag ensures that your scans are not uploaded to the Semgrep web app.”
   • [claimed-docs] “You do **not** need to be logged in to run a scan.”

   proof ↗⚑ flag

   Trivy—none0/10

   No evidence describes any data retention, storage duration, or deletion controls for Trivy's scan results, cache, vulnerability DB, or MCP interactions; the docs focus solely on scanning capabilities and CLI/MCP setup, not privacy/retention policy.

   ⚑ flag

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

   weight 2 · round to Semgrep
   Semgrep~partialclaimed5/10

   Semgrep's docs and GitHub README indicate privacy-conscious defaults: code is analyzed locally and never uploaded by default, no login is required to run a scan, and the --dry-run flag explicitly prevents scan results from being uploaded to the Semgrep web app. However, there's no explicit documentation of a dedicated 'telemetry/usage tracking' opt-out setting (e.g., an env var or flag specifically for metrics/telemetry) beyond the scan-upload behavior. missing for 10: explicit telemetry/usage-metrics opt-out flag or setting, independent confirmation of what usage data (if any) is collected outside of code content.

   • [github] “Semgrep analyzes code locally on your computer or in your build environment: by default, code is never upload”
   • [claimed-docs] “The `--dry-run` flag ensures that your scans are not uploaded to the Semgrep web app.”
   • [claimed-docs] “You do **not** need to be logged in to run a scan.”
   • [claimed-docs] “The --dry-run flag ensures that your scans are not uploaded to the Semgrep web app.”

   proof ↗⚑ flag

   Trivy—none0/10

   No evidence pack item mentions telemetry, usage tracking, or an opt-out mechanism for Trivy or its MCP server; the axis is plausible for a CLI/MCP tool but no documentation confirms or denies it.

   ⚑ flag

Ai remediation

1. ai-native userHave AI draft remediation pull requests for security findings that I review and merge

   weight 2 · round to Semgrep
   Semgrep~partialclaimed4/10

   Semgrep offers rule-defined autofix (--autofix), AI-powered detection/triage/remediation messaging ('Combine AI reasoning with rule-based analysis for detection, triage, and remediation'), and GitHub PR comment automation, but there is no documented evidence of an end-to-end AI-drafted pull request workflow for remediation that a user reviews and merges. missing for 10: evidence of automatic PR/MR creation with AI-generated code fixes, a documented workflow showing AI drafting a remediation diff as a mergeable PR, and independent/hands-on confirmation of this remediation-PR feature working.

   • [claimed-docs] “You can apply the Rule-defined fix directly to the file using the `--autofix` flag.”
   • [claimed-docs] “Combine AI reasoning with rule-based analysis for detection, triage, and remediation”
   • [claimed-docs] “You can use Semgrep and its GitHub integration to automate PR comments that you frequently make in code reviews.”
   • [claimed-docs] “informs developers of valid secrets in their PRs and MRs by posting comments directly”

   proof ↗⚑ flag

   Trivy—none0/10

   Trivy is a scanner that detects vulnerabilities, misconfigurations, secrets, and generates SBOMs; the evidence shows an MCP server for natural-language querying of scan results, but nowhere does it show Trivy or its MCP integration drafting remediation pull requests for review/merge. No evidence of automated PR generation capability.

   • [claimed-docs] “Natural Language Scanning: Ask questions about security issues in natural language”
   • [claimed-docs] “This plugin starts a Model Context Protocol (MCP) server that integrates Trivy's security scanning capabilities with VS Code and other MCP-e…”

   proof ↗⚑ flag

Code analysis

1. security-engineerDetect taint-style vulnerabilities that flow across files and function boundaries

   weight 2 · round to Semgrep
   Semgrep✓fullclaimed8/10

   Semgrep explicitly documents taint tracking/taint mode for catching injection-style vulnerabilities (semgrep-docs-41, semgrep-docs-58) and separately documents cross-file (interfile) analysis via Semgrep Code (semgrep-docs-2, semgrep-docs-32) plus interprocedural/interfile constant propagation (semgrep-docs-42), together supporting taint flows across files and function boundaries. Missing for 10: no independent/hands-on evidence specifically validating cross-file taint tracking accuracy (community evidence only covers simpler pattern-matching bypasses, not taint-mode cross-file cases).

   • [claimed-docs] “Taint tracking (known also as taint analysis) enables you to write simple rules that catch complex injection bugs, such as those that can re…”
   • [claimed-docs] “Semgrep supports taint analysis, also known as taint tracking, through taint rules.”
   • [claimed-docs] “To turn on cross-file analysis, which allows you to detect vulnerabilities across files and folders”
   • [claimed-docs] “Learn how to set up Semgrep, scan your project for security issues using Semgrep Code’s interfile analysis, and view your findings in the CL…”
   • [claimed-docs] “Semgrep AppSec Platform supports interprocedural (cross-function), interfile (cross-file) constant propagation.”

   proof ↗⚑ flag

   Trivy—none0/10

   Trivy is a vulnerability/misconfiguration/secret/SBOM scanner focused on known-CVE and dependency detection; the evidence pack shows no taint-analysis or cross-file/cross-function data-flow SAST capability (e.g. no mention of source-code taint tracking like Semgrep/CodeQL). This is an applicable axis for a security scanning tool, but there is no evidence Trivy performs taint-style SAST analysis.

   ⚑ flag

2. developerRun static analysis that finds vulnerability classes like injection and XSS in my source code

   weight 3 · round to Semgrep
   Semgrep✓fullcommunity8/10

   Semgrep explicitly documents SAST scanning with taint tracking designed to catch injection and XSS bugs (semgrep-docs-41, semgrep-docs-58), backed by a CLI scan workflow (semgrep-docs-19, semgrep-docs-27) and corroborated by community use for security lint rules including injection detection (semgrep-comm-1, semgrep-comm-7). Missing for 10: independent benchmark data on vulnerability-class detection rates, and community reports show simple evasions (e.g., function aliasing) can bypass naive rules (semgrep-comm-6, semgrep-comm-10), indicating real-world efficacy caveats.

   • [claimed-docs] “Taint tracking (known also as taint analysis) enables you to write simple rules that catch complex injection bugs, such as those that can re…”
   • [claimed-docs] “Semgrep supports taint analysis, also known as taint tracking, through taint rules.”
   • [claimed-docs] “navigate to the root of your project, and run your first scan: semgrep ci”
   • [claimed-docs] “semgrep scan - This is the recommended command for scanning local codebases or scanning a project when you don't have a Semgrep account”
   • [community] “As a security consultant, I write custom Semgrep rules to match antipatterns unique to a codebase (e.g., controllers missing an authorizatio…”
   • [community] “We've used Semgrep for Zulip's Python codebase for months and really appreciate the semantic checks, especially for security lint rules - it…”
   • [community] “A simple Semgrep 'no-prints' rule can be trivially bypassed with a workaround like `import builtins; builtins.print("whee")`, showing the to…”
   • [community] “Tried the Semgrep editor demo searching for exec(...) in Python; it failed to catch a simple aliasing workaround: `not_exec = exec; not_exec…”

   proof ↗⚑ flag

   Trivy—none0/10

   Trivy's documented capabilities are vulnerability scanning (known CVEs in dependencies/images), secret detection, IaC misconfiguration checks, license and SBOM generation — none of the evidence shows a SAST engine that analyzes source code for vulnerability classes like injection or XSS. This is a fair axis for a security scanning product, but no evidence supports it, so it is 'none' rather than 'na'.

   • [claimed-docs] “It detects known vulnerabilities in your container image.”
   • [claimed-docs] “Trivy will look for vulnerabilities based on lock files such as Gemfile.lock and package-lock.json.”
   • [claimed-docs] “Trivy scans any container image, filesystem and git repository to detect exposed secrets like passwords, api keys, and tokens. Secret scanni…”
   • [claimed-docs] “Trivy provides built-in checks to detect configuration issues in popular Infrastructure as Code files, such as: Docker, Kubernetes, Terrafor…”
   • [claimed-docs] “Trivy scans any container image for license files and offers an opinionated view on the risk associated with the license.”
   • [claimed-docs] “Trivy can generate the following SBOM formats. * [CycloneDX](#cyclonedx) * [SPDX](#spdx)”

   proof ↗⚑ flag

Custom rules

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

   weight 2 · round to Semgrep
   Semgrep✓fullcommunity8/10

   Semgrep's docs extensively cover writing custom rules with a simple YAML-based pattern syntax, testing them, using taint tracking, and sharing rules across repos via the Registry and private rules for teams; community evidence (HN) confirms security engineers actually write custom rules to catch codebase-specific antipatterns and find the syntax readable/flexible across languages. Missing for 10: independent evidence specifically validating cross-repo sharing workflows at scale, and community reports note real limitations (bypassable rules, parser errors, performance issues) that slightly temper confidence in robustness.

   • [claimed-docs] “you can write custom rules to determine what Semgrep detects in your repositories”
   • [claimed-docs] “you can write and test using the [Semgrep Editor]”
   • [claimed-docs] “you can write rules that: Automate code review comments. Identify secure coding violations. Scan configuration files.”
   • [claimed-docs] “Users with Semgrep Code's Team or Enterprise tier can publish rules to the Semgrep Registry as private rules that are not visible to those o…”
   • [claimed-docs] “Semgrep provides a testing mechanism for your rules. You can write code and provide annotations to let Semgrep know where you are or aren't …”
   • [claimed-docs] “Taint tracking (known also as taint analysis) enables you to write simple rules that catch complex injection bugs, such as those that can re…”
   • [claimed-docs] “Semgrep supports taint analysis, also known as taint tracking, through taint rules.”
   • [community] “As a security consultant, I write custom Semgrep rules to match antipatterns unique to a codebase (e.g., controllers missing an authorizatio…”
   • [community] “A simple Semgrep 'no-prints' rule can be trivially bypassed with a workaround like `import builtins; builtins.print("whee")`, showing the to…”

   proof ↗⚑ flag

   Trivy—none0/10

   Trivy's evidence covers vulnerability, misconfiguration, secret, license, and SBOM scanning, but there is no mention of a custom rule-writing syntax (e.g., Rego/OPA policies) or a mechanism for sharing custom rules across repositories in this evidence pack.

   ⚑ flag

Fix suggestions

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

   weight 2 · round to Semgrep
   Semgrep~partialclaimed6/10

   Semgrep supports rule-defined autofix via the --autofix flag, letting developers apply suggested fixes directly to files (semgrep-docs-38, semgrep-docs-53), and AppSec Platform mentions 'remediation' and 'fix AI-generated code' (semgrep-docs-45, semgrep-docs-47). However, autofix depends on individual rules defining a fix and is not universal across all findings, and there's no independent/community evidence confirming real-world reliability of autofix. missing for 10: community/hands-on validation of autofix accuracy, evidence of coverage breadth (what % of rules ship with fixes), and any first-party numbers on fix acceptance rates.

   • [claimed-docs] “You can apply the Rule-defined fix directly to the file using the `--autofix` flag.”
   • [claimed-docs] “You can apply the Rule-defined fix directly to the file using the --autofix flag.”
   • [claimed-docs] “Semgrep is integrated into CI environments by creating a **job** that is run by the CI provider. After a scan, findings are sent to Semgrep …”
   • [claimed-docs] “Scan and fix AI-generated code the moment it's written”
   • [claimed-docs] “Combine AI reasoning with rule-based analysis for detection, triage, and remediation”

   proof ↗⚑ flag

   Trivy—none0/10

   Trivy is purely a scanner that detects vulnerabilities, misconfigurations, secrets, and licenses and reports findings; there is no evidence of any suggested-fix or auto-remediation capability in the docs, CLI, or MCP integration, which only supports natural-language querying of scan results.

   • [claimed-docs] “It detects known vulnerabilities in your container image.”
   • [claimed-docs] “Trivy provides built-in checks to detect configuration issues in popular Infrastructure as Code files, such as: Docker, Kubernetes, Terrafor…”
   • [claimed-docs] “Trivy scans any container image, filesystem and git repository to detect exposed secrets like passwords, api keys, and tokens. Secret scanni…”
   • [claimed-docs] “This plugin starts a Model Context Protocol (MCP) server that integrates Trivy's security scanning capabilities with VS Code and other MCP-e…”

   proof ↗⚑ flag

Custom detection

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

   weight 2 · round to Semgrep
   Semgrep~partialcommunity6/10

   Semgrep's generic rule-writing engine is well documented (custom rules, pattern matching, Editor for testing) and community evidence confirms security engineers write custom rules for org-specific patterns, which extends naturally to matching internal token/secret formats via pattern or regex-based rules. However, there is no explicit documentation showing how to author custom rules specifically within the Semgrep Secrets product (e.g., custom secret validators or format definitions) — the evidence only shows built-in secret detection (docs-8/9/10) and generic custom rule capability (docs-4/5/21), not a documented workflow for adding custom secret-format rules to Semgrep Secrets. Missing for 10: explicit docs/examples for authoring custom Semgrep Secrets rule types (validators, custom regex-based secret detectors), and independent confirmation of doing so for secrets specifically.

   • [claimed-docs] “you can write custom rules to determine what Semgrep detects in your repositories”
   • [claimed-docs] “you can write and test using the [Semgrep Editor]”
   • [claimed-docs] “you can write rules that: Automate code review comments. Identify secure coding violations. Scan configuration files.”
   • [claimed-docs] “Semgrep Secrets scans code to detect exposed API keys, passwords, and other credentials.”
   • [claimed-docs] “valid secrets are those that have been tested against a web service and confirmed to successfully grant resources or authentication. They ar…”
   • [community] “As a security consultant, I write custom Semgrep rules to match antipatterns unique to a codebase (e.g., controllers missing an authorizatio…”

   proof ↗⚑ flag

   Trivy—none0/10

   Evidence confirms Trivy has built-in secret scanning for passwords, API keys, and tokens (trivy-docs-3, trivy-docs-10), but nothing in the pack describes an ability for users to define custom regex/rules for organization-specific token formats. Missing for 10: any documentation of custom secret rule configuration, regex pattern definition, or allow/deny-list rule authoring.

   • [claimed-docs] “Trivy scans any container image, filesystem and git repository to detect exposed secrets like passwords, api keys, and tokens. Secret scanni…”
   • [claimed-docs] “Trivy scans any container image, filesystem and git repository to detect exposed secrets like passwords, api keys, and tokens.”

   proof ↗⚑ flag

Secret scanning

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

   weight 3 · round to Trivy
   Semgrep~partialclaimed4/10

   Semgrep Secrets is documented to scan code for exposed API keys, passwords, and credentials and validate them (semgrep-docs-8, semgrep-docs-9, semgrep-docs-43), and pre-commit hooks aim to prevent secrets from entering git history (semgrep-docs-16/46), but this only prevents future leaks — none of the evidence shows Semgrep actually scanning the full historical git commit log/diffs for previously committed secrets (a capability tools like gitleaks/trufflehog specialize in). missing for 10: explicit documentation or feature for scanning past git commits/history (not just current working tree), evidence of retroactive history-wide secret detection, independent confirmation this works in practice.

   • [claimed-docs] “Semgrep Secrets scans code to detect exposed API keys, passwords, and other credentials.”
   • [claimed-docs] “valid secrets are those that have been tested against a web service and confirmed to successfully grant resources or authentication. They ar…”
   • [claimed-docs] “Semgrep saves security engineers time and effort by prioritizing valid leaked secrets and informs developer”
   • [claimed-docs] “The pre-commit framework can run semgrep when you commit changes. This is helpful in preventing secrets and security issues from leaking int…”
   • [claimed-docs] “The pre-commit framework can run `semgrep` when you commit changes. This is helpful in preventing secrets and security issues from leaking i…”

   proof ↗⚑ flag

   Trivy~partialclaimed5/10

   Trivy explicitly supports secret scanning across filesystem, container image, and git repository targets, enabled by default (trivy-docs-3, trivy-docs-10). However, the evidence never confirms that this scan traverses the full git commit history (e.g., detecting secrets committed and later removed) rather than just the current working tree/HEAD state. Missing for 10: explicit documentation or demonstration of full git-history secret scanning, independent verification of history-depth coverage.

   • [claimed-docs] “Trivy scans any container image, filesystem and git repository to detect exposed secrets like passwords, api keys, and tokens. Secret scanni…”
   • [claimed-docs] “Trivy scans any container image, filesystem and git repository to detect exposed secrets like passwords, api keys, and tokens.”
   • [claimed-docs] “it stores analysis results, using the latest commit hash as the key.”

   proof ↗⚑ flag

2. security-engineerScan non-git sources like S3 buckets, Docker images, and CI logs for leaked secrets

   weight 2 · round to Trivy
   Semgrep—none0/10

   Semgrep Secrets is documented to scan code/repositories for exposed credentials, but nothing in the evidence pack shows support for scanning non-git sources like S3 buckets, Docker images, or CI logs — all scanning references are to codebases, folders, monorepos, or CI pipelines running against git-based projects.

   • [claimed-docs] “Semgrep Secrets scans code to detect exposed API keys, passwords, and other credentials.”
   • [claimed-docs] “valid secrets are those that have been tested against a web service and confirmed to successfully grant resources or authentication. They ar…”
   • [claimed-docs] “Semgrep saves security engineers time and effort by prioritizing valid leaked secrets and informs developer”
   • [claimed-docs] “Semgrep Secrets scans code to detect exposed API ke”

   proof ↗⚑ flag

   Trivy~partialcommunity4/10

   Trivy's secret scanner explicitly supports container images, filesystem, and git repositories (trivy-docs-3, trivy-docs-10), covering the 'Docker images' part of the story, but there is no evidence of secret scanning for S3 buckets or CI logs specifically. A 'trivy aws' subcommand exists (trivy-comm-15) but it's shown crashing and is not documented as a secret-detection target. missing for 10: documented S3 bucket secret scanning, documented CI log secret scanning, and hands-on confirmation these non-git sources work reliably.

   • [claimed-docs] “Trivy scans any container image, filesystem and git repository to detect exposed secrets like passwords, api keys, and tokens. Secret scanni…”
   • [claimed-docs] “Trivy scans any container image, filesystem and git repository to detect exposed secrets like passwords, api keys, and tokens.”
   • [community] “Just tried it: ./trivy aws --region us-east-1 -> panic: runtime error: invalid memory address or nil pointer dereference. Posted a Github is…”

   proof ↗⚑ flag

3. security-engineerHave detected secrets verified against the issuing service so I know which ones are live

   weight 2 · round to Semgrep
   Semgrep✓fullclaimed8/10

   Semgrep Secrets explicitly performs validity checks by testing detected secrets against the issuing web service, distinguishing 'valid' (live, actively in use) secrets from invalid ones, and surfaces this in PR/MR comments to prioritize live secrets. Missing for 10: independent/hands-on corroboration of validation accuracy and broader coverage details across secret types/providers.

   • [claimed-docs] “valid secrets are those that have been tested against a web service and confirmed to successfully grant resources or authentication. They ar…”
   • [claimed-docs] “Semgrep Secrets scans code to detect exposed API keys, passwords, and other credentials.”
   • [claimed-docs] “informs developers of valid secrets in their PRs and MRs by posting comments directly”
   • [claimed-docs] “Semgrep saves security engineers time and effort by prioritizing valid leaked secrets and informs developer”

   proof ↗⚑ flag

   Trivy—none0/10

   Trivy's docs describe detecting secrets (passwords, API keys, tokens) via pattern-based scanning, but there is no evidence of any feature that verifies detected secrets against the issuing service (e.g., calling an API to check if a credential is still active/live). No mention of live-verification capability anywhere in the evidence pack.

   • [claimed-docs] “Trivy scans any container image, filesystem and git repository to detect exposed secrets like passwords, api keys, and tokens. Secret scanni…”
   • [claimed-docs] “Trivy scans any container image, filesystem and git repository to detect exposed secrets like passwords, api keys, and tokens.”

   proof ↗⚑ flag

Licenses

1. devops-leadDetect the licenses of my dependencies and enforce a license policy in scans

   weight 1 · round to Trivy
   Semgrep—none0/10

   Semgrep Supply Chain evidence focuses on SCA vulnerability detection, reachability analysis, malicious dependency detection, and SBOM generation, but nothing in the pack mentions license detection or license-policy enforcement for dependencies.

   • [claimed-docs] “Generate reports and software bills of materials (SBOM) that provide a complete inventory of your open source components”
   • [claimed-docs] “Supply Chain's Dynamic Dependency Resolution provides a complete inventory of your project's dependencies using a combination of manifest pa…”
   • [claimed-docs] “Detect malicious dependencies associated with Supply Chain attacks”
   • [claimed-docs] “Semgrep Supply Chain is a software composition analysis (SCA) tool that detects security vulnerabilities in your codebase introduced by open…”

   proof ↗⚑ flag

   Trivy~partialclaimed5/10

   Trivy documents dedicated license scanning that detects license files in container images and gives an opinionated risk categorization (trivy-docs-5), which covers the 'detect licenses' half of the story. However, the evidence pack contains no documentation of configurable allow/deny license lists or exit-code/policy enforcement gating a build on disallowed licenses—only the general misconfiguration/IaC policy engine is described (trivy-docs-4), not license-specific policy enforcement. missing for 10: explicit license allow/deny-list configuration, CI/CD gating or exit-code enforcement tied to license violations, independent confirmation of license policy enforcement in practice.

   • [claimed-docs] “Trivy scans any container image for license files and offers an opinionated view on the risk associated with the license.”
   • [claimed-docs] “Trivy provides built-in checks to detect configuration issues in popular Infrastructure as Code files, such as: Docker, Kubernetes, Terrafor…”

   proof ↗⚑ flag

Sbom

1. security-engineerGenerate a software bill of materials (SPDX or CycloneDX) for my project or image

   weight 2 · round to Trivy
   Semgrep~partialclaimed5/10

   Semgrep Supply Chain docs explicitly state it can 'generate reports and software bills of materials (SBOM)' as part of dependency inventory, confirming the capability exists, but this is gated behind the paid Supply Chain/AppSec Platform tier and no evidence specifies SPDX/CycloneDX format support, CLI flags, or container image SBOM generation. missing for 10: confirmation of specific SPDX/CycloneDX output formats, CLI command/flag documentation for SBOM export, container/image scanning SBOM support, and independent/hands-on corroboration of SBOM generation working as described.

   • [claimed-docs] “Generate reports and software bills of materials (SBOM) that provide a complete inventory of your open source components”
   • [claimed-docs] “Supply Chain's Dynamic Dependency Resolution provides a complete inventory of your project's dependencies using a combination of manifest pa…”
   • [claimed-docs] “Semgrep Supply Chain is a software composition analysis (SCA) tool that detects security vulnerabilities in your codebase introduced by open…”
   • [claimed-docs] “Support the enforcement of your business’ open source package licensing requirements”

   proof ↗⚑ flag

   Trivy✓fullclaimed9/10

   Trivy's docs explicitly document SBOM generation in both CycloneDX and SPDX formats for container images and filesystems/local projects, backed by a dedicated supply-chain SBOM guide and CLI usage. Missing for 10: independent/hands-on community corroboration specifically of SBOM output quality (community evidence focuses on vulnerability scanning and unrelated security incidents, not SBOM generation).

   • [claimed-docs] “Trivy can generate the following SBOM formats. * [CycloneDX](#cyclonedx) * [SPDX](#spdx)”
   • [claimed-docs] “Trivy can generate the following SBOM formats.”
   • [claimed-docs] “Trivy can generate SBOM for local projects.”
   • [claimed-docs] “Trivy can generate the following SBOM formats. * CycloneDX * SPDX”

   proof ↗⚑ flag

Ai triage

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

   weight 3 · round to Semgrep
   Semgrep~partialcommunity6/10

   Semgrep ships a native AI feature (Semgrep Assistant) explicitly described as 'contextual post-processing of findings...to further reduce noise by ~20%', and marketing docs claim combining 'AI reasoning with rule-based analysis for detection, triage, and remediation,' plus AI-powered detection for complex logic flaws — directly supporting AI-assisted false-positive reduction and triage. However, deduplication specifically is never mentioned, and the strongest independent evidence of AI triage in practice comes from a third-party tool built on Semgrep's SARIF output plus external LLMs (used at Microsoft) rather than the native Assistant, suggesting the first-party AI-triage feature is thin on independent corroboration. Missing for 10: explicit deduplication capability, deeper documentation of Assistant's explanation/false-positive-flagging behavior, independent hands-on evidence validating the native AI triage feature itself.

   • [github] “Contextual post-processing of findings with Semgrep Assistant (AI) to further reduce noise by ~20%”
   • [claimed-docs] “With AI-Powered Detection, you can automatically identify complex business logic flaws, such as IDORs and broken authorization.”
   • [claimed-docs] “Combine AI reasoning with rule-based analysis for detection, triage, and remediation”
   • [community] “Built a tool using Semgrep's SARIF output plus prompted LLMs to help prioritize triage; used at Microsoft for the past year to help surface …”

   proof ↗⚑ flag

   Trivy~partialprobed4/10

   Trivy's official MCP server (trivy-mcp) enables natural-language querying/explanation of scan findings via AI-enabled tools like VS Code, which supports the 'explaining findings' part of the story, but there is no documented feature for AI-driven deduplication of findings or automated false-positive flagging. Missing for 10: explicit deduplication logic, false-positive triage/suppression via AI, and independent hands-on evidence that MCP-based triage actually reduces noise in practice.

   • [claimed-docs] “Natural Language Scanning: Ask questions about security issues in natural language”
   • [claimed-docs] “**Natural Language Scanning**: Ask questions about security issues in natural language”
   • [claimed-docs] “This plugin starts a Model Context Protocol (MCP) server that integrates Trivy's security scanning capabilities with VS Code and other MCP-e…”
   • [probe] “official MCP server documented at https://github.com/aquasecurity/trivy-mcp”

   proof ↗⚑ flag

Fp management

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

   weight 3 · round to Semgrep
   Semgrep~partialclaimed4/10

   Docs mention a 'Triage findings' capability (alerts/tickets for tracking findings) and Semgrep Assistant's contextual post-processing to reduce noise by ~20%, implying some findings-management workflow, but there is no explicit evidence of baseline scanning (e.g., baseline-commit diffing), ignore-comments (nosemgrep), or a documented false-positive suppression/triage-state workflow. missing for 10: explicit baseline-commit/diff scanning documentation, .semgrepignore or inline nosemgrep suppression evidence, and a documented 'mark as false positive / ignored' triage state in the platform.

   • [claimed-docs] “Triage findings * Send alerts and notifications or create tickets to track findings identified by Semgrep Code”
   • [claimed-docs] “Triage findings Send alerts and notifications or create tickets to track findings identified by Semgrep Code”
   • [github] “Contextual post-processing of findings with Semgrep Assistant (AI) to further reduce noise by ~20%”

   proof ↗⚑ flag

   Trivy—none0/10

   The evidence pack contains no mention of Trivy's .trivyignore file, ignore-policies, baseline/suppression features, or VEX-based suppression that would let a security engineer mark existing findings as accepted/false-positive so only new issues alert. All docs excerpts focus on scanning capabilities (vulnerabilities, secrets, misconfig, SBOM) with none addressing triage/ignore workflows. Missing for 10: documentation of .trivyignore/ignore-file support, VEX suppression, baseline diffing, or any triage-noise reduction feature.

   ⚑ flag

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

   weight 2 · round drawn
   Semgrep—none0/10

   The evidence pack describes general triage/noise features (AI post-processing to reduce noise, ticketing/alerts, reachability analysis) but never mentions severity levels, confidence scores, or a mechanism to filter/gate CI builds based on them. Missing for 10: explicit severity/confidence filtering flags (e.g., --severity), CI gating configuration based on severity/confidence thresholds, and documentation tying these to build pass/fail behavior.

   ⚑ flag

   Trivy—none0/10

   The evidence pack contains no mention of severity or confidence filtering flags (e.g. --severity, --exit-code) or any gating mechanism to suppress low-value findings; all cited docs focus on scan targets (image, filesystem, secrets, misconfig, SBOM) rather than triage/filtering controls. Missing for 10: any documentation of severity/confidence thresholds, exit-code gating, or ignore-file mechanisms to reduce noise.

   ⚑ flag