anchore / anchore-engine

A service that analyzes docker images and scans for vulnerabilities
Apache License 2.0
1.58k stars 271 forks source link

No-DSA status in Debian Security Advisories is not well addressed #527

Open sibwara opened 4 years ago

sibwara commented 4 years ago

FEATURE REQUEST

anchore-cli version 0.7.2 on image debian:9.11 (stretch)

What happened

Several vulnerabilities are not detected by anchore following the approach described here : https://anchore.com/blog/how-many-cves/.
All the CVE with a "no-DSA" status are ignored by anchore, assuming that they are mitigated or corrected in another way.

What did you expect to happen

After a deep inspection of all the CVE detected by trivy and not by anchore, I can say that most of the no-DSA status over Debian stretch's CVE should not be ignored.

The case where the vulnerability is irrelevant or mitigated by another mean is quite rare and should not be regarded as the main rule. Most of the time, a vulnerability is accepted due to lack of time to fix.

Some of them have also the mention "(too intrusive to backport)" which clearly means that the vulnerability is present and should not be ignored.
For example:

This situation leads to medium/high severity vulnerabilities to be ignored in the results of anchore which is not an acceptable blindspot in the risk management.

Moreover, some CVE don't have a no-DSA status but are tagged as "unimportant" (see CVE-2011-4116 in https://security-tracker.debian.org/tracker/source-package/perl). Most of the time they will be less severe than the no-DSA CVEs, but they are detected by anchore.
So, finally anchore will raise a lot of minor/negligeable vulnerabilities and will ignore many medium/vulnerabilities.

Even if the approach of considering the no-DSA tag is smart, it is not enough well defined to assume that the vulnerability is not present.

Anchore should raise every applicable CVE to a Debian version even if a no-DSA status is associated and some CVE could be whitelisted when their status clearly mentions that they imply no risk (probably need a manual inspection)

zhill commented 4 years ago

Hi @sibwara sounds like the change you're suggesting is to remove the default behavior of filtering the no-dsa entries from the results. Anchore has those results we just hide them unless you explicitly request them. The policy for vulnerabilities also includes configurable behavior in that way.

I think this is a reasonable approach: make vendor_only=false in GET /image//vulnerabilties/all. Still leave the parameter available but do not filter unless explicitly requested to do so.

sibwara commented 4 years ago

If I set a vendor_only=false setting, will I see the CVE whose are not present due to backporting ?

I also suggest you that if you remove the NO-DSA tagged vuln from the result, you should also remove the "unimportant" ones as Debian will not fix them.

zhill commented 4 years ago

The resolution of CVEs via backports is handled by Debian. When they do the backport they typically release the package with an appropriate version bump and indicate that version as the fix in their security data. The vendor_only flag only removes vulnerability matches from the output of the API if they are marked as No-DSA, it doesn't affect the actual matching logic at all. If vendor_only=false is set then you're seeing all vulnerabilities that the system has matched for a given image for the dpkg db. Non-distro package types are unaffected (e.g. jar, npm, gem,..).

We generally have not added any behavioral changes in Anchore to the severity fields, only when there are specific flags with specific and documented semantics like no-dsa. Our policy capability and language is intended for filtering and building rules that let you exclude or highlight specific kinds of vulnerabilities based on their properties. See: https://docs.anchore.com/current/docs/overview/concepts/policy/policy_checks/#gate-vulnerabilities for details on the params available in the policy for handling vulnerability matches.