DEV Community: Developer Open

What Is Aqiron Security Missing? I Want You to Find Out.

Developer Open — Tue, 29 Sep 2026 15:29:45 +0000

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.

I Built a Security Workbench for Flutter. Now I Want Developers to Break It.

Developer Open — Mon, 28 Sep 2026 13:27:55 +0000

I have spent a lot of time building Aqiron Security.

Then I realized something uncomfortable:

I know how it behaves on my machine. I don't know how it behaves in the hands of developers I have never met.

That's the part I want to change.

Aqiron Security is an open-source, local-first application security tool that currently runs as a VS Code extension, with an initial focus on Flutter workspaces.

The idea is simple:

Instead of making a developer jump between several security tools, output formats, terminals, and dashboards, Aqiron tries to bring the workflow into one place.

But the project is still early.

Scan

Findings

Generated pdf

and there goes.. the remaining images of the pdfs generated(sample) are one aqiron security repo README.md

And that's exactly why I'm writing this.

The security workflow I wanted

A typical project can involve completely different tools for:

static analysis
dependency vulnerabilities
leaked secrets
mobile security testing
custom security rules
AI-assisted analysis
reports

The problem isn't that these tools don't exist.

The problem is what happens between them.

Different output formats.

Different severity models.

Different workflows.

Different places to investigate a finding.

Aqiron's current architecture is built around a TypeScript core that the VS Code extension communicates with through a separate Node.js process:

VS Code Extension ↓ Core Client / Process Manager ↓ stdin/stdout IPC ↓ Aqiron Core ↓ Scanners → Findings → Correlation → AI/RAG → Reports

The goal is to keep the security runtime independent from the UI while giving developers a fast workflow inside VS Code.

What exists today

Aqiron can currently scan supported Flutter workspaces or individual files and expose findings through VS Code and the Aqiron interface.

The implementation includes native security rules plus optional integrations such as:

Betterleaks
OSV-Scanner
Semgrep OSS
Trivy
MobSF

It can normalize and correlate findings, build a relationship graph, maintain workspace intelligence through RAG, and generate JSON, SARIF, and PDF report artifacts.

There are also optional AI workflows through Ollama or OpenRouter.

The project is local-first, and those external scanners and AI providers remain optional.

I'm deliberately saying current because some ideas are still future work.

Then I rebuilt the interface

Recently I stopped adding features for a moment and asked a different question:

Would I actually want to use this every day?

The answer was not initially good enough.

So I redesigned the major workflows.

Scan

The Scan workflow now follows a simpler progression:

Workspace ↓ Target ↓ Scan mode ↓ Start scan ↓ Execution ↓ Results

Findings

The findings screen became a triage workspace instead of a basic list.

Search, severity, source, status, file/line context, evidence, remediation information, and finding actions are surfaced around the actual security result.

Reports

The reporting workflow now exposes PDF, JSON, and SARIF outputs alongside the assessment context and report history.

The PDF itself is intended to look like an actual security assessment rather than a raw export of scanner output.

Agent

The AI interface was redesigned as part of the same workspace instead of feeling like a completely separate feature.

Workspace and Settings

I also rebuilt the workspace-entry and Settings experience so configuring the project and security tooling feels like part of the same application.

But here's the problem

All of that is still mostly being developed by one person.

And that's dangerous for a security project.

A security tool can look polished while still having:

missing detection rules
false positives
false negatives
awkward developer workflows
scanner integration problems
weak tests
poor documentation
platform-specific bugs
assumptions that only make sense on the maintainer's machine

I can keep adding features.

That's not necessarily what Aqiron needs next.

It needs other developers trying to use it.

I don't want you to just star the repository

Honestly, a star would be nice.

But it isn't the thing I'm looking for.

I'd rather have someone open an issue and say:

"This workflow doesn't make sense."

or:

"This scanner should catch this."

or:

"I tried this on my Flutter project and found a bug."

or even:

"Why did you design the architecture this way?"

Those conversations are much more valuable than a silent star.

Where contributors could actually help

You don't need to understand the entire codebase before contributing.

There are several directions that would be useful:

Security rules

Find a vulnerability pattern Aqiron currently misses and propose or implement a rule.

Scanner integrations

Improve an existing scanner integration or help make another security tool fit into Aqiron's normalized finding model.

False positives

