Software Composition Analysis (SCA)

Understand how SBOM Observer approaches software composition analysis across codebases, containers, and build pipelines.

Software Composition Analysis (SCA) inventories the open-source and third-party components inside your software so you can detect vulnerabilities, policy violations, and licensing risks.

Observer builds on SBOM standards like CycloneDX and SPDX to make SCA results actionable inside policies, CI/CD gates, and governance workflows.

Observer CLI is free to use, fully open source for auditability, and designed so teams can inspect exactly how dependency data is collected before it enters security workflows.

Why SCA matters

Visibility starts with a trustworthy inventory. Observer surfaces every direct library, transitive dependency, and container layer so you can answer “what’s inside?” without juggling multiple scanners.

Once you know what ships, you can attach CVEs, EPSS scores, and VEX context to the exact components that matter. That precision keeps remediation aligned with production reality instead of chasing noise.

SCA evidence also satisfies regulatory pressure (NTIA minimum elements, CRA, NIS2, contract clauses) because Observer’s SBOMs embed the metadata auditors ask for.

Finally, the same SBOMs flow directly into policies and CI/CD checks, so automation can halt risky releases before they reach customers.

How Observer CLI performs SCA

Observer CLI provides one SBOM-first workflow for scanning multiple targets while still producing high-fidelity CycloneDX documents:

Filesystems & repos: observer fs auto-detects ecosystems (npm, pip, Maven, go modules, etc.) and keeps monorepo components separate or merged based on your flags.
Container images: observer image inspects OS packages and application dependencies directly from an OCI or Docker image.
Build processes: observer build attaches to compilers (C/C++ and mixed-language builds) to capture system libraries that static scanners miss.

Each target outputs CycloneDX SBOMs that flow into the same policy and CI/CD enforcement pipelines.

Our "silver bullet" SCA approach

Traditional SCA tools force you to pick a single scanner per ecosystem. Observer CLI takes a different approach:

The CLI delegates collection to the best available scanner per target (osv-scalibr, Trivy, Syft) and layers Observer-specific enhancements, like monorepo awareness and metadata normalization, on top. If one scanner is missing, Observer automatically falls back to another so scans continue without manual intervention.

Delegated scanners and fallbacks

Target	Primary engine	Fallback / optional engines	Notes
Filesystems & builds	osv-scalibr	Trivy	Detects package managers and produces CycloneDX; Trivy fills gaps for unknown binaries.
Container images	Trivy	Syft (`--scanner syft`)	Trivy covers OS and app packages; Syft can be selected explicitly when preferred.
Kubernetes snapshots	Trivy	Syft	Same delegation model as container images, with cluster-aware context.

Observer then standardizes every SBOM, injects metadata from observer.yaml, and ships the result to policies, dashboards, and exports.

Benefits of the delegated model

Consistent output: Regardless of which engine gathered data, Observer normalizes results into a single CycloneDX SBOM that downstream tools understand.
Resilience: Missing binaries or unsupported ecosystems no longer break pipelines because the CLI can fall back automatically.
Extensibility: As new scanners emerge, Observer can wire them into the delegation layer without changing your CI/CD scripts.
Richer policies: Combining delegated SCA data with Observer-specific metadata ensures policies can reason about namespaces, suppliers, and deployment targets.

Learn the specific commands in the Observer CLI reference, especially the Scanner Delegation section.
Follow the Observer CLI getting-started guide for installation and quick wins.
Explore Policies & Evaluations to see how SCA results drive enforcement.
Review Policy Data Input to understand the payload that policies receive after SCA is complete.