Inside Google's Tsunami Security Scanner Plugins: The Open-Source Arsenal for AI Infrastructure Security

Hook

While most vulnerability scanners still focus on WordPress and Apache Struts, Google's Tsunami plugin repository has quietly become the most comprehensive open-source detector for AI infrastructure vulnerabilities—covering everything from exposed Ray dashboards to MLflow credential bypasses.

Context

The explosion of AI/ML deployments has created a new attack surface that traditional vulnerability scanners weren't designed to handle. Tools like Ray, MLflow, Jupyter, and Gradio have become critical infrastructure components, but they're often deployed with minimal security hardening. Engineers prioritize model training velocity over security posture, leaving dashboards exposed, APIs unauthenticated, and credentials hardcoded.

Google released Tsunami Security Scanner in 2020 as a high-confidence, low-false-positive vulnerability detector for large-scale networks. Unlike noisy scanners that flag every potential issue, Tsunami only reports vulnerabilities it can actually verify. The plugin repository extends this core scanner with community-contributed detectors. What makes this project remarkable is its focus: roughly 40% of maintained plugins specifically target AI/ML infrastructure vulnerabilities—a category barely represented in other scanning frameworks. This isn't accidental; Google's internal ML platform experiences informed what external threats needed detection.

Technical Insight

The plugin architecture follows a clean detector pattern where each vulnerability check implements the VulnDetector interface. Plugins receive network service information from the core scanner and return a DetectionReport with verified findings. The separation of concerns is elegant: the core Tsunami engine handles service discovery and network fingerprinting, while plugins focus solely on exploit verification.

Here's how a typical detector is structured, using the exposed Ray Dashboard detector as an example:

@PluginInfo(
    type = PluginType.VULN_DETECTION,
    name = "ExposedRayDashboardDetector",
    version = "0.1",
    description = "Detects exposed Ray dashboard instances.",
    author = "Google",
    bootstrapModule = ExposedRayDashboardDetectorBootstrapModule.class
)
public final class ExposedRayDashboardDetector implements VulnDetector {
  
  @Override
  public DetectionReportList detect(
      TargetInfo targetInfo, ImmutableList<NetworkService> matchedServices) {
    
    return DetectionReportList.newBuilder()
        .addAllDetectionReports(
            matchedServices.stream()
                .filter(this::isRayDashboard)
                .filter(this::isUnauthenticated)
                .map(this::buildDetectionReport)
                .collect(toImmutableList()))
        .build();
  }
  
  private boolean isRayDashboard(NetworkService service) {
    String response = httpClient.get(service.getNetworkEndpoint());
    return response.contains("Ray Dashboard") 
        && response.contains("/api/nodes");
  }
  
  private boolean isUnauthenticated(NetworkService service) {
    // Attempt to access sensitive API endpoint
    String apiResponse = httpClient.get(
        service.getNetworkEndpoint() + "/api/cluster_status");
    return apiResponse.contains("state") && !apiResponse.contains("401");
  }
}

The plugin makes HTTP requests to verify not just that Ray Dashboard exists, but that it's actually exploitable. This verification-first approach dramatically reduces false positives compared to signature-based scanners. Many Nuclei templates simply check for the presence of specific strings in responses; Tsunami plugins prove the vulnerability by performing the actual exploit chain (minus any destructive actions).

The repository organization reveals thoughtful categorization: google/detectors contains Google-maintained plugins with higher quality standards, while community/detectors accepts broader contributions. Within each category, plugins are grouped by vulnerability type—exposedui, rce, creds, and specific CVE identifiers. This structure makes it trivial to enable only relevant detectors for your infrastructure.

Plugin dependencies are managed through Guice modules, allowing for clean dependency injection of HTTP clients, crypto utilities, and configuration. Each plugin declares its own bootstrap module:

public final class ExposedRayDashboardDetectorBootstrapModule 
    extends PluginBootstrapModule {
  
  @Override
  protected void configurePlugin() {
    registerPlugin(ExposedRayDashboardDetector.class);
  }
}

What's particularly clever is how plugins handle version-specific vulnerabilities. The MLflow plugin, for instance, checks multiple exploit paths because different MLflow versions have different authentication bypass techniques. Rather than maintaining separate detectors for each version, a single plugin tests all known vectors and reports which succeeded. This reduces maintenance burden while improving detection coverage.

The AI/ML coverage is genuinely impressive. There are detectors for Ray dashboard exposure, Jupyter notebook servers without authentication, MLflow tracking servers with weak credentials, PyTorch Serve management APIs, Triton Inference Server vulnerabilities, Gradio interfaces, and even Tensorboard instances. These aren't obscure tools—they're production infrastructure running in major enterprises, often with minimal security oversight because they're considered "internal developer tools."

Gotcha

The elephant in the room: these plugins are useless without the core Tsunami Security Scanner. You can't just clone this repository and start scanning. You need to set up the full Tsunami framework, understand its configuration format, build the Java project with Gradle, and integrate plugins into the scanner's execution flow. The documentation assumes familiarity with the parent project, which has its own learning curve. For teams just wanting to run a quick security scan, this is heavyweight infrastructure.

The "not an officially supported Google product" disclaimer has real implications. While Google engineers contribute actively, there's no SLA, no guaranteed response time for critical vulnerabilities, and no enterprise support contract available. Several plugins target CVEs from 2019-2020 but haven't been updated to check for patches, meaning you might get alerts for already-remediated systems. The community contributions vary wildly in quality—some are production-ready with comprehensive tests, others are proof-of-concept code that may not handle edge cases. You're responsible for vetting which plugins to trust in production environments. The Java requirement also creates friction; many security teams have standardized on Python or Go tooling, and introducing JVM dependencies for scanning can complicate CI/CD pipelines and container images.

Verdict

Use if: You're already running Tsunami Security Scanner and need expanded detection capabilities, especially if you're operating AI/ML infrastructure at scale. The ML-focused detectors alone justify adoption for organizations running Ray, MLflow, Kubeflow, or similar platforms. Also valuable if you're building a security scanning platform and want a reference implementation of high-confidence vulnerability detection—the plugin code is clean, well-structured, and instructive. Skip if: You need a standalone scanner you can run immediately without infrastructure setup, require vendor support for compliance reasons, or don't have Java/Gradle expertise on your security team. Teams without significant AI/ML deployments should evaluate whether enough relevant plugins exist for their stack before investing setup time. For quick ad-hoc scanning, Nuclei templates or Nessus provide lower friction, even if they generate noisier results.