aquasecurity/starboard: Kubernetes security reports through CRDs

Starboard's Kubernetes-native security model

Starboard addresses a Kubernetes integration problem rather than trying to replace every scanner. The README says that separate security tools often sit beside a cluster, with each product requiring its own commands and installation process. Starboard collects their output into Custom Resource Definitions, also called CRDs, so security information can be accessed through the Kubernetes API.

That design is aimed at teams that need to relate security findings to cluster objects such as workloads and nodes. The documented capabilities include automated vulnerability scanning for Kubernetes workloads, configuration audits using predefined rules or custom Open Policy Agent policies, infrastructure scanning, CIS Benchmarks, compliance reports, and penetration test results for a cluster. The project also provides a Go module, an Octant Plugin, and a Lens Extension for integrating security reports with Kubernetes interfaces.

The important boundary is that Starboard is an aggregation and reporting layer. It does not eliminate the underlying scanners or their result formats. Its central design decision is to normalize access around Kubernetes resources, which can be useful where reports need to remain visible to cluster tools and policy workflows. The README also calls the project incubating and warns that APIs and CRDs may change, even though releases are intended to remain backward compatible where possible.

Operator and CLI execution paths

Starboard supports two documented operating modes. As a Kubernetes operator, it can update security reports in response to cluster changes. The README gives examples of initiating vulnerability scans when a new Pod starts and running CIS Benchmarks when a new Node is added. This mode is suited to continuous reconciliation of cluster state, but it also introduces operator deployment, permissions, image lifecycle, and report-management concerns.

As a command, Starboard can trigger scans and present risks through a kubectl-compatible interface. The documentation also positions this mode for CI/CD pipelines, where a job can request a scan or consume security information without waiting for an operator to react to a cluster event. The command mode is therefore better suited to explicit scan orchestration, while the operator mode is intended for automatic updates.

The repository layout reflects this split. The top-level `cmd/` directory contains separate `starboard` and `starboard-operator` entry points, while `pkg/`, `deploy/`, `build/`, and `docs/` hold supporting implementation and deployment material. The Go module is named `github.com/aquasecurity/starboard`, and `go.mod` lists Kubernetes client libraries, controller-runtime, Open Policy Agent, Cobra, and other dependencies. These entries confirm a Kubernetes client and operator implementation, but the README does not provide a complete command reference or a complete production installation manifest.

Report types and integration boundaries

Starboard's value depends on the range of findings it can represent, but each report has a different production owner and lifecycle. Vulnerability reports concern workload images, configuration audits concern Kubernetes resources, and infrastructure checks concern cluster components such as nodes. CIS compliance and the documented NSA and CISA hardening guidance add policy-oriented reporting, while penetration test results provide a different class of evidence.

The README specifically mentions predefined configuration rules and custom Open Policy Agent policies. This gives teams a path for organization-specific checks, but it also means policy distribution and rule ownership matter. The repository does not define which report fields are guaranteed stable or how a particular scanner failure is represented in every CRD. It explicitly warns that some APIs and Custom Resource Definitions may change, so consumers should treat the CRD schema as part of the integration contract rather than as an incidental output format.

The Go module and Kubernetes API approach can simplify access for controllers, dashboards, and custom automation. They do not make every security tool behave identically. Scanner availability, credentials, cluster permissions, policy content, and report retention remain separate concerns that an adopting team must document for its environment.

Installation and first Starboard scan

The README does not give a self-contained installation command for either component. It directs users to the official Starboard documentation for installation, configuration, troubleshooting, and quick starts. For the command, it points to the binary releases and a Getting Started guide. For the operator, it points to static YAML manifests and a separate Getting Started guide. Because the README does not include exact download URLs, flags, ports, environment variables, or manifest commands, those details should be taken from the linked project documentation rather than inferred here.

A first real use follows two documented paths. For a command-oriented workflow, install the Starboard command from the binary releases, follow the CLI Getting Started guide, and use the resulting vulnerability and configuration audit reports. For an operator workflow, install the static YAML manifests, then follow the operator Getting Started guide. The operator path is expected to create or update reports as workloads and other cluster resources change.

The repository's `Makefile` confirms that the source tree contains separate build targets for the CLI, operator, and scanner image, but the complete file does not provide enough target text to present a verified build tutorial. The visible default build command is assembled from repository targets, yet a reader should not substitute it for the documented release installation without checking the current documentation.

Standalone discontinuation and maintenance implications

The repository's own status notice says Starboard is joining Trivy. It states that the Starboard CLI has been reintroduced as `trivy kubernetes`, while the operator has continued as Trivy-Operator with a focus on Trivy capabilities. New features, pull requests, and issues are not being accepted, and contributions are directed to Trivy-Operator and Trivy CLI.

This changes the maintenance decision more than the release date alone. The repository is not archived, and the last push was on 2026-06-10, but the project explicitly announces discontinuation. Recent release entries, including `v0.15.38` on 2026-06-02, show that releases continued during a transition period. They should not be interpreted as a promise of ongoing standalone development. Teams planning a new deployment should treat the supported direction as Trivy rather than assume that Starboard's CRD and CLI surface will remain stable indefinitely.

Upgrade cost depends on whether a team runs the CLI, the operator, both, or has written controllers against Starboard CRDs. Migration may require changing image names, commands, manifests, or report consumers, but the README does not provide a compatibility matrix or a documented migration procedure. That absence is material for automation that queries specific CRD kinds or fields.

The repository identifies the license as Apache-2.0. Organizations should review the repository's `LICENSE` file for the applicable notice, modification, distribution, and patent terms. This review is a compliance check, not legal advice, and the README does not claim that Apache-2.0 removes operational migration or compatibility costs.

Choosing Starboard, Trivy, or another security workflow

Starboard is a reasonable fit for an existing cluster security deployment that already stores reports as Kubernetes CRDs and depends on its operator or Go integration. In that situation, the immediate concern is continuity rather than new adoption. The operator can react to workload and node changes, while the CLI can support explicit scans and pipeline use. The Kubernetes API remains the central interface for retrieving findings.

Trivy and Trivy-Operator are the more appropriate direction for a new deployment because the Starboard repository explicitly directs users to those projects. The CLI functionality is represented by `trivy kubernetes`, and the operator functionality is available through Trivy-Operator. A team choosing among these options should compare report types, CRD names, scan triggers, policy support, and existing automation against the replacement project's documentation. The Starboard README does not establish feature parity in detail, so it cannot answer every migration question.

Starboard is the wrong choice when the requirement is a new standalone project, a feature request, or a long-term dependency on future Starboard changes. It is also a poor fit for an environment that cannot accept an additional Kubernetes controller or does not have the permissions required to run scans and write security reports. Teams that only need a one-off image vulnerability check may find the CLI-centric workflow more appropriate than deploying the full operator, although the documentation does not give a complete resource comparison.

Editorial conclusion

Existing teams should adopt Starboard only when maintaining an established deployment and its CRD reports is unavoidable. New Kubernetes security deployments should use Trivy or Trivy-Operator, first checking whether required report types, permissions, policies, and existing automation have a documented replacement.

Frequently asked questions

Official sources

1. aquasecurity/starboard on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases