What it does
Dastardly is a stripped down version of the Burp Scanner engine packaged as a container image for use in a build pipeline. You give it a URL, it crawls the application in the pipeline environment, and it audits what it finds against a deliberately small set of checks chosen because they are fast, reliable and relevant to code a developer just changed. Typical coverage includes reflected and stored cross site scripting indicators, some injection classes, missing or misconfigured security headers, cookie flags, form and transport issues.
The design constraint is time. It is built around a scan budget short enough to sit inside a normal build, which is why the check set is narrow and why it does not attempt deep crawling, out of band detection or authenticated coverage. Output is a JUnit XML report: every CI system already knows how to render JUnit results and fail a build on them, so findings show up as test failures next to your unit tests without a custom parser.
Where it fits
This runs on pull requests and merges, owned by the development team. It needs a running instance of the application reachable from the pipeline, which in practice means the job starts the app in a container alongside the scanner. It is a first line check, not an assessment. The right way to think about it is a smoke test for obvious web security regressions, positioned in front of, not in place of, real scanning and manual testing.
Strengths
- Genuinely quick, which is the only reason a dynamic scan survives contact with a pull request workflow.
- JUnit output means integration with any CI system is trivial and results appear where developers already look.
- Free, with no account, licensing or quota friction, so adoption decisions do not need procurement.
- Checks inherit from a well regarded scanning engine, so what it does find is usually real.
Limitations
- Coverage is intentionally narrow. A clean Dastardly run says almost nothing about the overall security of an application.
- No authenticated scanning, so anything behind a login is invisible to it.
- No out of band detection, so blind injection and server side request forgery classes are out of reach.
- You still need to stand up the application in the pipeline, which is meaningful engineering work for anything with real dependencies.
Who it suits
Well suited to development teams who want a fast regression check for basic web security issues on every change, and to organizations building a security program who want an easy first automated control. Treating it as your only dynamic testing would be a serious misreading of what it is for.
Used Dastardly? Recommend it under your own name and title.
Recommend this tool