# tsunami-security-scanner: a shell with all its intelligence in plugins

> Google's network security scanner is small enough to read in an afternoon and does almost nothing on its own. The interesting part is the plugin contract, and the repository makes clear that the plugins live somewhere else entirely.

**google/tsunami-security-scanner** — Tsunami is a general purpose network security scanner with an extensible plugin system for detecting high severity vulnerabilities with high confidence.

- Repository: https://github.com/google/tsunami-security-scanner
- Stars: 8,616 · Forks: 928
- Language: Java
- License: Apache-2.0
- Published: 2026-10-06 · Updated: 2026-10-06 · Language: en
- Canonical page: https://hysenlabs.com/projects/google-tsunami-security-scanner

## What the README claims and what it withholds

The whole positioning statement fits in two sentences. Tsunami is described as a general purpose network security scanner with an extensible plugin system for detecting high severity vulnerabilities with high confidence. Both halves of that sentence matter, because the second one narrows the ambition considerably. This is not a sweep-everything-and-report-everything tool like a conventional port scanner. The stated target is high severity issues detected with confidence, which is a claim about precision rather than coverage.

What the README withholds is almost everything practical. There is no installation section, no example invocation, no configuration walkthrough and no list of supported checks. The quick start section consists of a single sentence pointing at a documentation site hosted at google.github.io, with a link to a how-to page for building and running the scanner. The contributing section is one line and one link as well.

That makes this a landing page rather than a manual, and it means the README cannot answer questions a potential adopter will ask first. What counts as a high severity finding, what a plugin has access to, how results are expressed, whether there is a scheduler or a queue, what happens on a false positive: all of it is on the other side of that documentation link. A reader who wants the project's pitch gets it in six lines. A reader who wants to decide whether to deploy it has to go and read a site.

## Plugins live in a separate repository by design

The most consequential sentence in the README is the one about where the work actually happens. Tsunami relies heavily on its plugin system to provide basic scanning capabilities, and all publicly available plugins are hosted in a separate repository, google/tsunami-security-scanner-plugins.

Read that as an architectural statement rather than a packaging convenience. The scanner and the knowledge are decoupled. The core provides a contract, a runtime and presumably some orchestration, while everything a user would recognise as scanning competence arrives from outside. The consequence for an adopter is that evaluating Tsunami means evaluating a plugin set you did not write and may not fully control, and the two repositories move independently.

This split also shapes the security question in an unusual way. A scanner that executes third-party detection logic is running code chosen by whoever wrote the plugins, against targets that may be hostile. A framework designed for this has to think hard about isolation, timeouts and resource limits, and the repository layout hints at where that thinking happens. There is a directory called `plugin_server/`, which is the obvious place for running plugins out of process, alongside `proto/` for whatever interface definition that boundary uses. Nothing in the README describes the isolation model, and for a tool whose job is to touch untrusted hosts, that is the first documentation gap worth flagging.

## Reading the tree for evidence of a migration

The repository layout is more informative than the README, and it contains one genuine surprise. The project is recorded as Java, and the tree does look like a Gradle build at first glance, with `build.gradle` and `settings.gradle` at the root. But there is also a Go module definition sitting right beside them.

```go
module github.com/google/tsunami-security-scanner
```

That module line declares the project path and nothing else, and the Go directive below it pins the language version the module expects.

```go
go 1.22.0
```

The mix of build systems is the interesting part. It reads as a project partway through moving its core from a JVM implementation to Go, with the Gradle files not yet removed. For an adopter this matters in a small but real way: the documented build path on the external site may not match what the current tree implies, and a language version pinned in a module file is a hard constraint on the toolchain you need installed.

The other top-level directories read as a fairly conventional plugin architecture. `main/` is the entry point, `common/` holds shared code, `core.Dockerfile`, `devel.Dockerfile` and `full.Dockerfile` give you three container variants, and `docs/` and `workflow/` hold documentation sources and continuous integration configuration. The three Dockerfiles are worth noting on their own, since a scanner that ships in three sizes implies a distinction between a minimal core, a development image and a full image with more of the plugin stack attached.

## What the container variants imply about how it is deployed

Three Dockerfiles at the repository root is an unusual amount of attention to packaging for a tool whose README never mentions containers. `devel.Dockerfile` is the obvious one, a build environment with a toolchain inside it. `full.Dockerfile` is the deployment shape, a scanner carrying the plugin set needed to actually scan. `core.Dockerfile` sits between them and is the interesting one, because it suggests the project distinguishes a core that can run at all from a full image that can do useful work out of the box.

That distinction lines up with the plugin split. If all the detection logic lives in an external repository, then the core image has nothing to scan with unless plugins are mounted, added or fetched, and the full image is presumably the one assembled with a plugin set included. For anyone running this in a pipeline, that is the difference between an image that starts and an image that produces findings.

