Vulnerability Static Analysis for Containers

Clair

Docker Repository on Quay PkgGoDev IRC Channel

Note: The main branch may be in an unstable or even broken state during development. Please use releases instead of the main branch in order to get stable binaries.

Clair Logo

Clair is an open source project for the static analysis of vulnerabilities in application containers (currently including OCI and docker).

Clients use the Clair API to index their container images and can then match it against known vulnerabilities.

Our goal is to enable a more transparent view of the security of container-based infrastructure. Thus, the project was named Clair after the French term which translates to clear, bright, transparent.

The book contains all the documentation on Clair's architecture and operation.

Community

Contributing

See CONTRIBUTING for details on submitting patches and the contribution workflow.

License

Clair is under the Apache 2.0 license. See the LICENSE file for details.

Owner
QUAY
[builds, analyzes, distributes] your container images
QUAY
Comments
  • what is considered as a valid path while posting layers to clair

    what is considered as a valid path while posting layers to clair

    Hi,

    In #127 , you mentioned that I should put a http url for clair to access the target layer archive. I used "GET /v1/images/(image_id)/layer" as described in docker registry v1 api (indicating this is the right way of getting layer binary data stream). I tested and I can successfully obtain binary data of the target layer. Therefore I set "https://REGISTRY_URL:8080/v1/images/LAYER_ID/layer" as the path to post for clair post, am I right? The URL is exactly the same I used to download layer binary data.

    However, I encountered the same error as described in the previous 307 issue (#127). Could you please let me know if I am using the right path? or this is caused by some other reasons?

    The data I posted (post_layer.txt)

    { "Layer": { "Name": LAYER_NAME, "Path": https://REGISTRY_URL:8080/v1/images/LAYER_ID/layer, "ParentName": PARENT_NAME, "Format": "Docker" } }

    Curl request & response:

    curl -v -X POST -d @post_layer.txt http://localhost:6060/v1/layers/

    • Hostname was NOT found in DNS cache
    • Trying 127.0.0.1...
    • Connected to localhost (127.0.0.1) port 6060 (#0)

      POST /v1/layers/ HTTP/1.1 User-Agent: curl/7.35.0 Host: localhost:6060 Accept: / Content-Length: 336 Content-Type: application/x-www-form-urlencoded

    • upload completely sent off: 336 out of 336 bytes < HTTP/1.1 307 Temporary Redirect < Location: /layers < Date: Wed, 30 Mar 2016 17:12:44 GMT < Content-Length: 0 < Content-Type: text/plain; charset=utf-8 <
    • Connection #0 to host localhost left intact

    Shall I use http instead of https? Our environment only support https right now. Could you let me know where/how I can possibly debug this issue? thanks

  • Add openSUSE/SLES support

    Add openSUSE/SLES support

    In order to integrate openSUSE/SLES including the available patches for CVEs I have started to work on this pull request. I already opened this pull request to get feedback early as possible. Below you can see a checklist for the remaining items.

    • [x] Fetcher for openSUSE
    • [x] Write tests for openSUSE fetcher
    • [x] Fetcher for SLES
    • [x] Write tests for SLES fetcher

    Do I miss something? Should we abstract the shared functionality from RedHat and openSUSE/SLES?

  • Integrate clairctl

    Integrate clairctl

    contrib: integrate command-line tool hyperclair into clairclt package

    migrate the wemanity-belgium/hyperclair command line tool into clair.

    Command line tool as few commands:

    Analyse your docker image with Clair, directly from your registry.
    
    Usage:
      clairclt [command]
    
    Available Commands:
      analyse     Analyse Docker image
      health       Get Health of underlying services
      pull            Pull Docker image information
      push         Push Docker image to Clair
      report        Generate Docker Image vulnerabilities report
      version     Get Versions of clairclt and underlying services
    
    Flags:
          --config string   config file (default is ./.hyperclair.yml)
      -h, --help            help for clairclt
    
    Use "clairclt [command] --help" for more information about a command.
    
    

    Fixes #148

  • Clair does not detect Debian vulnerability

    Clair does not detect Debian vulnerability

    Description of Problem

    I have an image that I know contains a version of openssh-client that is vulnerable to CVE-2019-6111 but when I scan it in Clair it does not detect this vulnerability. Having dug into the problem I think there are two issues, firstly the packages in any layers other than the base are not detected, secondly when a package is a binary package it is not matched to its source. More details on both of these below.

    Problem 1: Non-base layers not scanned

    Problem description

    I have the following dockerfile that installs a vulnerable version of openssh-client:

    FROM debian:stretch-slim
    
    RUN echo 'deb http://snapshot.debian.org/archive/debian/20170625T040030Z stretch-proposed-updates main' >> /etc/apt/sources.list && \
      apt-get -o Acquire::Check-Valid-Until=false update && \
      apt-get install openssh-client=1:7.4p1-10+deb9u1 -y
    

    Expected Outcome

    I expect to see the openssh-client listed in the list of installed packages and it to be vulnerable.

    Actual Outcome

    openssh-client does not appear in the list of installed packages. I looked at what is in the database and see that the layer does exist for the manifest as:

    SELECT COUNT(DISTINCT layer_id) FROM manifest_layer ml
    INNER JOIN manifest m
    ON m.id=ml.manifest_id
    WHERE m.hash='<HASH>'
    

    Returns 2 layers as expected, however, no packages are loaded from the second layer (that contains the openssh-client as the following only returns 1:

    SELECT COUNT(DISTINCT psa.layer_id) FROM package p
    INNER JOIN package_scanartifact psa
    ON psa.package_id=p.id
    INNER JOIN manifest_layer ml
    ON ml.layer_id=psa.layer_id
    INNER JOIN manifest m
    ON m.id=ml.manifest_id
    WHERE m.hash='<HASH>'
    

    When looking at the logs I see a debug message come out saying:

    didn't find an os-release or lsb release file
    

    So I wonder if it is not scanning the extra layer because it does not have the base OS files, although I have not taken this investigation further.

    Problem 2: Binary packages are not matched to source vulnerabilities

    Problem description

    To continue my investigation I then squashed the image into a single layer with this Dockerfile:

    FROM debian:stretch-slim as base
    
    RUN echo 'deb http://snapshot.debian.org/archive/debian/20170625T040030Z stretch-proposed-updates main' >> /etc/apt/sources.list && \
      apt-get -o Acquire::Check-Valid-Until=false update && \
      apt-get install openssh-client=1:7.4p1-10+deb9u1 -y
    
    FROM scratch
    COPY --from=base / /
    

    Expected Outcome

    I expect to see the openssh-client listed in the list of installed packages and it to be vulnerable.

    Actual Outcome

    openssh-client now appeared in the list of installed packages but it was not vulnerable. The vulnerability report now contains the fact that the package is installed:

    "172": {
      "id": "172",
      "name": "openssh-client",
      "version": "1:7.4p1-10+deb9u1",
      "kind": "binary",
      "source": {
        "id": "171",
        "name": "openssh",
        "version": "1:7.4p1-10+deb9u1",
        "kind": "source",
        "normalized_version": "",
        "cpe": ""
      },
      "normalized_version": "",
      "arch": "amd64",
      "cpe": ""
    }
    

    Again I went to the database to try to figure out why this might not be vulnerable and see that the database only contains data about the binary vulnerabilities:

    SELECT COUNT(id) FROM vuln
    WHERE dist_id = 'debian' AND package_kind <> 'binary'
    

    Returns 0. Looking at what it has loaded for CVE-2019-6111 I ran:

    SELECT * FROM vuln
    WHERE dist_id = 'debian' AND name = 'CVE-2019-6111'
    

    Which returns two results, both with a package_name of openssh, i.e. the source package but the package_kind is binary in both cases. As I only have the openssh_client package installed and not the openssh package I think this is why it is not matching.

    Environment

    • Clair version/image: I ran:
    $ git checkout v4.0.5
    $ make local-dev-up-with-quay
    
    • Clair client name/version: I accessed the API via curl
    • Host OS: macos using docker
    • Kernel (e.g. uname -a): Darwin Kernel Version 20.4.0
    • Kubernetes version (use kubectl version): n/a
    • Network/Firewall setup: All on localhost
  • Unable to push image to clair: 400 Error

    Unable to push image to clair: 400 Error

    Running clair as docker container. From the logs I see that ubuntu, debian update fails.

    coreos_clair

    Is this the reason for clair not analyzing correctly? Kindly help

    Thanks

  • Grafeas integration

    Grafeas integration

    We are looking at Grafeas for managing our software supply chain metadata. As vulnerability scanning is a key component in this process I would like to integrate Clair with Grafeas. I'm currently working at doing such an integration by writing a third party client but I was thinking that maybe this could be done better by doing the integration directly between Clair and Grafeas instead.

    I don't have a proposal for how to best do this (or if it is even suitable), but if there are others that are interested maybe this could be the start of a discussion.

  • implement nodejs fetcher

    implement nodejs fetcher

    Implement nodejs fetcher by parsing api.nodesecurity.io/advisories. Cache the last 'updated_at' time of advisories to send a valid 'update' notification. (https://github.com/coreos/clair/issues/40)

    One problem is: there might be more than one fixed/affected package versions in a nodejs advisory.
    For example: https://nodesecurity.io/advisories/77

    Vulnerable: < 3.1.3 || >= 4.0.0 <4.1.1
    Patched: >=3.1.3 < 4.0.0 || >=4.1.1
    

    The current Feature seems not be able to handle this.

    Signed-off-by: liang chenye [email protected]

  • Migrate RHEL vulnsrc to something more accurate

    Migrate RHEL vulnsrc to something more accurate

    Description of Problem / Feature Request

    Clair currently uses OVAL definitions (https://www.redhat.com/security/data/oval/) for ingesting RHEL CVEs. OVAL is an older defintion and Redhat only supports it for "selected products". CVRF definitions (https://www.redhat.com/security/data/cvrf/) on the other hand seem to have more complete information. Are there any plans for Clair to update to using CVRF?

    Environment

    N/A

  • Cannot fetching update on rhel-based os

    Cannot fetching update on rhel-based os

    Hello!

    I try run clair on fedora and centos 6(binary builded on fedora 21). After start it have errors like -

    2015-11-16 07:44:08.473519 I | updater/fetchers: fetching Ubuntu vulneratibilities
    2015-11-16 07:44:08.473851 I | updater/fetchers: fetching Debian vulneratibilities
    2015-11-16 07:44:08.474215 I | updater/fetchers: fetching Red Hat vulneratibilities
    2015-11-16 07:46:11.600821 E | updater/fetchers: could not parse bzr branch output to get the revision number
    2015-11-16 07:46:11.600855 E | updater: an error occured when fetching update 'Ubuntu': could not download requested ressource.
    

    bzr versions 2.6.0 and 2.1.1.

    Can you help fix it?

  • Connection refused between docker container of clair and pgsql

    Connection refused between docker container of clair and pgsql

    When I try to run the docker container of clair, there is something wrong with the connection to my pgsql. The docker logs are quoted as follows.

    2016-04-05 10:27:47.078096 I | pgsql: running database migrations
    2016-04-05 10:27:47.079614 E | pgsql: dial tcp [::1]:5432: getsockopt: connection refused
    2016-04-05 10:27:47.079655 C | main: database: could not open database
    

    I have tried several ways and on different machines and the issue still exists.

  • Document usage

    Document usage

    How do I actually run clair against an image pushed to a registry?

    When I start it, it basically sits and does nothing:

    ➜  ~  docker run -p 6060:6060 -p 6061:6061 quay.io/coreos/clair --db-path=/tmp/foo.db --log-level=debug
    2015-11-14 16:54:44.631509 I | database: database at /tmp/foo.db does not exist yet, creating it
    2015-11-14 16:54:44.641627 I | api: starting Health API on port 6061.
    2015-11-14 16:54:44.642071 I | api: starting API on port 6060.
    2015-11-14 16:54:44.642431 I | updater: updater service started. lock identifier: 1d652969-2f8f-40e0-9ca2-79f0f9125101
    2015-11-14 16:54:44.642712 D | updater: attempting to obtain update lock
    2015-11-14 16:54:44.644510 I | updater: updating vulnerabilities
    2015-11-14 16:54:44.644664 I | updater/fetchers: fetching Ubuntu vulneratibilities
    2015-11-14 16:54:44.644901 I | updater/fetchers: fetching Debian vulneratibilities
    2015-11-14 16:54:44.647307 I | updater/fetchers: fetching Red Hat vulneratibilities
    2015-11-14 17:58:40.143125 N | database: Ignoring 16668 notifications
    2015-11-14 17:58:40.167581 I | updater: update finished
    2015-11-14 17:58:40.175431 D | database: Lock updater owned by 1d652969-2f8f-40e0-9ca2-79f0f9125101 has expired.
    2015-11-14 17:58:40.191551 D | updater: next update attempt scheduled for 2015-11-14 18:58:40.167676167 +0000 UTC.
    2015-11-14 19:35:17.925595 I | api: 200 GET /v1/versions (112.378µs)
    

    How can I get it to check a container's flaws?

  • Strict client

    Strict client

    This PR reworks the HTTP client framework inside of Clair.

    It removes the http.RoundTripper that modified passing requests (a source of some previous data races and recommended against in the documentation) in favor of some helper functions.

    • The signing is pulled out into a dedicated object that modifies requests, meaning the caller needs to have one and use it.
    • The user-agent setting is pulled into a wrapper around http.NewRequestWithContext This also means that if we want to enforce additional defaults on Requests, it can be done here without needing to hunt down call sites.
    • The client constructor now only cares about whether it should use a dialer that allows public networks or not.

    Then all the packages are updated to use this new API surface as needed.

  • build: version of clairctl and clair with git --tags

    build: version of clairctl and clair with git --tags

    When building clair repo with make container-build,the version is hard code in Dockerfile. This patch set the version with git --tags.

    Signed-off-by: Anquan Wu [email protected]

  • clair server (v4.4.4) don't with

    clair server (v4.4.4) don't with "docker-compose up -d or make local-dev"

    Description of Problem / Feature Request

    Hi, I hope you're having a grate day.

    After I clone the repository, I tried docker compose up and make without any results. the traefic is running but quay and clair doesn't. they gave me an 404 error when I tried to connect to the 6060 and 8443 ports go version go1.19.2 linux/amd64 I did the go mod tidy and vendor and also rebuild the containers

    Expected Outcome

    Actual Outcome

    Environment

    • Clair version/image: latest
    • Clair client name/version: NA
    • Host OS: Linux
    • Kernel (e.g. uname -a): Linux kali 5.18.0-kali5-amd64 #1 SMP PREEMPT_DYNAMIC Debian 5.18.5-1kali6 (2022-07-07) x86_64 GNU/Linux
    • Kubernetes version (use kubectl version):
    • Network/Firewall setup: NA
  • Unsupported scan results on Google Distroless images

    Unsupported scan results on Google Distroless images

    Hi

    When I push Google Distroless Images to my Quay registry, I've got Unsupported security scan results. (just tried with mcr.microsoft.com/azure-cognitive-services/vision/read:3.2-model-2022-04-30 )

    Expected Outcome Security findings based on CVE for Debian.

    Actual Outcome Unsupported

    Environment Clair version/image: clair-rhel8:v3.7.2

    the same was reported on Clair V2 but it got simply closed (https://github.com/quay/clair/issues/1001). now that we have Clair V4 the same problem still exists.

    any plans to fix this? is it fixable?

    thanx.ivo

  • Dockerfile: add plugin support files

    Dockerfile: add plugin support files

    This updates the Dockerfile to use the "-trimpath" flag to facilitate more repeatable builds, with an eye to supporting plugin loading. Another "builder" Dockerfile is added to use as a "builder"-style base.

    Signed-off-by: Hank Donnay [email protected]

Open Source runtime scanner for Linux containers (LXD), It performs security audit checks based on CIS Linux containers Benchmark specification
Open Source runtime scanner for Linux containers (LXD), It performs security audit checks based on CIS Linux containers  Benchmark specification

lxd-probe Scan your Linux container runtime !! Lxd-Probe is an open source audit scanner who perform audit check on a linux container manager and outp

Dec 26, 2022
Static analysis for CloudFormation templates to identify common misconfigurations
Static analysis for CloudFormation templates to identify common misconfigurations

cfsec What is it? cfsec scans your yaml or json CloudFormation configuration files for common security misconfigurations. Installation Home Brew - Mac

Nov 7, 2022
A Simple and Comprehensive Vulnerability Scanner for Container Images, Git Repositories and Filesystems. Suitable for CI
A Simple and Comprehensive Vulnerability Scanner for Container Images, Git Repositories and Filesystems. Suitable for CI

A Simple and Comprehensive Vulnerability Scanner for Containers and other Artifacts, Suitable for CI. Table of Contents Abstract Features Installation

Jan 1, 2023
🔭 Kubernetes out-cluster vulnerability scanner
🔭 Kubernetes out-cluster vulnerability scanner

Kubnerable Kubnerable is an out-cluster vulnerability scanner tool for Kubernetes resources. It comes with a predefined vulnerability database (vulner

Mar 26, 2022
Grafana Unauthorized arbitrary file reading vulnerability
Grafana Unauthorized arbitrary file reading vulnerability

CVE-2021-43798 Grafana Unauthorized arbitrary file reading vulnerability 8.3.1 (2021-12-07) Security: Fixes CVE-2021-43798 . For more information, see

Dec 25, 2022
A standalone exporter for vulnerability reports and other CRs created by Starboard.

starboard-exporter Exposes Prometheus metrics from Starboard's VulnerabilityReport custom resources (CRs). Metrics This exporter exposes two types of

Dec 14, 2022
Dockerized Go app for testing the CVE-2021-44228 vulnerability

docker-log4shell Simple Go app / Docker image for playing with the CVE-2021-44228 vulnerability. Hosts a simple file server and an ldap server that pr

Dec 12, 2021
Vulnerability-exporter - A Prometheus Exporter for managing vulnerabilities in kubernetes by using trivy
Vulnerability-exporter - A Prometheus Exporter for managing vulnerabilities in kubernetes by using trivy

Kubernetes Vulnerability Exporter A Prometheus Exporter for managing vulnerabili

Dec 4, 2022
Learning about containers and how they work by creating them the hard way
Learning about containers and how they work by creating them the hard way

Containers the hard way: Gocker: A mini Docker written in Go It is a set of Linux's operating system primitives that provide the illusion of a contain

Jan 7, 2023
A tool to build, deploy, and release any environment using System Containers.
A tool to build, deploy, and release any environment using System Containers.

Bravetools Bravetools is an end-to-end System Container management utility. Bravetools makes it easy to configure, build, and deploy reproducible envi

Dec 14, 2022
Provides an interactive prompt to connect to ECS Containers using the ECS ExecuteCommand API.
Provides an interactive prompt to connect to ECS Containers using the ECS ExecuteCommand API.

ecsgo Heavily inspired by incredibly useful gossm, this tool makes use of the new ECS ExecuteCommand API to connect to running ECS tasks. It provides

Dec 12, 2022
Aceptadora provides the boilerplate to orchestrate the containers for an acceptance test.

aceptadora Aceptadora provides the boilerplate to orchestrate the containers for an acceptance test. Aceptadora is a replacement for docker-compose in

Nov 16, 2022
Binary program to restart unhealthy Docker containers

DeUnhealth Restart your unhealthy containers safely Features Restart unhealthy containers marked with deunhealth.restart.on.unhealthy=true label Recei

Dec 22, 2022
Simple docker tui to list, start and stop your containers
Simple docker tui to list, start and stop your containers

docker-tui Simple docker tui that lets you list, start and stop your containers. Current status Rough, initial prototype. Build with This tool relies

Dec 2, 2022
A super simple demo to document my journey to reasonably sized docker containers.

hello-docker A super simple demo to document my journey to reasonably sized docker containers. Task at Hand Build a docker container as small as possi

Nov 30, 2021
Viewnode displays Kubernetes cluster nodes with their pods and containers.

viewnode The viewnode shows Kubernetes cluster nodes with their pods and containers. It is very useful when you need to monitor multiple resources suc

Nov 23, 2022
Truly Minimal Linux Distribution for Containers

Statesman Statesman is a minimal Linux distribution, running from memory, that has just enough functionality to run OCI-compatible containers. Rationa

Nov 12, 2021
This repository is where I'm learning to write a CLI using Go, while learning Go, and experimenting with Docker containers and APIs.

CLI Project This repository contains a CLI project that I've been working on for a while. It's a simple project that I've been utilizing to learn Go,

Dec 12, 2021