aquasecurity/trivy

Description When a dependency in [[packages.dependencies]] of pylock.toml (PEP 751) is specified by name only, e.g. { name = "beta" }, Trivy silently drops it from the dependency graph. As a result, the SBOM (CycloneDX dependsOn, SPDX relationships) is incomplete, and the package shows up directly under pylock.toml instead of under its parent. Vulnerability detection is not affected. Reproduced on v0.75.0 and main: mkdir pylock-name-only && cd pylock-name-only cat > pylock.toml <<'EOF' lock-version = "1.0" created-by = "minimal-reproducer" [[packages]] name = "alpha" version = "1.0.0" dependencies = [{ name = "beta" }] [[packages]] name = "beta" version = "2.0.0" EOF trivy fs --format cyclonedx --output bom.json . jq -c '.dependencies[]' bom.json [email protected] is expected to depend on [email protected], but its dependsOn is empty. If the selector is changed to { name = "beta", version = "2.0.0" }, the relationship appears. Such lock files are produced by real tools, e.g. Pex (see test_issue_2

Description For pnpm-lock.yaml v9, Trivy detects direct dependencies and their dev/prod status from the importers section. When an importer's version is written in the alias form <name>@<version>, the direct dependency is not matched to its snapshot. As a result, it is marked as indirect and Dev: true, and its whole production subtree stays dev as well. Without --include-dev-deps, these packages and their vulnerabilities disappear from the result. The alias form appears in at least two cases. 1. pnpm deploy with a workspace package pnpm --config.inject-workspace-packages=true deploy --prod records the workspace package as a file: dependency: importers: .: dependencies: repro-shared: specifier: repro-shared@file:///<path>/packages/shared version: repro-shared@file:///<path>/packages/shared snapshots: '@xmldom/[email protected]': {} repro-shared@file:///<path>/packages/shared: dependencies: '@xmldom/xmldom': 0.8.13 Result (trivy fs pnpm-lock.yaml -

Description When a dependency in /lib/apk/db/installed uses the ~ (prefix match) operator, e.g. D:python3~3.12, Trivy silently drops it from the OS package dependency graph. As a result, the SBOM (CycloneDX dependsOn, SPDX relationships) is incomplete. Vulnerability detection is not affected. Reproduced on v0.75.0 and main: cat > Dockerfile <<'EOF' FROM alpine:3.20 RUN apk add --no-cache libxml2-static EOF docker build -t trivy-fuzzy-dep . docker run --rm trivy-fuzzy-dep apk info -R libxml2-static # python3~3.12 trivy image --format cyclonedx --output sbom.json trivy-fuzzy-dep jq -c '.dependencies[] | select(.ref | contains("libxml2-static"))' sbom.json libxml2-static is expected to depend on python3, but its dependsOn is empty, even though python3 is installed and present in the SBOM. Discussed in #11342 Root cause trimRequirement() in pkg/fanal/analyzer/pkg/apk/apk.go strips the version from a dependency name only at <, > and =. The token python3~3.12 is kept as-is, isn't found in

Description The Alpine detector reports already fixed vulnerabilities for apk packages that have no o: (origin) field in /lib/apk/db/installed. Such packages show up in images whose packages are not built with abuild, e.g. Docker Hardened Images. Original report: #11311. Reproduction trivy image --pkg-types os dhi.io/git:2-alpine@sha256:c22bf201b598dabf2e84defb4fdddfb485cc91c215db92614b879b624795b8f2 ┌─────────┬────────────────┬──────────┬────────┬───────────────────┬───────────────┐ │ Library │ Vulnerability │ Severity │ Status │ Installed Version │ Fixed Version │ ├─────────┼────────────────┼──────────┼────────┼───────────────────┼─────────────

Description The check treats a TLS policy as secure only if its name matches one of two hard-coded values: checks/cloud/aws/elasticsearch/use_secure_tls_policy.rego recommended_tls_policies := { "Policy-Min-TLS-1-2-2019-07", "Policy-Min-TLS-1-2-PFS-2023-10", } is_tls_policy_secure(domain) if domain.endpoint.tlspolicy.value in recommended_tls_policies DomainEndpointOptions.TLSSecurityPolicy accepts four values: Policy-Min-TLS-1-0-2019-07 - minimum TLS 1.0, correctly reported Policy-Min-TLS-1-2-2019-07 - minimum TLS 1.2, accepted Policy-Min-TLS-1-2-PFS-2023-10 - TLS 1.2 to 1.3 with PFS, accepted Policy-Min-TLS-1-2-RFC9151-FIPS-2024-08 - TLS 1.3 with FIPS, reported as outdated, false positive Policy-Min-TLS-1-2-RFC9151-FIPS-2024-08 is the strictest of the four and is reported as an outdated policy. There is a second problem in the same rule. The value is compared without a value.is_known guard, so a value Trivy could not resolve, for example one coming from an unresolved va