Radar

radar

Use radar to perform a full, 100% coverage security scan for critical vulnerabilities. start with running all templates per the targeted language, take insights from them as low hanging fruits, and continue to manual audit. at the end - reflect back to templates that could've done better, or engine utility improvements - and offer to PR new improvements for the next cycle.

How the pipeline actually works

The two node classes have different method sets. A rule gets one or the other based on its language: field - never both. Solidity is currently 68 of the 124 builtin templates, so check which side you are on before reaching for a method.

radar needs a running Docker daemon; every scan starts a compose stack. Template iteration does not - see the loop below.

Three ways a template fails silently

Nearly every "my rule doesn't work" is one of these. None of them produce an error you will see.

1. Every rule body runs inside try: … except: continue. A misspelled method, wrong arity, or a Rust method called on a Solidity node raises, gets swallowed, and the file is skipped. No findings looks identical to no vulnerability. When a rule reports nothing, suspect a broken call before you suspect the pattern.
2. The DSL is a sandbox with eight builtins: print len range dict list tuple set type. No imports. any(), all(), sorted(), enumerate(), str(), int() raise RuntimeError - into the except above. Use .nodes truthiness, explicit loops, and len().
3. language: and accent: gate execution. A template only runs when its language matches the detected project language (default rust) and, for Rust, its accent matches the detected framework. Get these wrong and the template is filtered out before it runs: no error, no failing test, no output. Solidity templates use accent: "" and language: solidity. There is no accent: solidity.

The loop

0. Do not write a duplicate. 124 templates already ship. ./radar list-templates, and grep api/builtin_templates/*.yaml for the vulnerability class. If one is close, extend it or sharpen its focus - a near-duplicate is a maintenance cost with no new coverage.

1. Read the AST of a contract that has the bug. ./radar --dev -p <path> --ast -o out.json writes findings to out.json and the AST to ast.json beside it - two files. See references/ast-shape.md; the shape is not what you would guess.

2. Draft the rule against what the AST actually contains, not against the source you read. Inside a rule, some_nodes.to_raw_ast_debug() prints the enriched view (with access_path) at that point - add the call, do not wrap it in print().

3. Iterate in-process, not through Docker. For Anchor templates:

cd api && poetry run python tests/check_scoping.py <template_stem>

Seconds per iteration, no daemon, and it reports detections on bad/ and good/ separately. It parses Rust live, so it needs rust_syn built once (references/contributing.md); inside the api container it is already there. It drives the Rust path only - Solidity rules iterate through the pytest suite.

4. Prove both directions before you believe it. The bad mock must detect; the good mock must be silent. One direction alone is not evidence.

5. Pin what you just proved, so the next person's tuning cannot quietly undo it - a noise fixture, a detection fixture, or both (see the gates below).

6. Register it in EXPECTED_DETECTIONS with exact file:line:startcol-endcol spans, and add the mock pair. A template with no entry is silently dropped from the accuracy suite and CI stays green. Full contract: references/contributing.md.

7. Generate the fixtures, then run the full suite - cd api && poetry run python scripts/generate_fixtures.py, then make test-all from the repo root. Plain make test skips the active_runtime suites, which are the ones that parse real source.