Dvalincode

English · 中文 · 🌐 dvalincode.dev

Open security engineering for code written by humans and AI agents.

Every repair carries its own proof.

When an agent fixes a security finding, someone has to decide whether the fix worked. Almost every tool asks the model that wrote it — which is the one question a model cannot answer against its own interest.

Dvalin decides instead, and hands you the proof. It re-scans, runs your project's own tests itself, and reads the exit codes from processes it started. Who wrote the repair — our agent, Claude Code, Codex, Copilot, a person — is recorded and never consulted. The result is a Verified Fix Record: a small JSON file anyone can re-check offline, on a laptop with no network and no Dvalin state.

dvalin verify-fix fix-record.json

Fix record 2c9d71ac03e0 · VERIFIED · scan-and-checks

executor: claude-code (recorded, not consulted) targets: 1 before · 0 remaining coverage: complete → complete introduced: 0 (gate high/new) outcome: verified ✓ test: npm run test (exit 0) audit: run verify-36509f42 @ 414644c75af0

That record says something narrow on purpose: *these findings were gone, and these checks were observed to pass.* It is not a claim that your code is safe, and Dvalin will not let it be read as one — every record carries what the scan actually covered, and a repair no check could confirm does not pass. The open profile →

A repair is a change, and a change can add as well as remove. So the record also carries what the re-scan saw that the first scan did not, and the gate threshold the verdict was reached under: a fix that removes an eval and introduces an SQL injection is recorded as regressed and does not verify. Neither does a record whose issuer never looked — introduced: not determined fails, because a verifier that skips the question must not score better than one that asks it and finds something.

Dvalin is the independent security runtime between code generation and merge. Humans, coding agents, and CI call the same versioned contract for discovery, remediation, and verification. It runs independently, or interoperates with specialist systems such as Codex Security through sealed scan artifacts or portable SARIF. Its built-in coding capability is a remediation executor — not the trust boundary, and not an attempt to compete with every general-purpose coding agent. See the security-agent strategy.

---

⏱️ 30 seconds, no install, no API key

npx dvalincode security scan .

After installing the package: dvalin scan .

That is the whole thing. It runs the built-in rules for injection, hardcoded secrets, XSS, eval, and unsafe shell use against the current directory and prints what it found. No account, no model, no config, no code leaves your machine. The default policy runs only Dvalin Built-in, so the first scan always works. Add optional engines explicitly, or inspect their fixed install commands:

dvalin scanners list

dvalin scanners install semgrep # review the command dvalin scanners install semgrep --yes # execute it under Dvalin policy

Make it the gate in one step

dvalin init

init writes dvalin.security.json (fail on *new* findings at high or above), names the checks your project actually has (test, typecheck, build, lint) as what Dvalin runs before it calls a fix verified, records today's findings as the accepted backlog in .dvalin/baseline.json, and writes a CI gate for GitHub (.github/workflows/dvalin.yml) or GitLab (.gitlab/dvalin-security.yml, with a Code Quality report for the merge request widget). It never overwrites a file that is already there unless you pass --force. Commit what it wrote, and the backlog stops blocking anyone: only what a change adds fails.

To gate every commit locally too, add the pre-commit hook:

# .pre-commit-config.yaml

repos:

• repo: https://github.com/arthurpanhku/dvalincode rev: v0.22.0 # the hook ships in v0.22.0 hooks:
• id: dvalin-scan # or dvalin-scan-installed, to use the CLI you installed

Measure with the scanner your CI gate uses

If Snyk is what blocks your merges, verify against Snyk. A fix judged "clean" by a different engine is a fix the gate can still reject, and that mismatch is what turns one agent repair into several rounds of push, fail, and rebase.

npm install -g snyk && snyk auth      # or set SNYK_TOKEN

dvalin scan . --scanners builtin,snyk-code,snyk-oss

snyk-code (SAST) and snyk-oss (dependencies) are engines like any other: their findings carry the same fingerprints, coverage and gate, and a failed login is reported as an engine error, which makes the scan partial, never clean. They run only when named, because Snyk Code uploads source to Snyk. Name them in dvalin.security.json to make them part of the policy, and reverify will judge every fix with them.

If GitHub code scanning is the gate, use CodeQL the same way:

dvalin scan . --scanners builtin,codeql