Take a finding that shouldn't have been reported and help make the detection more precise.

Tests

Add regression tests around scanners, finding normalization, workspace behavior, IPC, or UI workflows.

UI/UX

Try the extension like a real developer and point out where the workflow feels confusing, slow, or unnecessary.

Documentation

Improve setup instructions, scanner configuration, examples, or contributor onboarding.

You don't have to start by rewriting the core.

I'd actually prefer a small, focused pull request that teaches us something.

The part I'm curious about

The project started with Flutter because that's where I wanted to solve the problem first.

But I'm increasingly interested in a bigger question:

Can a developer-focused security workflow have one common security runtime while supporting multiple clients?

Today the main client is VS Code.

The architecture is intentionally moving toward a model where the security core can eventually serve other clients without making the core itself depend on VS Code.

That could eventually mean:

           `  Aqiron Security Core
            /     |      \
      VS Code    CLI    Desktop`

But that's future architecture, not the current repository structure.

Right now, I want to make the existing system good enough that other developers actually want to use it.

So I'm opening the door

Aqiron Security is early.

That means there are plenty of things that can be improved.

It also means a contributor can have a real impact on the direction of the project instead of becoming one tiny commit in a repository with thousands of contributors.

I'm looking for developers interested in:

security + TypeScript + VS Code + Flutter + developer tooling + AI-assisted security

You can inspect the code, run it, criticize it, open an issue, improve documentation, add a test, add a rule, improve an integration, or send a pull request.

I want the project to become better because other developers used it and challenged the assumptions behind it.

Aqiron Security

GitHub: https://github.com/Aqiron-Security/aqiron-security

If you are interested, don't just tell me that the idea is cool.

Try to break something.

That's probably the most useful contribution you can make right now.

I'm interested in hearing how others approach the boundary between a VS Code extension and a separate Node.js/TypeScript runtime.

Developer Open — Wed, 23 Sep 2026 14:54:04 +0000

Developer Open for Aqiron Security

Sep 23

Separating a VS Code Extension from a TypeScript Core: Architecture Lessons from Aqiron Security

#typescript #vscode #opensource #node

7 min read

Separating a VS Code Extension from a TypeScript Core: Architecture Lessons from Aqiron Security

Developer Open — Wed, 23 Sep 2026 14:51:53 +0000

When I started building Aqiron Security, the natural approach was to keep the security logic inside the VS Code extension.
That works.
At least initially.
But as the project started accumulating scanner orchestration, finding normalization, correlation, project intelligence, RAG, reporting, and AI operations, I started running into a deeper architectural question:

Should the VS Code extension actually own the application's core runtime?

I decided the answer should be no.

Aqiron Security is an open-source application security project. The current product is a VS Code extension, but I wanted the security/runtime layer to have a much cleaner boundary from the client.

The result is a design where the extension acts as the client and starts a separate Node.js process containing the TypeScript core.
This article explains why I made that separation, how the current architecture works, and some of the trade-offs I have encountered.

The original problem

A VS Code extension has a lot of responsibilities already.

It deals with things like:

extension activation
commands
diagnostics
the VS Code API
webview communication
editor state
user settings
UI lifecycle

Security scanning introduces another class of responsibilities:

starting external tools
parsing scanner output
normalizing findings
correlating duplicate results
generating reports
managing long-running operations
cancellation
AI operations
workspace analysis

Putting all of that into one runtime makes the boundary blurry.
The code may still work, but over time the architecture starts answering questions like:

"Does this security service need VS Code?"

That is a dangerous dependency to create if the answer does not actually need to be yes.

The separation

The current Aqiron architecture looks roughly like this:

┌──────────────────────────────────────────────┐ │ VS Code Extension │ │ │ │ activation / commands / diagnostics │ │ React webview / settings / workspace UI │ │ ScanController / client-side services │ └──────────────────────┬───────────────────────┘ │ │ CoreClient │ CoreProcessManager │ │ newline-delimited JSON ▼ ┌──────────────────────────────────────────────┐ │ Aqiron Core Runtime │ │ Node.js + TypeScript │ │ │ │ protocol / cancellation / adapters │ │ scanning / analysis / correlation │ │ reports / RAG / AI operations │ └──────────────────────┬───────────────────────┘ │ ┌────────────┴────────────┐ ▼ ▼ Native Aqiron rules External scanners Trivy / Semgrep OSV-Scanner / Betterleaks / MobSF │ │ └────────────┬────────────┘ ▼ Unified findings ▼ correlation + graph ▼ reports

