The Night I Almost Deleted My Own Security Tool..!

There's a specific kind of panic that hits at 1 AM when you change six lines of code and suddenly can't tell if your scanner is finding real vulnerabilities or just lying to you.

That happened to me twice while building SUDARSHAN. The second time, I almost gave up on the whole project and started over from nothing.

I didn't. Instead I sat with the mess for a few days and asked myself a question I'd been avoiding: was I building a security tool, or was I just really good at writing scripts that looked like one?

That question is the entire story of SUDARSHAN v3.

Where it started

A few months back I had a crawler. It walked websites, collected links, flagged anything with "admin" or "login" in the URL. I remember uploading it to GitHub and actually feeling proud — like I'd built something real.

Then I pointed it at an actual website and watched it do almost nothing useful. It found pages. It didn't understand them. It didn't test anything. It definitely didn't tell me whether what it found was actually exploitable.

I hadn't built a security tool. I'd built a link collector with a scary name.

That stung more than I expected. So I scrapped the mindset — not the code, the mindset — and started thinking about SUDARSHAN as a pipeline instead of a script: find the attack surface, test it properly, prove what's real, explain it clearly. That reframe is the whole reason SUDARSHAN exists in its current form.

The first real win — and why it scared me

I pointed an early version at demo.testfire.net, a banking site built specifically for people like me to practice on. I expected maybe a dozen findings.

[+] Found 20 pages, 22 forms
[INFO] Loaded 22 rules
[+] Scan complete! Found 334 vulnerabilities.

[+] Found 20 pages, 22 forms
[INFO] Loaded 22 rules
[+] Scan complete! Found 334 vulnerabilities.

1. My first reaction wasn't excitement. It was suspicion.

Nobody finds 334 real vulnerabilities on a demo app without something being wrong on their end. I spent the next two days not adding features, just trying to prove my own tool wrong — manually re-checking findings, trying to break my own detection logic, looking for the bug that would explain the number away.

I couldn't find one. The number was real. But that two days of doubting myself is where I actually learned what "validation" means in security tooling — not a checkbox, a discipline.

The 1 AM moment that changed the architecture

Here's what actually happened that night I mentioned at the start. I refactored one detection rule to make it "cleaner," ran a scan, and the finding count dropped by half. No errors. No crash. Just… fewer results, silently.

I had no way to know if that was a bug I'd fixed or a bug I'd introduced. That's the moment I understood the real problem with what I'd built: a scanner you can't trust after you touch it isn't a scanner, it's a black box with good PR.

So I stopped writing new detection rules for a while — which felt wrong, like I was going backwards — and built the things that don't show up in a demo:

• A pytest suite that runs before I'm allowed to trust a change
• GitHub Actions so every push gets checked automatically, not just when I remember to
• A rule dispatcher that keeps all 22 vulnerability checks fully isolated from each other, so touching SQL injection detection can't quietly break IDOR detection

It felt like unglamorous work at the time. In hindsight it's the actual engineering — the part that turns "I made a cool script" into "I built something someone else could depend on."

Learning to stop believing myself

The harder lesson underneath all of this: detecting something is the easy 80%. Not lying about it is the hard 20%.

Early SUDARSHAN would flag anything that looked suspicious and call it a finding. That's how you end up with a report nobody trusts, including you. So I split the pipeline into two honest stages — first, "does this look wrong," and only after that, "can I actually prove it's wrong." A result only becomes a real finding once it survives both. It's a small architectural line, but it's the difference between a tool that impresses people for five minutes and one that holds up when someone actually reads the report.

The feature I'm quietly proudest of

Once findings started numbering in the hundreds, I hit a new problem — nobody has time to open 180 separate proof-of-concept scripts for 180 IDOR findings. So instead of proving each finding alone, SUDARSHAN groups them by vulnerability type and builds one script per category that re-tests every related finding and reports back what still holds up.

pocs/
├── poc_DAST-001.py   # SQL Injection
├── poc_DAST-010.py   # IDOR — 180+ findings
└── poc_DAST-012.py   # XPath Injection — 130+ findings

pocs/
├── poc_DAST-001.py   # SQL Injection
├── poc_DAST-010.py   # IDOR — 180+ findings
└── poc_DAST-012.py   # XPath Injection — 130+ findings

It's a small idea, but it's the part of this project that feels the most like it came from actually using the tool myself, not just building it.

What I'd tell myself before starting this

If I could go back, I'd tell past-me: the vulnerabilities were never the hard part. You already knew how to find those. The hard part — the part that actually makes you better at this — is building something you can trust after you've broken it and fixed it a dozen times.

A scanner is easy to build once. Building one you don't have to re-verify every time you touch it is the actual craft.

Where SUDARSHAN goes from here

The next stretch is authentication-aware scanning and GraphQL testing, then a proper evidence vault with CVSS-based risk scoring, then SARIF output and GitHub Security integration so it can sit inside a real pipeline instead of running as a standalone tool. Slower progress than I'd like, but I'm not skipping the boring parts again.

Try it yourself

bash

git clone https://github.com/CalculusGuy/SUDARSHAN
cd SUDARSHAN/DAST_Engine
pip install -r requirements.txt
python main.py --target https://example.com --poc

git clone https://github.com/CalculusGuy/SUDARSHAN
cd SUDARSHAN/DAST_Engine
pip install -r requirements.txt
python main.py --target https://example.com --poc

Live demo: https://sudarshan-api-z66i.onrender.com Repo: https://github.com/CalculusGuy/SUDARSHAN

If you want to follow the journey:

GitHub: github.com/CalculusGuy Medium: medium.com/@nilanjan.calculus LinkedIn: linkedin.com/in/nilanjan-chowdhury-a36787359 My website: https://calculusguy.github.io/nilanjanchowdhury.github.io/

Building things, breaking things, and this time — actually trusting the results. 🔒

#CyberSecurity #DAST #AppSec #Python #OpenSource #DevSecOps #WebSecurity #EthicalHacking #InfoSec