Make every code review a security review.
Gritcadence was founded to close the gap between static analysis tooling and the actual place where security issues slip through: the pull request.
The scanner ran. No one looked at the results.
Caleb Wright spent six years as a staff engineer at a mid-size infrastructure SaaS company in the Bay Area. From 2016 to 2021, his work kept converging on the same pattern: every serious post-mortem traced back to a pull request that had looked clean.
The team ran SAST in CI. The scanner had fired. The finding was there — a SQL injection via an f-string in cursor.execute(), mapped to CWE-89, confidence HIGH. It sat in a separate dashboard tab. The PR had two approvals. The reviewer was on their fourteenth PR of the day and didn't switch tabs. The issue spent fourteen months in production.
The problem wasn't the scanner. The problem was placement. The finding existed — it just didn't exist in the place where the decision to merge was being made.
Gritcadence is the answer to that gap. Every finding appears as an inline review comment on the exact line in the diff — inside the PR, where the reviewer already is. No tab switch. No separate tool. No broken review loop.
The people building Gritcadence
How we think about the work
Engineering rigor over marketing claims
We don't publish coverage numbers that look good but don't reflect real-world detection accuracy. When we claim OWASP A03 coverage, that means the taint tracking actually follows data from user input through to the vulnerable sink — not that we have a rule that fires on the word "execute". We're not trying to do what Snyk does (dependency scanning) or what GitHub Advanced Security does (bundled with the platform). We do one thing: static analysis in the code review workflow, with the precision and workflow integration that standalone tooling makes possible.
False positives are a design failure
A tool that cries wolf fails quietly. Engineers learn to ignore noisy output, and the real findings get buried in the same dismissal pattern. We treat every false positive as a bug in the engine or the rule, not an acceptable cost of doing business.
Security belongs in the review loop, not after it
Security that happens after code ships is remediation. Security that happens at review time is prevention. The difference is not philosophical — it's a question of where the finding appears. A finding in a SIEM or a compliance report arrives after the developer has moved on. A finding on line 51 of the PR diff arrives while the reviewer still has full context. We build for the second case.