This is not a cloud architecture.

The current project is local-first. The extension starts the core process locally and communicates with it over standard input/output. The repository currently keeps packages/core private and bundles it into the extension rather than publishing it as a separate npm package.

That distinction is important.

The boundary exists today, but the eventual product packaging can evolve later.

Why a separate process?

There were several reasons.

1. Keep the core independent from VS Code

The first reason is architectural independence.
The core should not need to know that VS Code exists.
Ideally, security logic should be able to operate on concepts like:

workspace scan finding project report AI request

rather than:

vscode.workspace vscode.window WebviewPanel TextDocument DiagnosticCollection

The extension is responsible for translating between the developer environment and the core.

That gives me a much cleaner dependency direction:

VS Code client ↓ Core

rather than:

VS Code ↔ Security logic ↔ VS Code

2. Process isolation gives us a real boundary

Using a separate process also creates a runtime boundary.

The extension host and the security core no longer execute as one giant logical process.

That matters for long-running operations.

A scan might involve:

discover files ↓ run multiple tools ↓ parse results ↓ normalize findings ↓ correlate findings ↓ build relationships ↓ generate reports

That's a very different workload from handling an editor command or updating a sidebar.

With a separate core process, the extension can treat the security engine more like a service.

That makes lifecycle handling, restart behavior, and failure boundaries easier to reason about.

3. IPC forces us to define a contract

This was probably the most valuable part of the architecture.

Once the extension and core became separate processes, they couldn't casually call each other's internal functions anymore.

They needed a protocol.

The current protocol is intentionally simple:

stdin/stdout + newline-delimited JSON

A request looks conceptually like:

interface CoreRequestMessage {
  id: string;
  type: "request";
  method: string;
  params?: unknown;
}

And a response:

interface CoreResponseMessage {
  id: string;
  type: "response";
  success: boolean;
  result?: unknown;
  error?: CoreProtocolError;
}

There are also event messages for asynchronous pipeline updates:

interface CoreEventMessage {
  type: "event";
  event: string;
  requestId?: string;
  payload?: unknown;
}

The actual protocol also has a versioned handshake.

For example, the current runtime exposes a protocol version and core version and can report compatibility states such as:

compatible protocol-mismatch extension-too-old core-too-old unsupported

That gives us an explicit compatibility boundary instead of relying on both sides silently assuming they agree.

Why newline-delimited JSON?

I deliberately didn't start with something complicated.

The current transport is essentially:

message 1\n message 2\n message 3\n

where each line contains one JSON message.

That gives us a few useful properties:

Easy to inspect

You can literally look at the communication stream.

Easy to debug

Malformed input can be identified and rejected.

No additional server required

The extension starts the process locally and communicates through stdio.

Language-neutral at the protocol level

The wire format is JSON rather than TypeScript-specific objects.

That last point matters.

The implementation is TypeScript, but the protocol doesn't fundamentally need to be.

Correlation IDs become important

Once requests and responses cross a process boundary, we need a way to know which response belongs to which request.

That's why requests carry an ID.

For example:

request id: abc123 method: scan.start

The response can return:

id: abc123 success: true

Without this, concurrent operations become painful to reason about.

The ID becomes the connection between:

request
↓
core operation
↓
response

and also gives us something useful for cancellation and pipeline events.

Cancellation is part of the architecture

Security operations shouldn't be treated as unstoppable functions.

Imagine starting a deep scan and then closing the workspace.

Or starting an AI analysis and then deciding you don't need it anymore.

The architecture therefore includes explicit cancellation operations.

The current core protocol exposes operations such as:

core.cancel scan.cancel ai.cancel

and the runtime propagates cancellation through the relevant cancellation sources and scanner context.

This is one of those details that seems unnecessary until you have a real long-running operation.

Then it becomes essential.

The extension should not know how scanning works

One of the goals of the boundary is to let the client ask for a scan without knowing the implementation details.

Conceptually:

await coreClient.startScan({
  workspaceRoot,
  mode: "deep",
  trusted: true
});

The extension doesn't need to know:

which scanners are installed
how scanner output is parsed
how findings are normalized
how correlation works
how reports are generated

