Most microservice security bugs live between services. We wrote a paper on catching them.
Our SEKE 2026 paper on SAMSARA, the framework behind Slopless: what it measured against Semgrep, and the design choices that raised recall and precision.
Most security reviews look at one service at a time. In a microservice system, many serious bugs live between services: one service checks who owns a record, and the next service trusts that check and skips its own.
We built Slopless to find those bugs. We then wrote up the method as a research paper, SAMSARA, and it was accepted as a regular paper at SEKE 2026 (41% acceptance rate).
What we measured
We tested on six labeled benchmarks and compared against Semgrep, a widely used rule-based scanner.
| Benchmark | Services | Slopless | Semgrep |
|---|---|---|---|
| crAPI (OWASP) | 4 | 94.4% | 33.3% |
| sock-shop | 8 | 84.6% | 0.0% |
| online-boutique | 11 | 92.3% | 23.1% |
| train-ticket | 41 | 70.0% | 0.0% |
| XBOW-104 (single-file) | — | 97.1% | 91.3% |
The numbers are recall: the share of known vulnerabilities each tool found. For sock-shop, online-boutique and train-ticket, we wrote down the vulnerabilities before any scan ran, so the tools could not be tuned to them. Those three results combine three models (Opus, Sonnet and Haiku); one model alone found 20% to 85%.
On single-file bugs, the two tools almost tie (5.8 points apart). On bugs that cross services, Slopless found 61 to 85 points more. On train-ticket, Semgrep reported over a thousand findings and caught none of the 10 known flaws. Slopless caught 7.
Use rule-based scanning for single-file bugs. Use architecture-aware analysis for bugs that cross services.
What raised recall and precision
We removed one component at a time and measured the effect on crAPI.
1. A map of the services raised precision, not recall. Before any AI agent runs, a plain parser maps the services, the calls between them, and the databases they share. Without the map, recall stayed at 94.4%, but the number of reported findings went from 38 to 70 and precision fell from 0.45 to 0.24. The map tells the agent which connections between files are real.
2. More steps to explore raised both recall and precision. The agent reads files, searches and follows calls step by step. It must list its first candidates within two steps, so it can’t spend its whole budget on one lead. With one step, it found 77.8% of known bugs at 0.23 precision. With 15 steps, it found 94.4% at 0.45. This was the largest effect of any one component.
3. Findings are rejected unless the agent proves them. To confirm a finding, an agent must trace the path from attacker-controlled input to the dangerous operation, with a file location. The code rejects any finding without that trace. A separate reviewer on a different model then checks each finding of medium severity or higher.
4. Two cheaper models found more than one expensive model. Each model missed different bugs. On crAPI, Sonnet and Haiku together found 100% for $11. Opus alone found 94.4% for $24. Do not assume that the most expensive model sees everything the cheaper ones see.
We also checked the false positives. About two-thirds were real hardening issues that were outside the benchmark’s labels, such as disabled TLS verification, hardcoded credentials and permissive CORS.
In client audits
Our client audits combine Slopless with manual review. For o1.exchange, we reviewed the token launchpad over three rounds, including a check that the contracts deployed on X Layer match the audited code. In a trading contract on Base, the audit found a high-severity flaw: trades had no slippage limit, so a compromised owner key could drain the contract by trading against itself.
Try it
Slopless is built on this method. Your first scan is free, no account needed: slopless.work (opens in a new tab)