codeql builds one database per language outside the workspace and runs that language's default code-scanning queries, so its findings are the ones the gate reports. JavaScript/TypeScript, Python, Ruby, Java and C# are analysed without a build; Go uses CodeQL's autobuild. Kotlin, C/C++ and Swift need the project's own build, so when they are in the tree the run says so and the scan is partial, not clean. It runs only when named — a database takes minutes, not seconds, and the CodeQL CLI's license covers open-source code and GitHub Advanced Security customers.

Ignores Snyk itself reports as accepted are honored and listed as coverage exclusions. Ignores the change under review adds are not: when a fix is judged, .snyk, .semgrepignore, .trivyignore and .dvalincodeignore are restored to the base commit's version and new inline markers (deepcode ignore, nosemgrep, nosec, NOSONAR, …) are blanked, so a finding that was silenced rather than fixed still fails the fix. A suppression is a risk decision a person makes in its own change, never a repair.

The same judgement applies wherever Dvalin says "verified": the fix loop, dvalin verify, the MCP dvalin_verify_findings tool, single-round --fix --verify, and CI reverify. Those records are dvalin-fix-record/v3, which also fails a repair that hid a finding instead of fixing it — a sibling sink, a deleted vulnerable file, deleted tests or assertions. Outside a git repository, where the change cannot be determined, records stay v2 and say that evasion was not evaluated.

Let it loop until the gate would pass

dvalincode dvalin . --scanners builtin,snyk-code,snyk-oss --until-clean --max-rounds 3 --executor codex

--until-clean turns one fix attempt into a bounded loop. The executor edits; Dvalin re-scans with the same engines and runs the project's checks itself; the executor is sent only what is still wrong — targets still present, findings its change introduced, failing checks with their last lines of output, suppressions it added — and fixes again. Dependency findings go first.

The loop stops, and says which, when every target is gone with nothing blocking introduced and every check passing (verified), when the round budget runs out, when a round leaves the same problems open or the open set stops shrinking (stalled), when the targets need a person — a dependency with no fixed version (not-auto-fixable) — or when the engines or checks cannot run (unverifiable). Suppressions the executor adds are undone before each scan and stay open problems until removed. Every outcome issues a fix record, and every round is logged under ~/.dvalincode/security/fix-loops/; dvalin loop-stats summarizes those logs — how often loops reach verified, the median and p90 rounds to green, which stop rule fired, and what was still open when a loop stalled (--json, --since, --executor to slice it).

Rounds are kept short without changing what decides them. The engines run side by side, so a scan costs the slowest engine rather than the sum. Between rounds, the engines that analyse one file at a time (Dvalin Built-in, Semgrep) rescan only the files the change touched and the files the targets are in; the others always scan the whole tree. That narrowed scan only steers the executor: any round that would stop the loop is re-judged on a full scan of the same tree, and only the full scan decides the outcome and goes into the record. --full-rescan scans everything every round, and loop-stats reports scan time per round and how often a full scan changed the decision.

For code findings the loop first asks for a reproduction: tests only, which Dvalin runs on the unfixed code and requires to fail — by a failing assertion, not a missing runner or a not-yet-written import. The tests are hashed; the fix must then make them pass unchanged, and that run is a check in the record. A finding no test could demonstrate stops the loop as not-reproduced before anything is fixed: it may be a false positive, and a person triages it. The runner is inferred (vitest, jest, mocha, node --test, pytest, go test) or set with --repro-command 'npx vitest run {files}' or reproduce in dvalin.security.json — never chosen by the executor.

Each fix round also rejects the evasions an agent reaches for when the goal is "the scanner went quiet": moving the sink to a sibling (eval → new Function, exec → spawn with shell: true), deleting the vulnerable file, deleting tests, removing assertions. In practice the scanner alone is fooled by the first one — the rule stops matching — and the reproduction test and the evasion check are what catch it.

Keep it on today's main, and close it in CI

dvalincode dvalin . --scanners builtin,snyk-code,snyk-oss --until-clean \

--rebase-onto origin/main --executor codex --draft-pr --sign-key ci.key

With --rebase-onto the loop fetches and rebases the fix onto upstream before it starts and after every round, then judges it there. Conflicts go to the executor — the conflicted files only, with "do not run git" — and Dvalin continues the rebase itself; markers left in a file are a conflict not resolved. If they cannot be resolved the