Those concerns belong to the core pipeline.

The current core pipeline can combine native Aqiron rules with optional external scanners, normalize results into UnifiedFinding[], then pass them through correlation/graph processing and report generation.

That separation is the main reason I like this architecture.

The finding model becomes the shared language

A scanner may produce one format.

Another scanner produces something completely different.

For example:

Scanner A severity = HIGH file = foo.dart line = 41

while another might report:

Scanner B level = error path = foo.dart startLine = 41

The core shouldn't force the rest of the system to understand every scanner's native format.

Instead, scanner-specific parsers convert the output into a common model.

Conceptually:

external scanner ↓ scanner-specific parser ↓ UnifiedFinding ↓ correlation ↓ report

This is one of the biggest advantages of having an application-level core rather than scattering scanner logic throughout the VS Code extension.

The architecture isn't completely finished

This is important because architecture diagrams can easily make an early project look more mature than it actually is.

Aqiron is currently version 0.0.1 and under active development.

There are still intentional limitations.

For example:

workspace operations currently require a Flutter workspace
external scanners are optional
the core is still bundled into the extension
quick file scans use a separate direct extension path
the project does not yet have independently published Core, CLI, or Desktop packages

So the current architecture is not:

`Aqiron Core npm package
↓
VS Code
CLI
Desktop

Not yet.

It's closer to:

VS Code
↓
internal Core process
↓
bundled runtime`

That is an important distinction.

The architecture is being prepared for broader reuse without prematurely creating a bunch of packages that don't yet need to exist.

Why I didn't immediately split everything into repositories

This was another deliberate decision.

It would be easy to say:

aqiron-core aqiron-security-vscode aqiron-security-cli aqiron-security-desktop

and create four repositories immediately.

But that would add operational complexity before the products existed.

You would now have to manage:

package publishing
version coordination
cross-repository changes
release synchronization
dependency management
contributor workflow across multiple repositories

The current repository gives me a cleaner intermediate step:

src/ packages/core/

with an explicit runtime boundary.

When multiple clients become real products, the repository structure can change.

Until then, the architecture can evolve without forcing the project to pay the cost of premature distribution.

What I like about this architecture

The biggest win isn't actually "using IPC."

The bigger win is making the boundary explicit.

The VS Code extension owns the developer environment.

The core owns security operations.

The protocol connects them.

That gives us a mental model like:

`Client responsibilities
↓
UI
VS Code
commands
diagnostics
workspace interaction

      │
      │ protocol
      ▼

Core responsibilities
↓
scanning
normalization
correlation
RAG
AI operations
reports
`

That's much easier to reason about than a single giant extension runtime.

What I still need to watch

The architecture also introduces new problems.

A process boundary is not free.

Now we have to care about:

process startup time

restart behavior

malformed messages

protocol compatibility

stderr/stdout handling

partial failures

cancellation

shutdown

concurrent requests

serialization overhead

In other words:

We traded code coupling for process-boundary complexity.

I think that's a reasonable trade for Aqiron, but it isn't automatically the right choice for every VS Code extension.

If your project is a small command-based extension with a few hundred lines of logic, this architecture would probably be overkill.

For a growing security platform with multiple subsystems and long-running operations, the boundary becomes much more interesting.

The bigger goal

The long-term idea is not "make a complicated VS Code extension."

It's to make the security core reusable.

The future might eventually look like:

                Aqiron Core
               /     |      \
              /      |       \
             ↓       ↓        ↓

         VS Code    CLI     Desktop

But I don't need to build all three clients today.

Right now, I'm using the VS Code extension as the first real client and using the Core boundary to keep the architecture ready for future evolution.

That's the part I'm most interested in getting right.

Final thoughts

The biggest lesson I've taken from this project is that architecture isn't about drawing the biggest possible diagram.

It's about deciding where responsibilities should stop.

For Aqiron, the important boundary became:

VS Code is the client.
The TypeScript runtime is the security engine.
IPC is the contract between them.

That doesn't mean the architecture is finished.

It means there is now a clear place to evolve it.

I'm still working through the trade-offs, so I'd be interested in hearing from people who have built:

VS Code extensions with external processes

TypeScript/Node developer tools

language-server-style architectures

security scanners

CLI + GUI products sharing a common runtime

How would you design this boundary differently?

Aqiron Security is open source and currently under active development.