namandogra431

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.

Today’s work focused on building and deploying the web version of SplitSense, taking it from a local idea to a live, production-ready application.

I started by designing a highly polished, responsive frontend using modern HTML, Tailwind CSS, glassmorphism, animations, and premium visual effects. The goal was to make the interface feel app-like, professional, and intuitive, with smooth interactions, animated headings, and a clean user flow for creating groups, adding members, and managing expenses. Special attention was given to responsiveness so the UI works seamlessly across desktop and mobile screens.

On the backend side, we implemented a Flask application (app.py) that handles core functionality: creating groups, storing members, adding expenses, calculating balances, and simplifying settlements. The backend uses clean routing, form handling, and in-memory data structures to power the app logic while keeping the architecture simple and easy to extend later (for example, with a database or authentication).

The final and most important step was deploying the Flask backend to the cloud using Render. This involved preparing the project structure, creating a requirements.txt, configuring Gunicorn as the production server, pushing the code to GitHub, and setting up a Render web service with HTTPS. After deployment, the app became accessible through a public URL, making it usable outside localhost and ready for real users. This completed the full web pipeline: design → backend → live deployment.

Today i have created the basic expense-splitting logic as ell as created the prototype Flask server, and i also made the basic ui to test the protoype

I’m working on my first project! This is so exciting. I can’t wait to share more updates as I build.