How It Works Features Integrations Pricing Changelog Docs Blog
Request access
Features

Static analysis that lives inside code review

Dataflow analysis, inline PR findings, YAML custom rules, and auditable suppression — without adding a new tool to your workflow or a new tab to your browser.

SAST Engine PR Automation Custom Rules Dashboards
SAST Engine

500+ rules. 7 languages. OWASP + CWE coverage.

The Gritcadence SAST engine scans every changed file in a pull request for security vulnerabilities. Built-in rules cover the full OWASP Top 10, mapped to CWE IDs for compatibility with your bug-tracker and compliance tooling.

The engine uses both AST-level pattern matching and inter-procedural dataflow analysis — following taint sources through function call boundaries to confirm that user-controlled input actually reaches a vulnerable sink. A finding is only raised when the rule has sufficient confidence that the issue is reachable and exploitable.

Language support
Python JavaScript TypeScript Go Java Ruby Rust
Language support matrix
Category Rules OWASP CWE
SQL Injection48CWE-89
XSS35CWE-79
Path Traversal29CWE-22
Hardcoded Creds61CWE-798
Insecure Deser.22CWE-502
Auth / AuthZ44CWE-306
PR Automation

Findings inside the PR. Not in another tab.

No dashboard login required. No separate tool to check. Security findings appear where your team is already reviewing code.

When Gritcadence finds an issue, it posts an inline review comment on the exact line in the diff. The comment contains the rule ID, severity, a plain-English description, and a suggested fix pattern.

On HIGH severity findings, Gritcadence adds a required check to the PR status — configurable per branch or per rule category. Reviewers can dismiss with justification, creating an auditable suppression record.

  • Inline comment on changed line
  • PR status check (configurable severity threshold)
  • Re-scan on every push to the branch
  • Auditable suppression with justification
PR #237 · handlers.py 116 def process_payment(request, amount): 117 user = request.user 118 query = f"SELECT * FROM accounts WHERE uid={user.id}" gritcadence-bot HIGH · GRCD-0081 SQL injection: f-string in cursor.execute (CWE-89) Use: cursor.execute("... WHERE uid=%s", (user.id,)) 119 cursor.execute(query) 120 return cursor.fetchall() CI / gritcadence · Failing security / gritcadence-scan · 1 HIGH severity issue
Custom Rules

Extend with YAML rules for your codebase

Your codebase has patterns no off-the-shelf scanner knows about — internal auth helpers, custom ORM wrappers, proprietary data access layers. Gritcadence's YAML rule DSL lets you write detection logic for exactly those patterns, with taint tracking support so rules follow data flow rather than matching surface syntax.

Rules are version-controlled as YAML files alongside your code. The test harness (grcd test-rules) validates them against fixture files with explicit should-match and should-not-match annotations before they run in production. On Team plans, a shared rule library applies your organization's rules across every connected repo without per-repo config.

Read the rule authoring guide
rules/no-raw-payments-query.yaml
1id: GRCD-CUSTOM-PAYMENTS-001
2severity: high
3language: python
4message: Raw SQL in payments context
5pattern: |
6 payment_db.execute($QUERY)
7taint: track_user_input: true
8fix: Use PaymentQuery ORM wrapper
Suppression

High false positive rates kill SAST adoption. We treat them as bugs.

A SAST tool that produces noisy output trains engineers to dismiss comments without reading them. Once that habit sets in, the real findings get buried in the same dismissal pattern. Gritcadence treats every false positive as a defect — either in the engine's confidence scoring or in the rule's context awareness.

The engine uses inter-procedural dataflow verification and AST-level context filtering before firing a rule. When a finding does reach a reviewer and they believe it's a false positive, they can suppress it inline with a required justification note. That suppression is stored per file/rule pair, carried forward on subsequent pushes, and visible in the dashboard — building an auditable record without leaving the review workflow.

Engine-level

Confidence scoring, data-flow verification, and context-aware filtering. Findings only fire when the engine has high confidence the issue is reachable and exploitable.

Reviewer-level

Inline suppression with required justification. Suppressions are stored per file/rule, visible in the dashboard, and reviewable by security leads.

Team Dashboards

Security posture across all your repos

The team dashboard gives security leads and engineering managers a cross-repo view: finding counts by severity and rule, MTTD trends, suppression rates, and week-over-week posture change. Not a compliance screenshot — a view that connects to actual review behavior.

Available on Team plans. All data is exportable via REST API for integration with your SIEM, Jira, Linear, or security metrics tooling. SARIF export is available for findings import into GitHub Advanced Security or similar platforms.

Findings by severity — last 8 weeks W1 W2 W3 W4 W5 W6 W7 HIGH MED

Static analysis that actually stays in the review loop.

Connect a repo in under 5 minutes. Starter is free — no credit card, 500+ built-in rules, 3 repos.