AutoST vs Open-Source UDS Tools: CaringCaribou, udsoncan, Scapy, can-utils

What is the difference?

The open-source tools are building blocks for an engineer at a terminal. cansend and candump from can-utils put frames on the bus and show what comes back. python-udsoncan gives you a correct UDS client with typed services and exceptions, ideal for a script that reads DIDs or walks a session. Scapy’s automotive layers dissect and craft CAN, ISO-TP, UDS, DoIP and SOME/IP packets and ship scanners for services, DIDs and sessions. CaringCaribou bundles discovery, service and DID enumeration, a fuzzer and a SecurityAccess seed-randomness check into one command-line tool. All of them are free, documented and maintained by people who know the protocols.

AutoST is a product for a team that has to produce the same result repeatedly and show it to someone else. The test agent on the bench runs enumeration across sessions, names what it finds from your ODX or CDD, probes SecurityAccess with bounded attempts, fuzzes UDS and CAN with a stored seed and live crash detection, and reports the result as PDF, SARIF and a ranked Fix Plan, triggered from a dashboard, the REST API or a Bamboo build. The difference is not that AutoST knows a service the free tools do not. It is what happens around the request: state handling, naming, reproducibility, evidence and integration.

Side by side

	Open-source UDS tools	AutoST
What it finds	Endpoints, sessions, services and DIDs on a CAN ECU; seed randomness (CaringCaribou); anything you script with udsoncan or Scapy, including DoIP and SOME/IP packets	The same surface plus session-aware classification, ODX/CDD-named DIDs and routines, write probing, SecurityAccess counters and delays, reproducible UDS and CAN fuzzing with crash detection, DoIP routing, SOME/IP service mapping, Android IVI checks
What it misses	Nothing in principle, everything in practice that nobody scripted: cross-session state, reproducibility, hang detection, naming, history, reports	Logic and chained attacks (a pentester’s job), FlexRay, LIN, HSFZ, firmware internals
Who does it	An engineer who knows Python, SocketCAN and the protocol; the script lives with that engineer	Test and QA engineers through a dashboard; no scripting needed
Bench time	Minutes per probe, hours to assemble and debug a full run; repeat by hand each release	Minutes for enumeration, hours for fuzzing, unattended; re-run by one click or a build step
Cost	Free; your engineer’s time and a CAN interface	Licence per tested component, price on request after a demo
Fits a release cycle	Only if someone maintains the scripts and compares results by hand	Yes, via API tokens, the Bamboo plugin and SARIF export into your tracker
Required by	Nothing; a recognised part of any tester’s kit	Nothing either; what standards ask for is testing with evidence, which either route can deliver
Output	Console output, candump logs, whatever your script writes	PDF report per run, SARIF 2.1.0, CSV and JSON, dated scan history, Fix Plan with status

Choose the open-source tools when

• You are exploring. The first hour with an unknown ECU is candump, a few cansend frames and CaringCaribou’s uds discovery. Nothing beats that for understanding what is on the bus.
• You need something the product does not do: a custom protocol on top of CAN, a manufacturer-specific service with its own framing, a quick DoIP packet with Scapy to check one hypothesis.
• One engineer tests one ECU once and nobody needs a report. A script and a notebook are the right size for that.
• You are learning. Reading udsoncan’s source teaches ISO 14229 better than the standard does.
• The budget is zero. These tools are the reason a security test does not have to start with a purchase order.

Choose AutoST when

• The same ECU comes back every sprint or in a dozen variants and the question is “did anything regress”, not “what is this”.
• Results have to be defended: an auditor, an OEM or a customer wants to know what was tested, when, and what happened to each finding. Dated history, PDF and SARIF answer that; a folder of candump logs does not.
• The team running the bench is test engineers, not security specialists. A dashboard with named DIDs from the CDD and a Fix Plan in plain language is what lets them run and read a security test.
• Fuzzing has to be reproducible. A crash found by a random script at 3 a.m. is only useful if the same sequence can be replayed on the developer’s bench, with the payload history and the monitor that caught it.
• The test should run in the pipeline and fail the build above a threshold, with JUnit XML in the build results.

Both together

Most teams we work with keep both. Scripts and CaringCaribou for the exploratory half hour on a new ECU and for the odd custom protocol; AutoST for the repeatable suite that runs on every release and writes the evidence. The REST API makes the hand-off easy: a script can trigger a scan and pull the JSON. If you only ever do the first half, the free tools are all you need and we will say so in the demo.