1d962ee6fc
Some checks failed
Docs CI / lint-and-preview (push) Has been cancelled
This commit introduces the OpenSslLegacyShim class, which sets the LD_LIBRARY_PATH environment variable to include the directory containing OpenSSL 1.1 native libraries. This is necessary for Mongo2Go to function correctly on Linux platforms that do not ship these libraries by default. The shim checks if the current operating system is Linux and whether the required directory exists before modifying the environment variable.
36 lines
4.1 KiB
Markdown
36 lines
4.1 KiB
Markdown
# 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 into `types.Package` records 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.
|
||
|
||
### 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`
|