Changed the name to CypherAI sounds cooler :))
CypherAI started with a simple question: why do most developers eventually mute security tools? The answer wasn’t lack of vulnerabilities—it was lack of trust. Too many false positives, unclear warnings, and fixes that didn’t respect how code actually works.
From the beginning, CypherAI was designed to be deterministic and explainable. Instead of black-box analysis or ML guesses, it uses Python’s AST and explicit rules. Every finding exists because something concrete happened in the code, and CypherAI can point to it.
The first major feature was SQL Injection detection, but simply flagging the issue felt incomplete. Developers don’t just want to know what is wrong—they want to know how it happened. This led to taint-path explanations that show how user input flows through code until it reaches a dangerous operation. That became a core design principle.
As more rules were added—Command Injection, SSRF, Hardcoded Secrets, and Security Misconfiguration—precision became the priority. Rules were rewritten to require real sinks, real user input, and real data flow. Hardcoded secret detection went through several iterations to eliminate noise like emails, names, and file paths, using entropy and structure instead of naive pattern matching.
The CLI evolved alongside the engine: directory scanning, confidence scores, optional explanations, and CI-friendly exit codes turned CypherAI from a script into a usable tool. Fix suggestions and CWE-based education were added, but only when explicitly requested, keeping default output clean and developer-focused.
Today, CypherAI detects five OWASP-class vulnerabilities with high confidence, clear explanations, and minimal noise. It’s not built to overwhelm developers—it’s built to earn their trust and stay enabled.
This devlog marks the point where CypherAI stopped being an experiment and became a real security tool.