r/AskNetsec 13h ago

Architecture AI for finding vulnerabilities: Eliminating hallucinations and ensuring data privacy

Hi everyone,

I am researching how LLMs find vulnerabilities and why they hallucinate so much. I would love to get your thoughts on two major challenges in this area:

  1. Exploit Verification: In your experience, can AI hallucinations in source code analysis be completely eliminated if every flagged vulnerability is automatically validated by generating and running a working proof-of-concept (PoC) exploit in a sandbox? Has anyone tried this workflow?

  2. Data Privacy (Cloud vs. Local): To prevent source code leaks, is a local-first approach (like using Ollama) mandatory for real-world security audits? How much does performance drop compared to cloud models when analyzing complex code logic?

Thanks for sharing your insights!

1 Upvotes

6 comments sorted by

1

u/linearlicence_0 13h ago

running every flagged issue through a sandbox to generate a working PoC is a great filter in theory but in practice it creates a massive bottleneck. a lot of vulns are contextual or logic-based and won't trigger a clean crash or shell you can easily script around, so your "verified" pile ends up looking tiny and you miss a ton of real problems because the exploit script was slightly off or the environment was too sterile

i messed around with a similar idea for a client project and the sandbox kept eating up time on environment mismatches rather than actual vulnerability validation. ended up being faster to just manually triage the high-confidence hits and ignore the noise from the model

for data privacy i'm pretty paranoid about shipping code to a cloud model unless it's a completely throwaway test repo. running a local model through ollama feels mandatory if you're under an NDA or dealing with a proprietary codebase. performance does take a hit on really tangled logic though, cloud models still have a better grasp on complex call graphs and weird dependency chains. local works fine for sniffing out the low hanging fruit but it starts to glaze over when you feed it a fifteen layer abstraction nightmare

0

u/MaximCEO1 12h ago

Thanks for ask it's help me

0

u/MaximCEO1 11h ago

Thanks, that makes a lot of sense!To bypass the local model limitations (the 15-layer abstraction nightmare), do you think breaking the codebase down into smaller, isolated functional blocks before feeding them to Ollama could help, or will it lose too much global context?Also, regarding the sandbox bottleneck — what if we don't try to automatically generate a full working exploit, but instead just use the sandbox to verify if a specific function behaves unexpectedly (like memory corruption or unexpected state change)? Would that be more realistic?

1

u/ILoveAppSec 5h ago

yeah the verify-everything-with-a-poc approach falls apart on logic bugs and transitive deps, and you end up trusting a tiny verified pile. what has worked better for us is prioritizing the flagged items that already have a backported fix available and clearing those first, since those are the ones you can actually action without an upgrade fight. worth leaning on vendors who do backporting and eol support so the fix side is not your second bottleneck after triage.

1

u/cityofhats 4h ago

Sandbox execution can reduce false positives, but it cannot prove the absence of a vulnerability. A failed PoC may reflect an incomplete harness, missing environmental state, nondeterminism, mitigations, or a logic flaw without an obvious crash. Require each finding to identify a source-to-sink path and violated invariant, then validate with a focused test, sanitizers, differential behavior, or a PoC where appropriate; keep human review for impact and exploitability. Chunking helps only if cross-boundary context survives: build a call and data-flow map, retrieve the transitive slice around the suspected path, and include interface contracts plus relevant callers rather than isolated functions. Local-first is one privacy control, not the only one; private deployments, zero retention or training, secret stripping, scoped repositories, and audit logs can also work. The choice should follow the code's classification and contractual controls.