Four NASA + ESA Repos, Audited in 205 Seconds: What KCode Found

What we set out to do

The KCode README has carried a single replication of our audit engine since launch: 28 bugs found and patched in a prior NASA-repository audit. One repo, one case study, no statistical confidence. Useful as a proof of life, useless as a proof of impact.

This was the second data point. Four more repos, picked because they're recognizable: real flight software, a real mission-control framework, a real satellite-mission server, and a real Earth-science data pipeline. All open-source, all under heavy ongoing development by competent teams, all of them already running their own security tooling. Public, resolved findings are named here; findings still under private disclosure are described by bug class only.

The campaign brief was simple: run the audit, ship every finding through its appropriate channel — public PRs for hygiene issues, private disclosure for anything exploitable — and write down what happened. Including the parts that didn't go well.

The pipeline, briefly

KCode's audit runs two phases:

1. Static scan — 441 hand-written patterns (387 regex + 54 AST via tree-sitter) run against the source tree. Produces a large pool of candidates, most of which are noise. ~50 seconds on a typical 1,000-file repo.
2. LLM verifier — every candidate goes to a language model with its file context attached. The model answers a single, focused question per candidate: "is this real?". Returns one of three verdicts: confirmed, false_positive, needs_context. This is what kills the false-positive tsunami.

For this campaign the verifier ran on Grok 4 Fast (non-reasoning mode) with a batch size of ten candidates per call and ten calls in flight concurrently. Pure cloud, no local GPU involved. The total cost across the four audits was well under a dollar.

The headline: an accepted security advisory in NASA JPL flight software

The finding that matters most came out of F´ (F Prime) — NASA JPL's open-source flight-software framework, the kind of code that ends up on hardware leaving Earth. KCode surfaced a pattern where FW_ASSERT is used to validate untrusted input at four independent call sites (ground-loaded sequence files and inter-component port arguments). Because FW_ASSERT is compiled out under FW_NO_ASSERT builds — commonly used for flight images that strip asserts for footprint — that validation silently disappears in deployed binaries, letting malformed input propagate with inconsistent internal state (CWE-617).

We filed it through the framework's private vulnerability-reporting channel. A collaborator accepted it in nine hours:

"Thank you for your thorough and well-documented advisory. We concur with your findings and we are formally accepting them. […] When the fix is released, I will create a CVE acknowledging you as the reporter."

NASA F´ accepted all four findings, resolved them in F´ v4.3, and published the advisory as GHSA-x8cp-v4fr-fg2x, crediting AstroLexis · Kulvex Code (Bruno Aiub) as the reporter, with a CVE requested through GitHub's CNA. A published security advisory in flight software, accepted on first contact and credited — that is the result you hope for and rarely get.

The rest of the 25, by class

The remaining findings split by channel. The public ones live on the public record; the still-private exploitable findings stay described here by class only, so maintainers can coordinate fixes without a weaponisable writeup.

• CI/CD hygiene (public PRs): GitHub Actions pinned to mutable refs instead of commit SHAs (CWE-829) — the same class exploited in the March 2025 tj-actions supply-chain attack that hit ~23,000 workflows. Filed as public pull requests.
• Robustness (public PR): bare except: handlers swallowing SystemExit/KeyboardInterrupt (CWE-396).
• Exploitable, still private: ReDoS via unbounded attacker-influenced RegExp construction, and SSRF via unvalidated user-controllable fetch URLs. Sent through private security channels, still awaiting resolution, and kept out of this post until they are.

The one uncomfortable data point: one public hygiene PR was closed without merging and tagged "AI slop". We did not appeal it. The change was purely stylistic, the PR description read as auto-generated, and drive-by external PRs with AI-tool attribution are a recognizable shape of low-quality submission in 2026. We replied acknowledging the call and offered the security-class findings from the same audit through private channels.

If the next 99 PRs land cleanly, the one labeled "AI slop" is a fair data point. If 50 of the next 99 get the same label, the labeling is the data point. We don't know yet.

The loop, dogfooded

Every step of this campaign used KCode against KCode.

