SecuTron

SecuTron is an AI-powered security workspace that combines deterministic vulnerability detection with NVIDIA Nemotron on Nebius for intelligent explanations, remediation, and verification.

Comment

Inspiration

Security scanners can produce a long list of alerts without making it easy to see why an alert fired or where a developer should look. SecuTron was inspired by the idea that a useful early warning should show its evidence and its limits. We focused on a small, inspectable Python scanner whose findings can be reviewed locally, with an optional model explanation when a developer wants another way to understand one finding.

What it does

SecuTron scans Python and .env files for candidate hard-coded credentials, selected request-derived SQL, command, path, and code-execution flows, weak MD5/SHA-1 digests, and uses of Python's non-cryptographic random APIs. It reports file locations, sanitized evidence, confidence, and rule limitations in text, JSON, or SARIF. The local dashboard can run a scan and stream lifecycle and timing information. Developers can also use a fail-closed pull-request gate simulation and a repeated-scan benchmark.

An optional action sends one selected finding's allowlisted metadata and sanitized evidence to NVIDIA Nemotron through Nebius Token Factory for an explanation. The model does not detect findings or generate fixes. The hosted Vercel site is a static report viewer; scanning and model calls run in the local application.

How we built it

We built the scanner in Rust and used Tree-sitter's Python grammar to inspect source syntax. Deterministic rules look for a deliberately limited set of credential patterns and request-to-sink flows. We added intentionally vulnerable fixtures and secure negative examples so the scanner's known cases and misses are visible. The CLI emits JSON and SARIF, and the Axum/Tokio local server provides an authenticated loopback dashboard and WebSocket scan events.

For optional explanations, the local API sends only allowlisted fields for one finding to Nebius Token Factory's OpenAI-compatible inference endpoint, configured for NVIDIA Nemotron 3.5 Lightning (nvidia/Nemotron-3_5-Lightning). The prompt treats finding data as untrusted input and constrains the response. The dashboard displays provider/model details and returned latency and token usage. We also implemented a fail-closed PR gate, a repeated-scan benchmark, Docker Compose packaging, and CI. The public Vercel deployment serves report viewing only.

Challenges we ran into

The first challenge was keeping a source-to-sink rule useful without implying that a heuristic proves exploitability. The scanner currently follows simple local assignments in source order within a function; it does not resolve aliases, branch paths, sanitizers, or framework semantics. We addressed this by exposing evidence and limitations and by describing results as candidates.

The second challenge was keeping scanning local while making model assistance explicit and bounded. We kept the model out of the detection path and limited the optional request to one finding's allowlisted metadata rather than sending source files or a full report. We also had to distinguish the local application from the static Vercel viewer so the hosted site is not described as running scans or AI calls.

Finally, a correct security product should not claim that a clean scan means safe code. We designed the output, incomplete-scan behavior, and PR-gate simulation to make uncertainty visible and to fail closed when the scan is incomplete.

Accomplishments that we're proud of

  • A Rust CLI that scans supported Python and .env inputs and exports JSON and SARIF.
  • Source-to-sink evidence for a defined set of request-derived inputs, with rule limitations included in findings.
  • Vulnerable fixtures and secure negative examples, plus passing automated scanner and API tests.
  • An authenticated loopback dashboard with streamed scan lifecycle events and timing.
  • An opt-in Nebius Token Factory integration that sends one allowlisted finding for a Nemotron explanation and surfaces provider telemetry.
  • A fail-closed PR-gate simulation, benchmark command, Docker Compose setup, CI, and public MIT-licensed repository.

What we learned

We learned how much care it takes to make static-analysis results understandable without overstating what the analysis can prove. Tree-sitter gives us structured syntax to build focused rules, but useful taint analysis also needs control-flow, alias, framework, and sanitizer modeling that this prototype does not yet have.

We also learned to keep deterministic detection separate from generative explanation. A model can help explain a finding, but it should not silently become the authority that decides whether code is vulnerable. Bounded data sharing, explicit user action, and honest product boundaries matter as much as the model call itself.

What's next for SecuTron

Next we want to expand the test corpus, add safer and more precise flow modeling, and measure false positives and missed cases against a curated benchmark. We also want to improve setup and error feedback for the Token Factory integration and collect real usage measurements before making performance claims. Patch generation and isolated patch/test/verification are future work; they are not part of this release.

Built With

Share this project:

Updates

Submission history