Trivy is a comprehensive, production-grade security scanner for container images, filesystems, Git repositories, Kubernetes clusters, cloud infrastructure (IaC), and virtual machines. It detects vulnerabilities in OS packages and language-specific dependencies, scans for IaC misconfigurations (Terraform, CloudFormation, ARM, Ansible, Helm, Dockerfile), secrets, and license compliance. The architecture is modular: a CLI entry point (`cmd/trivy/main.go`) orchestrates scanning via a file analysis engine (`pkg/fanal`), dependency parsers (`pkg/dependency/parser`), vulnerability detectors (`pkg/detector`), IaC scanners with Rego-based policies (`pkg/iac`), and multiple output formats (JSON, SARIF, CycloneDX, SPDX, table, etc.). It supports client-server mode via gRPC, a plugin system, WASM modules, and VEX/SBOM attestation integration. The codebase is well-structured with clear separation of concerns, extensive test coverage, and many reusable utility packages (parallel processing, generic sets, caching, version constraints, license expression parsing). It is actively maintained with frequent releases and a large community.
Syft is a production-grade CLI tool and Go library for generating Software Bills of Materials (SBOMs) from container images, filesystems, directories, and OCI artifacts. It detects and catalogs packages across 40+ ecosystems (Alpine, Debian, RPM, Python, Java, Go, Ruby, Rust, JavaScript, .NET, etc.) by parsing lockfiles, package databases, binary metadata, and source manifests. The tool outputs SBOMs in multiple formats including CycloneDX (JSON/XML), SPDX (JSON/tag-value), Syft JSON, and GitHub Dependency Snapshots, with version-aware encoding and decoding. Architecturally, Syft uses a modular cataloger system where each ecosystem implements a `generic.Cataloger` with parser functions registered by file globs or MIME types. A task-based pipeline orchestrates file indexing, package cataloging, dependency resolution, and relationship linking. The system supports both library integration via `syft.CreateSBOM()` and a CLI with cobra commands (`scan`, `attest`, `convert`, `cataloger`). A bubbletea-based TUI provides real-time progress feedback during image pulls and cataloging. External dependencies include `stereoscope` for container image access, `cosign` for attestation signing, and `go-partybus` for event-driven UI. Key entry points include `cmd/syft/main.go` (CLI), `syft/create_sbom.go` (library API), `syft/get_source.go` (source resolution), and the format encoders/decoders in `syft/format/`. The codebase demonstrates strong engineering practices: extensive test coverage (unit, integration, snapshot), CI/CD with GitHub Actions, auto-generated JSON schemas, and drift-check scripts for capabilities and schema. Notable reusable components include the generic cataloger framework, the dependency resolver, and the file resolver abstraction.
ko is a CLI tool for building container images from Go source code. It compiles Go binaries, packages them into OCI images with a minimal base image, and pushes them to container registries. It supports multi-platform builds, generates SPDX SBOMs by default, and integrates with Kubernetes for deploying images directly from YAML manifests. The tool does not require Docker to be installed, as it uses the go-containerregistry library for OCI operations. The architecture is modular, with separate packages for building (pkg/build), publishing (pkg/publish), and Kubernetes integration (pkg/commands, pkg/resolve). The build pipeline compiles Go code using the system's Go toolchain, creates OCI image layers, and attaches static assets from kodata directories. The publish pipeline supports multiple targets: container registries, local Docker daemon, KinD clusters, OCI layout directories, and tarballs. Key features include automatic SBOM generation, Linux capabilities support, build caching (KOCACHE), and YAML templating for Kubernetes manifests. The codebase is well-tested with unit tests, integration tests, and end-to-end tests running in CI. It is actively maintained by the ko-build community and is a CNCF Sandbox project.
Buildah is a command-line tool for building OCI-compliant container images without requiring a daemon. It focuses on image creation tasks such as building from Dockerfiles/Containerfiles, managing working containers, committing images, and pushing/pulling to registries. The architecture is modular, separating CLI command handling (using Cobra), core build logic, storage abstraction, and utility packages. Key features include rootless operation, multi-platform support (Linux/FreeBSD), SBOM generation, and confidential workload encryption via SEV/SNP. The tool is designed for integration with container ecosystems like Podman and Kubernetes, emphasizing security and flexibility in image building workflows.
Zarf is an air-gap native package manager for Kubernetes. It provides a CLI tool to build, sign, publish, and deploy immutable software bundles (packages) into disconnected Kubernetes clusters. The architecture consists of a Go CLI that orchestrates package lifecycle (create, deploy, remove, publish, inspect), a mutating admission webhook agent that rewrites container image references and Git URLs to point to internal Zarf services, and a set of embedded tools (Helm, K9s, Syft, Cosign, etc.). Key capabilities include OCI-based package distribution, Helm chart and manifest deployment, Git repository mirroring, SBOM generation, and Cosign-based signing/verification with both key and keyless modes. The codebase is well-structured with extensive unit and e2e tests, a clean separation between API versions (v1alpha1/v1beta1) with bidirectional conversion, and several reusable subsystems for value merging, archive extraction, template processing, and Kubernetes resource waiting. It is actively maintained with frequent releases and a large community (2000+ stars).
sbomqs is a command-line tool and Go library for evaluating the quality and compliance of Software Bill of Materials (SBOM) documents. It parses SBOMs in CycloneDX, SPDX 2.x, and SPDX 3.0 formats and scores them against multiple industry standards: NTIA Minimum Elements (2021/2025/2026), BSI TR-03183-2 (v1.1, v2.0, v2.1), FSCT v3, OpenChain Telco v1.1, and an Interlynk comprehensive profile. The tool outputs scores, detailed compliance reports, and feature lists, and can be integrated with Dependency-Track and policy engines. It is used in production by several platforms and has been cited in academic research evaluating over 78,000 SBOMs. The codebase is well-structured with clean interfaces, extensive test coverage, and a modular architecture that separates parsing, scoring, compliance checking, and reporting. A notable architectural trade-off is the coexistence of two scoring engines (legacy v1 and v2), which adds complexity but allows incremental migration. The library is embeddable as a Go module, and the CLI supports multiple output formats (basic, detailed, JSON).
vexctl is a command-line tool for creating, applying, and attesting VEX (Vulnerability Exploitability eXchange) data. It is built as a single binary using Cobra for CLI, with subcommands for creating VEX documents, merging them, filtering SARIF scanner results, generating attestations, and validating documents against the OpenVEX specification. The tool integrates with Sigstore for keyless signing and supports multiple VEX formats (OpenVEX native, CSAF, CycloneDX). It can attach VEX attestations to container images via OCI referrers API or legacy tag layout. The architecture follows a clean separation of concerns: CLI handlers in `internal/cmd/` delegate to a core library in `pkg/ctl/`, which uses an interface (`Implementation`) for testability. The `pkg/attestation/` package handles in-toto attestations and Sigstore signing independently. The codebase demonstrates strong engineering practices with dependency injection, options struct patterns, and comprehensive test data. While primarily an application, it also processes vulnerability data (SARIF, VEX documents) and includes validation logic that could be reused in other security tooling.
FOSSLight Hub is an open-source compliance and security platform that manages open source software (OSS) inventories, licenses, vulnerabilities, and compliance workflows. It provides a web interface for OSS identification, license management, vulnerability tracking, self-check audits, SBOM generation (SPDX, CycloneDX), and supply chain management. The system is architected as a Spring Boot backend with MyBatis persistence, JWT-based authentication, and REST APIs (v2 and lite). It features a dual frontend: a legacy server-rendered UI using jqGrid and Thymeleaf, and a modern Next.js 'lite' client built with React, Tailwind CSS, and Recoil. Key entry points include API controllers (e.g., LiteOssController, ApiOssV2Controller), service layer components, and scheduled tasks for NVD/OSV vulnerability synchronization. External dependencies include MariaDB, a mail server, external license APIs (GitHub, ClearlyDefined), NVD/OSV vulnerability feeds, and the FOSSLight Scanner. The platform is actively developed with continuous releases and a growing feature set, though it carries some technical debt from legacy frontend libraries and enterprise-specific hardcoding.
This repository serves as the central documentation and community hub for the AboutCode family of open-source projects focused on software composition analysis (SCA). It hosts the documentation, contributing guidelines, release notes, and links to the actual code repositories for tools such as ScanCode Toolkit, VulnerableCode, DejaCode, and others. The repository is structured to build and maintain a static documentation site using Sphinx, integrated with Read the Docs for automated hosting. The codebase primarily consists of documentation source files (reStructuredText), Sphinx configuration, and standard project setup files (Makefile, configure scripts, etc.). It does not contain the functional code of the SCA tools themselves but provides the necessary infrastructure for documentation generation and community engagement. The project emphasizes clear contribution processes, code of conduct, and issue templates to facilitate collaboration. Despite being a documentation repository, it follows good software engineering practices with automated documentation builds, style checking (Doc8), and linting (Ruff) configured via GitHub workflows. The minimal actual code (setup scripts and configuration) is functional and maintainable, though it lacks highly reusable components beyond standard documentation project boilerplate. The repository is actively maintained, as evidenced by recent commits and ongoing workflow executions.