trivy: Can trivy filter false positive vulnerabilities for centos 7 (epel, remi)?

Hi, Trivy team I use Trivy to scan centos:7 based image. However, I get many false positives in result.

Trivy version: 0.11.0 Base image: centos:7 (centos 7.8.2003) Trivy command: trivy --timeout 5m0s --vuln-type os -f json -q $image-name

Click to toggle contents of 'Dockerfile'
FROM centos:7
RUN yum upgrade -y

RUN yum install -y \
        https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm \
        https://rpms.remirepo.net/enterprise/remi-release-7.rpm \
    && \
    rpm --import \
        /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7 \
        /etc/pki/rpm-gpg/RPM-GPG-KEY-remi \
        /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 \
    && \
    yum-config-manager --enable remi,remi-php73 && \
    yum install -y \
        php

The result will contain the following:

Click to toggle contents of 'Result'
...
{
        "VulnerabilityID": "CVE-2015-5589",
        "PkgName": "php",
        "InstalledVersion": "7.3.22-1.el7.remi",
        "Layer": {
          "DiffID": "sha256:2c1f6971c560d8970f6f247d0040c4a48752eb8b9166aae0dc885dd9b7c732e9"
        },
        "SeveritySource": "redhat",
        "Title": "php: segmentation fault in Phar::convertToData on invalid file",
        "Description": "The phar_convert_to_other function in ext/phar/phar_object.c in PHP before 5.4.43, 5.5.x before 5.5.27, and 5.6.x before 5.6.11 does not validate a file pointer before a close operation, which allows remote attackers to cause a denial of service (segmentation fault) or possibly have unspecified other impact via a crafted TAR archive that is mishandled in a Phar::convertToData call.",
        "Severity": "MEDIUM",
        "CweIDs": [
          "CWE-20"
        ],
        "VendorVectors": {
          "nvd": {
            "v2": "AV:N/AC:L/Au:N/C:C/I:C/A:C",
            "v3": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"
          },
          "redhat": {
            "v2": "AV:N/AC:M/Au:N/C:N/I:N/A:P"
          }
        },
        "CVSS": {
          "nvd": {
            "V2Vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C",
            "V3Vector": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
            "V2Score": 10,
            "V3Score": 9.8
          },
          "redhat": {
            "V2Vector": "AV:N/AC:M/Au:N/C:N/I:N/A:P",
            "V2Score": 4.3
          }
        },
        "References": [
          "http://git.php.net/?p=php-src.git;a=commit;h=bf58162ddf970f63502837f366930e44d6a992cf",
          "http://openwall.com/lists/oss-security/2015/07/18/1",
          "http://php.net/ChangeLog-5.php",
          "http://seclists.org/oss-sec/2015/q3/141",
          "http://www.debian.org/security/2015/dsa-3344",
          "http://www.securityfocus.com/bid/75974",
          "https://bugs.php.net/bug.php?id=69958",
          "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5589",
          "https://usn.ubuntu.com/usn/usn-2758-1"
        ],
        "PublishedDate": "2016-05-16T10:59:00Z",
        "LastModifiedDate": "2017-11-04T01:29:00Z"
      }
...

Based on the Description and References, the vulnerability does not affect the installed 7.3.22-1.el7.remi PHP version. I have attached only one vulnerability for PHP, but there are 156 false positive vulnerabilities in total. Many false positive vulnerabilities for another packages also, but I chose PHP for example.

Why are many false positive for centos? Could I change configuration to filter false positive?

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 15 (7 by maintainers)

Commits related to this issue

Most upvoted comments

@rahul2393 Can you help them reproduce it?