Semgrep vs Custom Rules for AI Security: Why We Chose the Engine

When I started building AI AppSec, I had a choice: write a custom AST parser for AI framework patterns, or use an existing static analysis engine. I spent a week prototyping both. The custom parser could detect a LangChain tool abuse pattern in 200 lines of Python. The Semgrep rule could detect the same pattern in 15 lines of YAML. The Semgrep rule also worked for TypeScript, JavaScript, JSX, and TSX without any changes. The custom parser worked for Python only.

I chose Semgrep. This article explains why, what the tradeoffs are, and when you might choose differently.

The two approaches

Custom AST parser: you write code that parses source files into an abstract syntax tree, traverses the tree, and matches patterns. You control every step. You support exactly the languages and frameworks you write parsers for.

Semgrep: you write rules in a declarative pattern language. Semgrep parses the source code, matches your patterns, and reports findings. Semgrep supports 30+ languages. You write rules, not parsers.

AI AppSec uses Semgrep 1.173.0 as its execution engine with a bundled rulepack of 122 detectors and 79 security checks. The rules are written in Semgrep's pattern language. The package installs Semgrep as an external dependency and runs the rules against your source code.

Why Semgrep

Cross-language support

AI applications are not single-language. A typical AI project has Python for model training, TypeScript for the API server, JavaScript for the frontend, and maybe some Go for infrastructure. A custom parser needs a separate implementation for each language. Semgrep supports all of them with the same rule syntax.

AI AppSec supports Python, TypeScript, JavaScript, JSX, and TSX. If I had written custom parsers, that would be five parser implementations. With Semgrep, it is one rulepack.

Mature pattern matching

Semgrep's pattern language is designed for security rules. It supports:

• Pattern matching: match code structures regardless of variable names or formatting
• Metavariables: capture parts of the matched code for use in the finding message
• Pattern-either: match one of several patterns (OR logic)
• Pattern-inside: match a pattern only if it appears inside another pattern (context)
• Pattern-not-inside: match a pattern only if it does not appear inside another pattern (negative context)
• Data flow: trace data from source to sink across function calls and assignments

Writing these features from scratch in a custom parser would take months. Semgrep has had them for years.

CI/CD integration

Semgrep runs in GitHub Actions, GitLab CI, CircleCI, Jenkins, and any CI system that can run a CLI tool. It outputs SARIF 2.1.0 for GitHub Code Scanning integration. It has a GitHub App for pull request comments.

AI AppSec inherits all of this. You run ai-appsec scan ./src --format sarif --output results.sarif in your CI pipeline and the results show up in GitHub Security tab.

Community ecosystem

Semgrep has a community registry of thousands of rules. AI AppSec's rulepack is separate (it is a bundled Public Core rulepack focused on AI patterns), but the ecosystem means the engine is well-maintained, well-documented, and well-tested.

The tradeoffs

External dependency

AI AppSec requires Semgrep 1.173.0 installed separately. The exact version is enforced because Semgrep rule syntax can change between versions. This means:

npm install -g ai-appsec
pip install semgrep==1.173.0

Two install commands instead of one. The Semgrep binary is approximately 50 MB. For CI pipelines, this adds about 10 seconds to the setup time.

A custom parser would be a single install with no external dependency. The tradeoff is that you maintain the parser.

Rule expressiveness limits

Semgrep's pattern language is powerful but not Turing-complete. There are patterns it cannot express:

• Complex data flow across files: Semgrep supports inter-file data flow, but deeply nested cross-file taint tracking can be difficult to express
• Type-aware matching: Semgrep has type inference but it is not as precise as a type checker. If you need to match "a variable of type OpenAIClient calling chat.completions.create", Semgrep can do it, but it may produce false positives if the variable name matches but the type does not
• Custom analysis logic: if you need to compute something that is not pattern matching (e.g., cyclomatic complexity, call graph analysis), Semgrep is the wrong tool

For AI AppSec's use case (matching AI framework patterns, detecting prompt injection sinks, finding tool abuse), Semgrep's expressiveness is sufficient. The 122 detectors and 79 checks are all expressible as Semgrep rules.

Version coupling

AI AppSec enforces Semgrep 1.173.0. If you already use Semgrep in your CI pipeline at a different version, you have a conflict. You need to either upgrade your existing Semgrep to 1.173.0 or run AI AppSec in a separate CI step with its own Semgrep version.

This is a real inconvenience. The version enforcement exists because Semgrep rule syntax has changed between versions in ways that break existing rules. Pinning the version ensures the rulepack works as tested.

A worked example: writing a custom Semgrep rule

Here is how you would write a Semgrep rule for the LangChain SSRF pattern I described in the AI AppSec article. The vulnerability: a LangChain tool that fetches a URL from user input without validation.

rules:
  - id: langchain-ssrf-via-tool-argument
    pattern: |
      @$DECORATOR
      def $FUNC($URL: str) -> str:
          ...
          requests.get($URL)
          ...
    message: "LangChain tool accepts URL from input and fetches without validation. SSRF risk."
    languages: [python]
    severity: ERROR
    metadata:
      category: ssrf
      cwe: "CWE-918"
      framework: langchain

This rule matches any Python function decorated with @tool (or any decorator) that accepts a string parameter named $URL and calls requests.get($URL). The ... is Semgrep's wildcard — it matches any code between the function signature and the requests.get call.

When AI AppSec runs, it includes rules like this one (the actual rulepack has 122 detectors with more sophisticated patterns). The finding includes the rule ID, file path, line number, and the message.

When to choose a custom parser

Semgrep is the right choice for AI AppSec because:

• The vulnerability patterns are expressible as pattern matches
• Cross-language support matters (AI apps are multi-language)
• CI/CD integration and SARIF output are required
• The team maintaining the rulepack is small (rules are easier to write than parsers)

A custom parser would be the right choice if:

• You need analysis logic that is not pattern matching (e.g., call graph construction, type checking)
• You need to support a language Semgrep does not support
• You need to integrate with a proprietary analysis pipeline that cannot run external tools
• You have a large team that can maintain parsers for multiple languages
• You need zero external dependencies

For most AI security use cases, Semgrep is the pragmatic choice. The time you save by not writing parsers is time you spend writing rules — and rules are where the security knowledge lives.

The rulepack

AI AppSec's bundled rulepack covers these concern families:

| Family | Detectors | What it checks | |---|---|---| | Prompt injection | 18 | User input flowing into LLM context without sanitization | | Tool abuse | 24 | Tools with broad permissions, missing validation, command execution | | SSRF | 12 | Fetch tools without private IP filtering | | Secrets exposure | 15 | API keys in prompts, credentials in tool arguments | | Data leakage | 14 | Sensitive data flowing into LLM context or model output | | Insecure output handling | 11 | Model output used in dangerous sinks | | Missing input validation | 16 | AI endpoints without input validation | | Insecure deserialization | 12 | Model output parsed as executable code or SQL |

The rulepack is bundled with the package. You do not write your own rules or configure anything. If you want to write custom rules for application-specific patterns, you can add them as a separate Semgrep configuration alongside the AI AppSec rulepack.

Where it fits

AI AppSec is the SOURCE layer in the Developer Security family. It uses Semgrep to scan source code. It does not check tenant boundaries (that is MCP Tenant Isolation) or runtime model I/O (that is LLMVerify).

The choice of Semgrep as the engine is an implementation detail. The value is in the 122 detectors and 79 checks that catch AI-specific vulnerability patterns. Whether those patterns are implemented as Semgrep rules or custom parser logic does not change what they find.