StellarFoundry/soroban-security-scanner

What it is

soroban-scan is an MIT-licensed Rust CLI (crates soroban-scan-core and soroban-scan-cli) that statically analyzes Soroban contracts using syn-based parsing. It never executes, deploys or signs the code it scans, and makes no network requests by default. The README calls the project early development and points to docs/PROJECT_STATUS.md for what exists today. The maintainer is @Ayinkx (AyinkxLab).

What the detectors rate themselves at

Severity and confidence are reported separately, and the confidence column is the main thing to read before adopting it. Of the 19 rules, 12 are rated low confidence, 5 medium and 2 high.

• Low confidence includes several high-severity rules: SS-002 (cross-contract call without caller authorization), SS-011 (initialization without a re-initialization guard) and SS-013 (cross-contract call before state update). Expect these to need manual triage.
• SS-001 (state-changing entry point without caller authorization) is high severity at medium confidence. SS-017 (authorization after state mutation) is medium at medium.
• Only SS-005 (unsafe code) and SS-033 (wildcard SDK import) are high confidence.
• Rule IDs are stable and never reused, so the gaps between SS-017, SS-029 and SS-033 are not a sign of missing files.

The page shows one real run on the bundled vulnerable example: 5 findings (2 high, 1 medium, 2 low), covering SS-001, SS-006, SS-004, SS-007 and SS-002.

What to do

Build and try it on the example, then your own contracts:

git clone https://github.com/StellarFoundry/soroban-security-scanner
cd soroban-security-scanner
cargo build --release
./target/release/soroban-scan scan ./examples/vulnerable-contract --fail-on none

For CI, emit SARIF 2.1.0 or JSON, and use explain to read a rule:

soroban-scan scan ./contracts --format sarif --output results.sarif
soroban-scan scan ./contracts --format json --output report.json --fail-on none
soroban-scan explain SS-001
soroban-scan init
soroban-scan config validate

Given the low-confidence rules, the baseline flags are the practical way to adopt it on an existing codebase: --baseline, --write-baseline, --new-only and --incremental. A composite GitHub Action scans only files changed in a pull request. It also offers opt-in sticky PR comments and check runs, and a scheduled workflow that opens a pull request to refresh the baseline. The README example is:

- uses: AyinkxLab/soroban-security-scanner@main
  with:
    fail-on: high

CI is tested against pinned Soroban SDK fixtures 20.5.0, 21.7.7 and 29.0.1. Other SDK versions are not mentioned.

Caveats

• The README states the scanner does not replace a professional audit. It points to an Analysis Methodology doc for what detectors can and cannot prove.
• The Action example references AyinkxLab/soroban-security-scanner@main, while the repository is under StellarFoundry. It also tracks the moving main branch, not a tagged release. Check the owner path and pin a tag before relying on it.
• Optional --guidance assistance is off by default and described as never authoritative. The core scanner does not use AI.
• The page gives no precision or recall numbers, no comparison against other Soroban analyzers, and no list of known false-positive patterns.