Two configuration files sit at the root alongside them, `tsunami.yaml` and `tsunami_tcs.yaml`. The naming suggests a primary configuration and a separate one for credentials or secrets, which is a pattern that shows up repeatedly in tools that talk to authenticated cloud targets. The README does not describe either file, so what they actually contain is documented only on the external site.

## Release history, activity and what is missing

The project has exactly one tagged release in the visible history, v0.2.0, published on 2026-02-19, with an empty release body. Version numbering that starts at 0.2 rather than 1.0 is consistent with a framework that has not yet committed to a stable plugin interface, and an empty release note gives no evidence either way.

Activity is the more reassuring signal. The repository was pushed to on 2026-06-23, it is not archived, and it carries 8,617 stars with 927 forks, which is a large audience for a tool whose README is twelve lines. The open issue count of 15 is unusually low for that many stars and suggests a project that is either well maintained or heavily filtered, and the README does nothing to help a reader tell which.

What is missing is the thing that matters most for a scanner. There is no compatibility statement, no schema for results, no guidance on what a plugin author must implement beyond a link to the contributing docs, and no explanation of what the output looks like. There is also no security policy and no statement about how to report a vulnerability in the scanner itself, which for a tool that parses responses from hostile hosts is a gap a security team will notice immediately. The README closes with the standard line that Tsunami is not an official Google product, which is worth reading as a boundary on what support you can expect.

## How to compare it against what you would use instead

The honest comparison is not against other general purpose scanners. Tsunami does not present itself as one, and the precision framing suggests it will miss plenty of lower severity findings that a broad tool would surface. The comparison that makes sense is against a bespoke script you would otherwise write.

The case for a framework like this is that the plugins are the hard part. Writing a detection for a specific product vulnerability requires knowing the product, knowing the request that distinguishes it, and knowing what the response looks like both when the product is there and when it is not. Encoding that once as a plugin and sharing it is a real saving, and the separate plugin repository is evidence that people do exactly that.

The case against is that you now depend on two repositories, a Go toolchain, a plugin contract documented elsewhere, and whatever quality bar the external repository applies to submissions. If your scanning need is a fixed list of checks against known infrastructure, a few hundred lines of your own script may be less work and fewer moving parts.

Either way the decision cannot be made from the repository. Read the how-to, find the plugin contract, read a handful of the plugins in the external repository, and only then decide whether the precision claim is one you can live with. That last point deserves emphasis, because a scanner tuned for high confidence and high severity will happily return nothing on a network that is merely unremarkable, and an empty report is much harder to defend than a noisy one.

## Conclusion

Tsunami is not a scanner you run to get a report today. It is a framework whose value is decided by the quality of the plugins you install, and the README is honest that you need a second repository to see any of that value. The documentation site, not the repository, holds the build and run instructions, the plugin contract and the contribution rules, so that is where an evaluation has to start. There is one tagged release, v0.2.0 from 2026-02-19, and the repository was pushed to on 2026-06-23, which puts the project in the range where the architecture is settled and the plugin ecosystem is still the open question.

## FAQ

### What is Google Tsunami security scanner used for?

Tsunami is a general purpose network security scanner built around an extensible plugin system, with the stated goal of detecting high severity vulnerabilities with high confidence. The actual detection capabilities live in plugins hosted in a separate google/tsunami-security-scanner-plugins repository rather than in the scanner repository itself.

### How do you build and run Tsunami?

The repository README does not spell out the steps and instead links to the project's documentation site, which has a how-to page covering building and running the scanner. The repository itself ships three Dockerfiles for development, core and full images, and a Go module definition alongside Gradle build files, so the current build layout is in some flux.

### Where are Tsunami's vulnerability checks stored?

In a separate repository. Tsunami relies heavily on its plugin system for basic scanning capability, and all publicly available plugins are hosted in google/tsunami-security-scanner-plugins. The core repository provides the framework, the entry point and shared code, plus a plugin_server directory that suggests plugins can run out of process.

### Is Tsunami a production ready security scanner?

It has a single tagged release, v0.2.0 from 2026-02-19, which suggests an API that has not settled. The repository is not archived and was pushed to on 2026-06-23, so work is continuing. Note also that the stated design goal is high severity issues with high confidence, so quiet output on an unremarkable network is expected behaviour rather than evidence of a clean bill of health.

## Sources

- [google/tsunami-security-scanner on GitHub](https://github.com/google/tsunami-security-scanner)
- [Issues](https://github.com/google/tsunami-security-scanner/issues)
- [License: Apache-2.0](https://github.com/google/tsunami-security-scanner/blob/master/LICENSE)
- [README](https://github.com/google/tsunami-security-scanner/blob/master/README.md)
- [Releases](https://github.com/google/tsunami-security-scanner/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/google-tsunami-security-scanner