Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

trivy fails to scan apk-based containers without /etc/os-release matching alpine #1975

Closed
kaniini opened this issue Apr 11, 2022 · 7 comments · Fixed by #1987
Closed

trivy fails to scan apk-based containers without /etc/os-release matching alpine #1975

kaniini opened this issue Apr 11, 2022 · 7 comments · Fixed by #1987
Assignees
Labels
kind/bug Categorizes issue or PR as related to a bug.

Comments

@kaniini
Copy link

kaniini commented Apr 11, 2022

Description

Trivy fails to scan packages in the apk database unless it thinks the image is alpine-derived. This makes trivy incapable of scanning many containers based on APK distributions that do not use alpine-base package, such as containers based on Adelie Linux or Distroless Alpine.

What did you expect to happen?

Trivy successfully scans packages in any container with a /lib/apk/db/installed file.

What happened instead?

Trivy fails to detect the package content of the container when an Alpine /etc/os-release file is not present.

Output of run with -debug:

pestilence:~/apko$ trivy --debug i ghcr.io/distroless/busybox:latest
2022-04-11T17:22:51.080Z        DEBUG   Severities: UNKNOWN,LOW,MEDIUM,HIGH,CRITICAL
2022-04-11T17:22:51.081Z        DEBUG   cache dir:  /home/kaniini/.cache/trivy
2022-04-11T17:22:51.081Z        DEBUG   DB update was skipped because the local DB is the latest
2022-04-11T17:22:51.081Z        DEBUG   DB Schema: 2, UpdatedAt: 2022-04-11 12:11:14.928170782  0000 UTC, NextUpdate: 2022-04-11 18:11:14.928170282  0000 UTC, DownloadedAt: 2022-04-11 17:22:34.356055373  0000 UTC
2022-04-11T17:22:51.081Z        DEBUG   Vulnerability type:  [os library]
2022-04-11T17:22:51.615Z        DEBUG   Image ID: sha256:cfe03db3a80f14be22797135beab1cab40501a6752a9161eddcb28435ae1929e
2022-04-11T17:22:51.615Z        DEBUG   Diff IDs: [sha256:2009254c99bf6f1a7c34ae2c192dc1225608ec1f13dd634951e0f48949914d32]
2022-04-11T17:22:51.616Z        DEBUG   OS is not detected and vulnerabilities in OS packages are not detected.
2022-04-11T17:22:51.616Z        DEBUG   Detected OS: unknown
2022-04-11T17:22:51.616Z        INFO    Number of language-specific files: 0

Output of trivy -v:

Version: 0.25.0
Vulnerability DB:
  Version: 2
  UpdatedAt: 2022-04-11 12:11:14.928170782  0000 UTC
  NextUpdate: 2022-04-11 18:11:14.928170282  0000 UTC
  DownloadedAt: 2022-04-11 17:22:34.356055373  0000 UTC

Additional details (base image name, container registry info...):

An example is ghcr.io/distroless/busybox

@kaniini kaniini added the kind/bug Categorizes issue or PR as related to a bug. label Apr 11, 2022
@knqyf263
Copy link
Collaborator

Thanks for the report. How can we identify Alpine version?

@kaniini
Copy link
Author

kaniini commented Apr 11, 2022

Figuring out which security feeds apply to a given image is what the new /etc/secfixes.d stuff is supposed to address, but you could also figure it out from /etc/apk/repositories perhaps. There are other distributions using apk which trivy cannot scan right now, but grype can.

@knqyf263
Copy link
Collaborator

Thanks. I played with ghcr.io/distroless/busybox

$ cat etc/apk/repositories
http://dl-cdn.alpinelinux.org/alpine/edge/main
$ ls etc/secfixes.d
ls: cannot access 'etc/secfixes.d': No such file or directory

We should take /etc/apk/repositories. And edge is actually interesting. Can we always take the latest alpine version?

@knqyf263
Copy link
Collaborator

knqyf263 commented Apr 11, 2022

BTW, I was curious how Grype detects Alpine version and took a quick look at their source code. They try to find advisories from Alpine secfixes, but it cannot do since the distro is "busybox". I inspected the value in debugging and confirmed it was not "alpine".
https://github.com/anchore/grype/blob/637a061532000223b3dfe6f655ae9c6696162f6e/grype/matcher/apk/matcher.go#L142-L145

Then, they fall into CPE matching.
https://github.com/anchore/grype/blob/637a061532000223b3dfe6f655ae9c6696162f6e/grype/matcher/apk/matcher.go#L147-L150

If Grype shows some vulnerabilities in apk-based distributions, I guess they come from CPE, not Alpine secfixes.

@kaniini
Copy link
Author

kaniini commented Apr 11, 2022

Thanks. I played with ghcr.io/distroless/busybox

We haven't added secfixes.d feeds for the distroless images yet. It's coming soon. ghcr.io/distroless/alpine-base:latest is based on alpine-base in edge and has the feeds.

@knqyf263
Copy link
Collaborator

Oh, I see. I thought edge is an alias of the latest version, but it seems to be wrong. We'll add the support for /etc/apk/repositories and /etc/secfixes.d soon. Thanks!

@knqyf263
Copy link
Collaborator

v0.26.0 is out.
#2001

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants