A security tool that only finds the vulnerabilities its author expected is not very interesting.
So I'm trying something different with Aqiron Security.
I want other developers to find things that I missed.
Not because Aqiron is finished.
Quite the opposite.
It is still early enough that someone who spends an hour trying to break its assumptions could genuinely change the project.
Here's the challenge
Take a project you know.
Run Aqiron Security against it.
Then ask:
What should this have detected that it didn't?
That's the kind of issue I'm looking for.
Not:
"The UI looks nice."
Not:
"Cool project."
Something concrete.
A vulnerability pattern.
A false positive.
A missing rule.
A scanner result that gets lost during normalization.
A finding whose evidence isn't preserved the way you expected.
A workflow that makes security investigation harder than it should be.
Those are much more interesting.
Why I'm asking outsiders
I built most of Aqiron around assumptions.
Some of those assumptions are probably wrong.
That's unavoidable when the same person designs the scanner workflow, the finding model, the UI, the report structure, and the developer experience.
The dangerous part is that everything can look consistent internally while still being wrong externally.
A different developer brings a different codebase, different framework patterns, different expectations, and a completely different way of investigating a finding.
That's exactly what Aqiron needs.
What Aqiron is trying to do
The current system brings several security workflows into one developer-oriented interface.
The architecture currently looks roughly like this:
VS Code Extension
↓
Core Client / Process Manager
↓
stdin/stdout IPC
↓
Aqiron Core
↓
Scanners
↓
Findings
↓
Correlation / AI / RAG
↓
Reports
The idea is to separate the security runtime from the UI while still giving developers a fast workflow inside VS Code.
The scanning layer currently includes integrations such as:
- Trivy
- Betterleaks
- OSV-Scanner
- Semgrep
- MobSF
alongside Aqiron's own rules and Flutter/Dart-oriented analysis.
There are also optional AI workflows through Ollama and OpenRouter.
The important word there is optional.
Aqiron is intended to remain useful without requiring an AI provider.
But normalization creates an interesting problem
This came up in a recent discussion on my previous article:
How do you preserve scanner-specific evidence after normalizing everything into one finding model?
That's a much harder question than it initially sounds.
A common finding model is useful because different scanners can then be searched, displayed, correlated, and reported consistently.
But security scanners don't naturally produce identical information.
One tool may give you:
rule
severity
file
line
column
message
Another might provide:
rule
cwe
owasp
code snippet
metadata
confidence
Another may expose completely different evidence.
So there is a balancing act:
Too little normalization
↓
Every scanner stays unique
↓
Hard to correlate
Too much normalization
↓
Scanner context gets lost
↓
Harder to investigate findings
That's one of the areas where I think contributors can have much more impact than simply adding another button to the UI.
I want someone to challenge the model
Suppose you find a scanner result that Aqiron cannot represent cleanly.
That's interesting.
Open an issue.
Show:
Scanner
↓
Original result
↓
What Aqiron currently produces
↓
What information was lost
↓
What you think the model should preserve
You don't even need to implement the fix.
A good reproduction is already valuable.
There are other ways to attack the project
Find a missed vulnerability
Create a tiny reproducible vulnerable example.
Tell me:
Expected detection
Actual detection
Why it matters
That can become a regression test or a new security rule.
Find a false positive
This is equally valuable.
If Aqiron reports something that shouldn't be reported, show the smallest example that reproduces it.
Security tools need precision, not just more findings.
Break the scanner integration
Try unusual inputs.
Malformed output.
Unexpected paths.
Large files.
Multiple findings at the same location.
Scanner failures.
Anything that exposes a hidden assumption is useful.
Break the developer workflow
Try the extension as if you had never seen the code.
Can you:
create workspace
↓
configure
↓
scan
↓
investigate
↓
understand evidence
↓
export report
without having to stop and figure out how the application works?
If not, tell me where the friction is.
Improve the rules
You don't need to understand the entire codebase to add value.
A focused security rule, regression test, scanner improvement, or documentation PR is enough.
One thing I don't want
I don't want contributors making changes just to make the repository look busy.
Aqiron doesn't need:
50 meaningless commits
It needs:
one contributor who finds something I didn't see.
That's a much better outcome.
Where the project is right now
Aqiron is still early.
The current primary client is the VS Code extension, backed by a TypeScript/Node security core.
The UI now has dedicated workflows for:
Scan
Findings
Reports
Agent
Settings
Workspace
The reporting layer can produce PDF, JSON, and SARIF output.
The project also has scan history, finding triage, correlation, and optional AI/RAG functionality.
But none of that means the system is finished.
I'd rather be very clear about that.
So here's my invitation
Don't come to Aqiron because I said it's good.
Come because you're curious whether it actually holds up.
Run it.
Read the code.
Try a weird project.
Try an unusual vulnerability.
Question the finding model.
Question the scanner architecture.
Question the UI.
And when something doesn't make sense, open an issue and show me why.
That is exactly the kind of contribution that can shape an early security project.
Aqiron Security
GitHub: https://github.com/Aqiron-Security/aqiron-security
The most useful comment you could leave is not:
"Looks great."
It's:
"I found something you missed."
I'm hoping someone does.
