AutoST for CI/CD Engineers: ECU Security Scans as a Pipeline Gate

The job

A CI/CD or test automation engineer in an ECU project builds and maintains the pipeline that takes a commit to a flashed ECU on a bench and a green or red build. Unit tests, static analysis and hardware-in-the-loop tests are usually in place. Security testing is not: it happens once per sample phase, by hand, and the result arrives weeks after the change that caused it.

We regularly see regressions that a pipeline would have caught on the day they were introduced. A debug service enabled for a test build stays reachable in the default session in the release. A refactoring of the diagnostic stack drops the attempt counter on SecurityAccess. A new DID for end-of-line programming ends up writable without authentication. Each is a one-line diff and each is visible in the very next enumeration scan.

What the role needs from a test run

The engineer needs the security scan to behave like every other stage: scripted, bounded in time and unambiguous.

• A trigger without a human. Long-lived API tokens (JWTs), scoped and revocable in the dashboard, authenticate the pipeline against the REST API. The same API starts any scan the dashboard can start.
• A clear verdict. The Bamboo plugin fails the build when findings exceed the threshold you set. In other CI systems, your script reads the scan result from the API and sets the exit code.
• Output the build server understands. JUnit XML shows the scan in the build results like any test suite, JSON feeds your own tooling, and a PDF per run is archived as evidence. The Fix Plan exports as SARIF 2.1.0 for code-scanning dashboards.
• Stable results. Accepted risks and comments carry across re-scans, so the gate only reacts to new findings. Fuzzing uses a stored seed, so a nightly crash can be replayed exactly.
• No inbound ports on the bench. The Carbyne agent polls the backend over HTTPS, so the bench network does not have to be reachable from the build server.

Typical setup

The pipeline builds the firmware, flashes it onto the bench ECU with your existing flashing tool, then calls AutoST. The Carbyne agent runs on the bench PC, on Windows with Vector hardware through the XL driver library or on Linux with PEAK, Kvaser or any other SocketCAN interface, plus Ethernet for DoIP and SOME/IP. It picks up the job, runs the scan and streams results to the backend; several benches run in parallel.

On Atlassian Bamboo, the plugin is a task in the build plan: it triggers the scan, polls for completion, applies the threshold and attaches JSON, JUnit XML and the PDF. On Jenkins, GitLab CI or GitHub Actions there is no plugin; a script step calls the REST API with the token from your secret store and does the same. A common split is a short deterministic profile per build, enumeration and SecurityAccess checks, and a longer fuzzing profile nightly or before a release.

A sensible first project

Start with one ECU on one bench that the pipeline already flashes.

1. Week 1: plumbing. Install and pair the agent on the bench, create an API token for the pipeline, and add the Bamboo task or a script step that starts an enumeration scan after the flash step.
2. Week 2: baseline and threshold. Run the scan on the current release, review the findings with the security team, accept what is intended, and set the threshold so today’s build passes.
3. Week 3: gate. Turn the threshold on. From now on a new reachable service, a lost attempt counter or a newly writable DID fails the build with the request in the report.
4. Week 4: nightly fuzzing. Add a seeded UDS fuzzing job on a schedule, with TesterPresent liveness and DTC monitoring, and route crashes to the Fix Plan.
5. Review. Count the regressions caught and decide which further ECUs and benches join the pipeline.

How results feed ISO/SAE 21434 and UN R155

Every pipeline run leaves a dated PDF, which turns security verification from a project milestone into a record per build. ISO/SAE 21434:2021 Clause 10.4.2 requires verification against the cybersecurity specification ([RQ-10-09]) and recommends component testing with fuzz testing and vulnerability scanning ([RC-10-12]); Clause 8.5 treats vulnerability analysis as a continuous activity. A gate in the pipeline is the most direct way to make both happen on every release.

UN R156 requires that a software update does not undermine the vehicle’s security, which in practice means re-testing after each update; a pipeline does that by default. For the UN R155 Annex 5 threats around diagnostic access, the per-build history shows the mitigation was still in place when the software shipped. AutoST does not replace a penetration test and does not certify anything; it makes sure the known checks never get skipped.