• Discovery — KCode's regex+AST scanner plus the LLM verifier.
• Fix authoring — KCode's agentic mode (Claude Sonnet 4.5 via kcode --print). The model reads the audit report, applies edits to the right files with the Edit tool, runs git diff to verify itself.
• Pull requests — gh pr create from the same agent loop, each commit signed-off AstroLexis · Kulvex Code with the audit report linked.
• Disclosure drafts — KCode wrote the three private-channel reports (two vendor-security emails and one GitHub Security Advisory) in markdown, including the AI-tooling disclosure markers the projects' security policies ask for.

The most interesting moment was a small one. During one repository's fix pass, the agent declared "✓ all edits applied" in its summary — but it hadn't actually called the Edit tool for that turn. KCode's internal anti-fabrication guard fired immediately and surfaced a "REALITY CHECK" warning, refusing to let the false completion claim go uncorrected. We re-ran the turn and the edits actually applied.

An anti-fabrication guard catching a hallucination by KCode's own agent — written into KCode for exactly this scenario — is the kind of dogfood moment that's hard to fake.

Engine improvements shipped the same day

While running this campaign we shipped five algorithmic commits to the audit engine. The two most consequential:

String-literal awareness. The static scanner used to flag text inside string literals as candidates. Three of our own self-audit findings turned out to be the engine catching verify_prompt string content in another pattern file. We added a tree-sitter pass that pre-computes string-literal byte ranges and drops matches that fall inside one (unless the pattern opts in to "I want string content"). Drops 37% of static candidates with zero true-positive loss on the locked benchmark.

Snippet hash cache. Every verifier verdict is logged to ~/.kcode/audit-history.db keyed by normalised (pattern_id, snippet). After three samples with ≥80% agreement, the verifier is skipped entirely for that snippet. The cache earned its keep mid-audit: in one repo, five of nine bare-except findings returned [cache hit: N prior samples agree] and skipped the model.

Together the five commits moved the engine's real-world precision from 9.5% (baseline against KCode itself two days earlier) to 38% on the same codebase. The locked-benchmark numbers — precision 100%, recall 92.3%, F1 0.960 — were unchanged throughout. The point of a locked benchmark is to refuse to move when the engine improves.

What this campaign cost, and what it produced

The verifier downgraded 89.6% of static candidates as false positives. That number is the value the LLM verifier adds: a deterministic regex/AST scan produces a 90% noise rate; a focused one-question-per-candidate model call brings it down to single-digit percent.

Cost: under fifty US cents in xAI API spend across the four audits. The model is priced low enough that the audit's bottleneck is no longer cost or wall time — it's the human triage of confirmed findings, plus the responsible-disclosure paperwork.

Why we ran this campaign

There's a Phase 1 milestone in the KCode roadmap that says "10 paying subscribers." We have zero today. The technical product is disproportionately mature for the user base, which is a distribution problem, not an engineering problem.

The honest move is to give people something to look at. "We scanned NASA and ESA repos in three minutes and found 25 real bugs, and one is now a published CVE" is something to look at. The 28 bugs in NASA IDF was the first proof point. This is the second. The plan is to keep going — top-100 npm, top-100 PyPI, top-100 Go modules — until the evidence is easier to point at than to argue with.

If you want to try the tool, KCode is open source under Apache 2.0: github.com/AstrolexisAI/KCode. The audit runs locally by default; the cloud-verifier mode used in this campaign is opt-in.

curl -fsSL https://kulvex.ai/kcode/install.sh | sh
cd your-project
kcode audit .

The disclosure ethics

The rule here is simple: hygiene fixes ship publicly because publishing them doesn't weaponise anything; ReDoS, SSRF, and the assertion-vanishing items go through private channels because publishing them does, and we'd rather give maintainers room to coordinate a fix than score a click. The public pull requests live on the public record under their respective projects. The private disclosures — including the one now published as a CVE — stay described here only by aggregate count and bug class, per that same policy.

KCode audit engine and the agentic edits were performed by AstroLexis · Kulvex Code. Findings written to disk by AI; humans pressed "send." For questions: contact@astrolexis.space.