Everyone is racing to add AI into security tooling.
I decided to build something in the opposite direction.
Over the last few months I've been building Sinkline, a deterministic security scanner for Python that never sends code to the cloud and never relies on an LLM to decide whether something is malicious.
Instead of asking "Does this code look dangerous?" it asks:
Where did this data come from, and where does it end up?
That single design decision changed everything.
The Problem
Most static analyzers are excellent at finding classic vulnerabilities:
SQL Injection
Command Injection
Weak hashing
Unsafe deserialization
Hardcoded credentials
Those are solved problems.
The attacks becoming common today are different.
Think about things like:
credentials quietly exfiltrated through multiple modules
install-time payloads
logic bombs
environment-triggered malware
typosquatted dependencies
base64/XOR encoded payloads
These aren't obvious from a single file.
Source → Sink
The name Sinkline comes from taint analysis.
A source is where sensitive information originates:
environment variables
secrets
API keys
user input
A sink is where dangerous actions happen:
requests.post()
os.system()
subprocess
exec()
The interesting question isn't whether either exists.
It's whether there is a path connecting them.
Example:
os.environ["AWS_SECRET"]
│
▼
config.py
│
▼
helper.py
│
▼
telemetry.py
│
▼
requests.post(...)
Every file can look perfectly harmless.
The dangerous behavior only appears when you connect them together.
Why No AI?
Recent research has shown that LLM-powered scanners can themselves become attack targets.
If malicious packages know they're being inspected by an AI, they can attempt prompt injection inside source code or comments.
Instead of trying to outsmart that problem, I removed it.
The detection engine is:
deterministic
offline
explainable
reproducible
Same input.
Same output.
Every time.
What It Detects
Besides common OWASP issues, Sinkline looks for:
cross-file credential exfiltration
probabilistic logic bombs
encoded payloads
install/import-time execution
typosquatted dependencies
import-correlated secrets
environment-gated malware
The goal isn't more alerts.
The goal is higher-value alerts.
A Built-in Demo
One thing I disliked about security tools is that they often demonstrate themselves on tiny 3-line examples.
Real attacks aren't like that.
So the repository includes a realistic multi-file demo project where:
every individual file looks normal
the malicious behavior only appears after tracing data across modules
That's a much better test of whether taint analysis actually works.
Design Decisions
Some principles that guided the project:
Local-first
No telemetry
No cloud processing
No LLM dependency
Deterministic output
SARIF support
CI-friendly exit codes
Explainable findings
If a finding cannot be explained, it's difficult to trust.
Things It Doesn't Try To Do
Sinkline isn't trying to replace:
CodeQL
Bandit
Semgrep
Those tools are excellent.
Instead, it focuses on areas where deterministic cross-file analysis can provide additional signal, particularly for stealthier supply-chain style attacks.
Lessons Learned
Building a security scanner taught me that detection is only half the problem.
The harder challenge is reducing noise.
Developers stop trusting tools that constantly cry wolf.
Finding the right balance between recall and false positives turned out to be far more difficult than implementing another detection rule.
Open Source
The project is open source and still evolving.
Repository: https://github.com/Dinesh431786/sinkline
I'm particularly interested in feedback on:
taint propagation
detection strategies
benchmark methodology
false positive reduction
performance optimizations
If you've built static analysis tools before, I'd love to hear your thoughts.
Security is one of the few areas where deterministic engineering still has enormous value, and I think there's plenty of room for approaches that don't depend on AI.
Top comments (0)