b1e78fe412
Some checks failed
Docs CI / lint-and-preview (push) Has been cancelled
- Added VulnTokenSigner for signing JWT tokens with specified algorithms and keys. - Introduced VulnTokenUtilities for resolving tenant and subject claims, and sanitizing context dictionaries. - Created VulnTokenVerificationUtilities for parsing tokens, verifying signatures, and deserializing payloads. - Developed VulnWorkflowAntiForgeryTokenIssuer for issuing anti-forgery tokens with configurable options. - Implemented VulnWorkflowAntiForgeryTokenVerifier for verifying anti-forgery tokens and validating payloads. - Added AuthorityVulnerabilityExplorerOptions to manage configuration for vulnerability explorer features. - Included tests for FilesystemPackRunDispatcher to ensure proper job handling under egress policy restrictions.
5.4 KiB
5.4 KiB
OS Package Managers (APK / DPKG / RPM)
StellaOps implementation
- Analyzer implementations reside under
src/Scanner/__Libraries/StellaOps.Scanner.Analyzers.OS.*(e.g.,...OS.Dpkg/DpkgPackageAnalyzer.cs,...OS.Rpm/RpmPackageAnalyzer.cs,...OS.Apk/ApkPackageAnalyzer.cs). - Each analyzer reads authoritative package databases (
/var/lib/dpkg/status, RPMDB headers,lib/apk/db/installed) and emits content-addressed fragments per layer. - Metadata includes source package, maintainer, vendor fields, dependencies/provides, license strings, and CVE hint extraction; file evidence captures configuration files and checksums.
- Results feed SBOM assembly with deterministic ordering and layer attribution, enabling replayable diff/manifests and provenance binding.
- Windows/macOS package ecosystems remain out of scope; analyzer backlog tracks feasibility for future releases.
Trivy implementation
- Package analyzers live under
pkg/fanal/analyzer/pkg(apk, dpkg, rpm). Parsers translate distro databases intotypes.Packagerecords for vulnerability matching. - RPM analyzers leverage distro-specific metadata (e.g., Red Hat content manifests) when available; dpkg/apk analyzers enumerate package lists and file paths for licensing purposes.
- Layer attribution is implicit via artifact walkers; outputs prioritise package inventories for scanning rather than deterministic fragment storage.
- Supported operating systems are catalogued in
docs/docs/coverage/os/index.md, which maps Alpine/Wolfi/Chainguard/MinimOS (apk), RHEL and rebuilds (dnf/yum/rpm), SUSE families (zypper), Photon/Azure/Amazon variants, Debian/Ubuntu, Bottlerocket, and Conda-based images to their package managers with per-distro version ranges (e.g.,docs/docs/coverage/os/rhel.md,.../ubuntu.md,.../suse.md,.../amazon.md,.../bottlerocket.md).[t1] - Container image profiles such as Google Distroless and Bitnami are tracked in the same coverage table, highlighting Trivy’s ability to repurpose cached feeds across common base images.[t1]
Snyk implementation
- The CLI exposes container scanning (
snyk container test) that uploads image metadata to Snyk’s SaaS backend for analysis; supported distribution lists are maintained in Snyk SaaS documentation rather than the CLI itself.[s1] - Requires authentication and network connectivity; no per-layer fragments or offline workflow beyond SaaS-managed results, and coverage expands as the SaaS service updates its advisory backends rather than local catalogers.[s1]
Grype implementation
- Source enumeration flows through Syft (
grype/pkg/syft_provider.go), after which distro-specific matchers operate (e.g.,grype/matcher/apk/matcher.go,grype/matcher/dpkg/matcher.go). - Matchers combine ecosystem lookups, upstream package indirection, and Anchore’s vulnerability DB; fixes and NAK handling (e.g., Alpine SecDB) are embedded in matcher logic.
- OS support mirrors Syft’s catalogers: dedicated matchers exist for APK (Alpine/Wolfi/Chainguard), DPKG/APT (Debian/Ubuntu), RPM (RHEL/Alma/Rocky/Amazon/SUSE), Portage, Bitnami stacks, and stock package inventories, all under
grype/matcher/**. The matcher set delegates to Anchore’s feed service to stay current with distro advisories.[g1] - Per-layer provenance is not retained; results align with Syft’s catalog and Anchore’s aggregated feeds.
Key differences
- Layer fragments: StellaOps persists per-layer fragments tied to content-addressed storage, whereas Trivy, Snyk, and Grype maintain package inventories without explicit fragment artifacts.
- Metadata depth: StellaOps records extensive vendor metadata and file evidence for replay; Trivy, Snyk, and Grype focus on match-relevant fields from their feeds.
- Provenance: StellaOps’ outputs integrate directly with attestation/diff pipelines, while Trivy, Snyk, and Grype assume downstream tools consume package lists without replay requirements.
Detection technique comparison
| Tool | Detection technique(s) | Merge / result handling | Notes |
|---|---|---|---|
| StellaOps | Deterministic DB parsing via `StellaOps.Scanner.Analyzers.OS.(Apk | Dpkg | Rpm); fragment mapping via OsComponentMapper`; provenance persisted in Surface.FS. |
| Trivy | Layer walkers + distro parsers in pkg/fanal/analyzer/pkg/*; optional manifest enrichment using vendor feeds. |
Packages aggregated per artifact; provenance/layer context not persisted, leaving downstream tooling to interpret results. | Coverage matrix enumerated in docs/docs/coverage/os/*.md. |
| Grype | Syft catalogers + matchers in grype/matcher/{apk,dpkg,rpm} leveraging Anchore feeds. |
Matchers run against Syft inventory and Anchore DB; no layer fragments retained. | Determinism depends on feed snapshots. |
| Snyk | Container scans upload image metadata to SaaS for analysis. | Results surfaced via SaaS dashboards/API; no local merge or provenance data. | Requires network connectivity; offline unsupported. |
References
- [t1]
/tmp/trivy-src/docs/docs/coverage/os/index.md - [s1]
/tmp/snyk-cli/README.md - [g1]
/tmp/grype-data/grype/matcher/apk/matcher.go,/tmp/grype-data/grype/matcher/dpkg/matcher.go,/tmp/grype-data/grype/matcher/rpm/matcher.go