This the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

  • 1:
    • 1.1:
    • 2:
      • 3:
        • 4:
          • 4.1:
            • 4.2:
              • 4.3:
              • 5:
                • 6:
                  • 6.1:
                  • 7:
                    • 8:
                      • 9:
                        • 10:
                          • 10.1:
                          • 11:
                            • 12:

                              Scanning

                              Two Types of Scanning

                              As of May 2021, Sysdig Secure includes two different types of scanning for vulnerabilities:

                              • Image scanning This includes all prior scanning tools, policies, alerts, etc. in Sysdig Secure and focuses on scanning the container images in an environment.

                              • Host scanning: (New) This feature, deployed via the Node Analyzer, scans the host operating system, whether OS (e.g rpm, dpkg) or non-OS (e.g. Java packages, Ruby gems).

                              Host scanning documentation is self-contained; the rest of the topics in this Scanning module concern image scanning.

                              How Sysdig Image Scanning Works

                              Image scanning allows you to scan container images for vulnerabilities, secrets, license violations, and more. It can be used as part of a development build process, can validate images added to your container registry, and can scan the images used by running containers on your infrastructure.

                              The basic set up for image scanning is simple: provide registry information where your images are stored, trigger a scan, and review the results.

                              Behind the scenes:

                              • Image contents are analyzed.

                              • The contents report is evaluated against multiple vulnerability databases.

                              • It is then compared against default or user-defined policies.

                              • Results are reported, both in Sysdig Secure and (if applicable) in a developer’s external CI tool.

                              Prerequisites

                              • Network and port requirements

                                Image Scanning requires access to an external vulnerability feed. To ensure proper access to the latest definitions, refer to the Network and Port requirements.

                              • Whitelisted IP for image scanning requests

                                Image scanning requests and Splunk event forwards both originate from 18.209.200.129. To enable Sysdig to scan private repositories, your firewall will need to allow inbound requests from this IP address.

                              Image Contents Reported

                              The analysis generates a detailed report of the image contents, including:

                              • Official OS packages

                              • Unofficial OS packages

                              • Configuration files

                              • Credentials files

                              • Localization modules and software-specific installers:

                                • Javascript with NPM

                                • Python PiP

                                • Ruby with GEM

                                • Java/JVM with .jar archives

                              • Image metadata and configuration attributes

                              Vulnerability Databases Used

                              Sysdig Secure continuously checks against a wide range of vulnerability databases, updating the Runtime scan results with any newly detected CVEs.

                              The current database list includes:

                              Centos Debian Ruby Red Hat Ubuntu Python

                              CVE NIST NPM Alpine NVD VulnDB

                              See also: Updating Vulnerability Feed in Airgapped Environments.

                              Use Cases

                              As an organization, you define what is an acceptable, secure, reliable image running in your environment. Image scanning for the development pipeline follows a somewhat different flow than for security personnel.

                              Scanning During Container Development (DevOps)

                              Use image scanning as part of your development pipeline, to check for best practices, vulnerabilities, and sensitive content.

                              To begin:

                              • Add Registry: Add a registry where your images are stored, along with the credentials necessary to access them.

                              • Integrate CI Tool: Integrate image scanning with an external CI tool, using the Jenkins plugin or building your own integration from a SysdigLabs solution.

                              • Scan Image(s): The plugin or CLI integration triggers the image scanning process. Failed builds will be stopped, if so configured.

                              • Review Results (in CI tool): Developers can analyze the results in the integrated CI tool (Jenkins).

                                (Optionally: add policies or refine the default policies to suit your needs, assign policies to particular images or tags, and configure alerts and notifications.)

                              Scanning Running Containers (Security Personnel)

                              Security personnel uses image scanning to monitor which containers are running, what their scan status is, and whether new vulnerabilities are present in their images.

                              • Add Registry: Add a registry where your images are stored, along with the credentials necessary to access them.

                              • Scan Image(s): Trigger an image scan with the node image analyzer or manually (one-by-one).

                              • Review Results (in Sysdig Secure): Security personnel can analyze scan results in the Sysdig Secure image scanning UI.

                                (Optionally: add policies or refine the default policies to suit your needs, assign policies to particular images or tags, and configure alerts and notifications.)

                              Image Scanning requires access to an external vulnerability feed. To ensure proper access to the latest definitions, refer to the Network and Port requirements.

                              Add Scanning to Container Registries

                              In some cases, it is possible to integrate image scanning directly into a container registry and automatically trigger an event or action every time a new container is pushed into the registry. This feature is currently supported for the following container registry:

                              1 -

                              Integrate with CI/CD Tools

                              You have the option to use image scanning as part of your development pipeline, to check for best practices, vulnerabilities, and sensitive content.

                              Review the Types of Secure Integrations table for more context. The CI/CD Tools column lists the various options and their levels of support.

                              Inline Scanning

                              Sysdig provides a stand-alone inline scanner– a containerized application that can perform local analysis on container images (both pulling from registries or locally built) and post the result of the analysis to Sysdig Secure.

                              Other scanning integrations (i.e. the Jenkins CI/CD plugin) make use of this component under the hood to provide local image analysis capabilities, but it can also be used as a stand-alone component for custom pipelines, or simply as a way to one-shot scan a container from any host.

                              The Sysdig inline scanner works as an independent container, without any Docker dependency (it can be run using other container runtimes), and can analyze images using different image formats and sources.

                              This feature has a variety of use cases and benefits:

                              • Images don’t leave their own environment 

                              • SaaS users don’t send images and proprietary code to Sysdig’s SaaS service

                              • Registries don’t have to be exposed

                              • Images can be scanned in parallel more easily

                              • Images can be scanned before they hit the registry, which can

                                • cut down on registry costs

                                • simplify the build pipeline

                              Prerequisites

                              At a minimum, the inline scanner requires:

                              • Sysdig Secure v2.5.0+ (with API token)

                              • Internet access to post results to Sysdig Secure (SaaS or On-Prem)

                              • Ability to run a container

                              Using the inline_script.sh is deprecated. This script uses a different set of parameters; for more information about porting the parameters to the inline scanner container, see changes-from-v1xx.

                              Implement Inline Scanning

                              Quick Start

                              You can scan an image from any host by executing:

                              docker run --rm quay.io/sysdig/secure-inline-scan:2 <image_name> --sysdig-token <my_API_token> --sysdig-url <secure_backend_endpoint>
                              …
                              …
                              Status is pass
                              View the full result @ https://secure.sysdig.com/#/scanning/scan-results/docker.io%2Falpine%3A3.12.1/sha256:c0e9560cda118f9ec63ddefb4a173a2b2a0347082d7dff7dc14272e7841a5b5a/summaries
                              PDF report of the scan results can be generated with -r option.
                              
                              Common Parameters

                              Parameter

                              Description

                              Image name (mandatory)

                              Container image to be analyzed, following the usual registry/repo:tag format, i.e. docker.io/alpine:3.12.1. If no tag is specified, the latest will be used.

                              Digest format is also supported, i.e.: docker.io/alpine@sha256:c0e9560cda118f9ec6...

                              --sysdig-token (mandatory)

                              Sysdig API token, visible from the User Profile page.

                              --sysdig-url:

                              Not required for Sysdig Secure SaaS in the us-east region. For any other case, you must adjust this parameter. I.e. for SaaS us-west it is: --sysdig-url https://us2.app.sysdig.com. See also SaaS Regions and IP Ranges.

                              Quick Help and Parameter List from -h

                              Display a quick help and parameters description from the image itself by executing: docker run --rm quay.io/sysdig/secure-inline-scan:2 -h.

                              Sample output:

                              $ docker run quay.io/sysdig/secure-inline-scan:2 -h
                              Sysdig Inline Analyzer -- USAGE
                              
                                Container for performing analysis on local container images, utilizing the Sysdig analyzer subsystem.
                                After image is analyzed, the resulting image archive is sent to a remote Sysdig installation
                                using the -s <URL> option. This allows inline analysis data to be persisted & utilized for reporting.
                              
                                Usage: sysdig-inline-scan.sh -k <API Token> [ OPTIONS ] <FULL_IMAGE_TAG>
                              
                                  == GLOBAL OPTIONS ==
                              
                                  -k <TEXT>   [required] API token for Sysdig Scanning auth
                                              (ex: -k 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx')
                                              Alternatively, set environment variable SYSDIG_API_TOKEN
                                              Alias: --sysdig-token
                                  -s <URL>    [optional] Sysdig Secure URL (ex: -s 'https://secure-sysdig.svc.cluster.local').
                                              If not specified, it will default to Sysdig Secure SaaS URL (https://secure.sysdig.com).
                                              Alias: --sysdig-url
                                  --sysdig-skip-tls
                                              [optional] skip tls verification when calling secure endpoints
                                  -o          [optional] Use this flag if targeting onprem sysdig installation
                                              Alias: --on-prem
                                  -a <TEXT>   [optional] Add annotations (ex: -a 'key=value,key=value')
                                              Alias: --annotations
                                  -f <PATH>   [optional] Path to Dockerfile (ex: -f ./Dockerfile)
                                              Alias: --dockerfile
                                  -m <PATH>   [optional] Path to Docker image manifest (ex: -m ./manifest.json)
                                              Alias: --manifest
                                  -i <TEXT>   [optional] Specify image ID used within Sysdig (ex: -i '<64 hex characters>')
                                              Alias: --image-id
                                  -d <SHA256> [optional] Specify image digest (ex: -d 'sha256:<64 hex characters>')
                                              Alias: --digest
                                  -c          [optional] Remove the image from Sysdig Secure if the scan fails
                                  -r <PATH>   [optional] Download scan result pdf in a specified container-local directory (ex: -r /staging/reports)
                                              This directory needs to be previously mounted from the host to persist the data
                                              Alias: --report-folder
                                  -v          [optional] Increase verbosity
                                              Alias: --verbose
                                  --format <FORMAT>
                                              [optional] The only valid format is JSON. It sets the output format to a valid JSON which
                                              can be processed in an automated way.
                                  --write-json <PATH>
                                              Write the final JSON report to <PATH>.
                                  --time-profile
                                              Output information about the time elapsed in the different stages of the scan process
                                  --malware-scan-enable
                                              Enables malware scan on container.
                                              WARNING: it's generally a very slow process.
                                  --malware-scan-db-path <PATH>
                                              Local container path with updated ClamAV database.
                                              Will be used to call clamscan command as "clamscan --database=<PATH> ..."
                                  --malware-scan-output <DIR-PATH>
                                              Save JSON output of scan to path. Will be saved to <PATH>/malware_findings.json.
                                              Output is a JSON array of {"path": "...", "signature": "..."} objects.
                                              Note: path should exists and should be a directory.
                                  --malware-fail-fast true|false
                                              Fails immediately when a malware is found, skipping sending analysis
                                              results to Secure Backend.
                                              Default: true
                                  --malware-exclude REGEX
                                              Exclude dirs (and its content) and files which match the given regex.
                                              Arguments are passed to ClamAV --exclude AND --exclude-dir options, please
                                              refer to its official documentation.
                                              (https://www.clamav.net/documents/clam-antivirus-user-manual)
                              
                                  == IMAGE SOURCE OPTIONS ==
                              
                                  [default] If --storage-type is not specified, pull container image from registry.
                              
                                      == REGISTRY AUTHENTICATION ==
                              
                                      When pulling from the registry,
                                      the credentials in the config file located at /config/auth.json will be
                                      used (so you can mount a docker config.json file, for example).
                                      Legacy .dockercfg file is also supported.
                                      Alternatively, you can provide authentication credentials with:
                                      --registry-auth-basic     username:password  Authenticate using the provided <username> and <password>
                                      --registry-auth-token     <TOKEN>            Authenticate using this Bearer <Token>
                                      --registry-auth-file      <PATH>             Path to config.json or auth.json file with registry credentials
                                      --registry-auth-dockercfg <PATH>             Path to legacy .dockercfg file with registry credentials
                              
                                      == TLS OPTIONS ==
                              
                                      -n                    Skip TLS certificate validation when pulling image
                                                            Alias: --registry-skip-tls
                              
                                  --storage-type <SOURCE-TYPE>
                              
                                      Where <SOURCE-TYPE> can be one of:
                              
                                      docker-daemon   Get the image from the Docker daemon.
                                                      Requires /var/run/docker.sock to be mounted in the container
                                      cri-o           Get the image from containers-storage (CRI-O and others).
                                                      Requires mounting /etc/containers/storage.conf and /var/lib/containers
                                      docker-archive  Image is provided as a Docker .tar file (from docker save).
                                                      Tarfile must be mounted inside the container and path set with --storage-path
                                      oci-archive     Image is provided as a OCI image tar file.
                                                      Tarfile must be mounted inside the container and path set with --storage-path
                                      oci-dir         Image is provided as a OCI image, untared.
                                                      The directory must be mounted inside the container and path set with --storage-path
                              
                                  --storage-path <PATH>   Specifies the path to the source of the image to scan, that has to be
                                                          mounted inside the container, it is required if --storage-type is set to
                                                          docker-archive, oci-archive or oci-dir
                              
                                  == EXIT CODES ==
                              
                                  0   Scan result "pass"
                                  1   Scan result "fail"
                                  2   Wrong parameters
                                  3   Error during execution
                              

                              Supported Execution Modes and Image Formats

                              The inline scanner can pull the target image from different sources. Each case requires a different set of parameters and/or host mounts, as described in the relevant Execution Examples.

                              Output Options

                              When the inline scanner has completed the image analysis, it sends the metadata to the Sysdig Secure backend to perform the policy evaluation step. The scan results can then be consumed inline or by accessing the Secure UI.

                              Container Exit Code

                              The container exit codes are:

                              • 0 - image passed policy evaluation

                              • 1 - image failed policy evaluation

                              • 2 - incorrect parameters (i.e. no API token)

                              • 3 - other execution errors

                              Use the exit code, for example, to decide whether to abort the CI/CD pipeline.

                              Standard Output

                              The standard output produces a human-readable output including:

                              • Image information (digest, image ID, etc)

                              • Evaluation results, including the final pass / fail decision

                              • A link to visualize the complete scan report using the Sysdig UI

                              If you prefer JSON output, simply pass --format JSON as a parameter.

                              JSON Output

                              You can write a JSON report, while keeping the human-readable output in the console, by adding the following flag: --write-json /out/report.json

                              Remember to bind mount the output directory from the host in the container and provide the corresponding write permissions.

                              PDF Report

                              You can also download the scan result PDF in a specified container-local directory. Remember to mount this directory from the host in the container to retain the data.

                              --report-folder /output

                              Execution Examples

                              Docker Daemon

                              Scan a local image build; mounting the host Docker socket is required. You might need to include Docker options ‘-u root’ and ‘--privileged’, depending on the access permissions for /var/run/docker.sock

                              docker build -t <image-name> .
                              
                              docker run --rm \
                                  -v /var/run/docker.sock:/var/run/docker.sock \
                                  quay.io/sysdig/secure-inline-scan:2 \
                                  --sysdig-url <omitted> \
                                  --sysdig-token <omitted> \
                                  --storage-type docker-daemon \
                                  --storage-path /var/run/docker.sock \
                                  <image-name>
                              
                              Docker Archive

                              Trigger the scan, assuming the image is available as an image tarball at image.tar. For example, the command docker save <image-name> -o image.tar creates a tarball for <image-name>. Mount this file inside the container:

                              docker run --rm \
                                  -v ${PWD}/image.tar:/tmp/image.tar \
                                  quay.io/sysdig/secure-inline-scan:2 \
                                  --sysdig-url <omitted> \
                                  --sysdig-token <omitted> \
                                  --storage-type docker-archive \
                                  --storage-path /tmp/image.tar \
                                  <image-name>
                              
                              OCI Archive

                              Trigger the scan assuming the image is available as an OCI tarball at oci-image.tar.  Mount this file inside the container:

                              docker run --rm \
                                  -v ${PWD}/oci-image.tar:/tmp/oci-image.tar \
                                  quay.io/sysdig/secure-inline-scan:2 \
                                  --sysdig-url <omitted> \
                                  --sysdig-token <omitted> \
                                  --storage-type oci-archive \
                                  --storage-path /tmp/oci-image.tar \
                                  <image-name>
                              
                              OCI Layout

                              Trigger the scan assuming the image is available in OCI format in the directory ./oci-image. Mount the OCI directory inside the container:

                              docker run --rm \
                                  -v ${PWD}/oci-image:/tmp/oci-image \
                                  quay.io/sysdig/secure-inline-scan:2 \
                                  --sysdig-url <omitted> \
                                  --sysdig-token <omitted> \
                                  --storage-type oci-dir \
                                  --storage-path /tmp/oci-image \
                                  <image-name>
                              
                              Container Storage: Build w/ Buildah & Scan w/ Podman

                              Build an image using Buildah from a Dockerfile, and perform a scan. You might need to include docker options '-u root' and '--privileged', depending on the access permissions for /var/lib/containers. Mount the container storage folder inside the container:

                              sudo buildah build-using-dockerfile -t myimage
                              
                              sudo podman run \
                              --rm -u root --privileged \
                              -v /var/lib/containers/:/var/lib/containers \
                              quay.io/sysdig/secure-inline-scan:2 \
                              --storage-type cri-o \
                              --sysdig-token <omitted> \
                              localhost/myimage
                              

                              Using a Proxy

                              To use a proxy, set the standard http_proxy and https_proxy variables when running the container.

                              Example:

                              docker run --rm \
                                  -e http_proxy="http://my-proxy:3128" \
                                  -e https_proxy="http://my-proxy:3128" \
                                  quay.io/sysdig/secure-inline-scan:2 \
                                  --sysdig-url <omitted> \
                                  --sysdig-token <omitted> \
                                  alpine
                              

                              Both http_proxy and https_proxy variables are required, as some tools will use a per-scheme proxy.The no_proxy variable can be used to define a list of hosts that don’t use the proxy.

                              Perform Inline Malware Scanning

                              It is now possible to scan the image contents for malware as part of the inline scanning process.

                              Note two important details to consider:

                              • Malware scanning is resource intensive. Enable this mode for the required set of images only, i.e. images coming from an untrustworthy source.

                              • Malware contents in the image are not communicated back to the Sysdig backend. The default behavior if malware is found is to consider the scan failed, report malware details, and abort analysis.

                              Malware Scanning Flags

                              • --malware-scan-enable: Enable malware detection as part of the inline scanner analysis process. Mounting an external malware database (Using ClamAV format) is highly recommended. If no existing malware database is detected, the analyzer will try to download one on the spot, which means the download time will be added to the analysis process and that it will require network connectivity to pull this database from the Internet.

                              • --malware-scan-db-path <PATH>: Local container path with updated ClamAV database. Will be used to call clamscan command as clamscan --database=<PATH>

                              • --malware-fail-fast true|false: Fail fast is true by default, meaning that, on malware found, the image contents will not be sent to the Sysdig backend for further policy evaluation. If you want to send the image contents to the Backend, even on malware detected, set this parameter to false.

                                About this flag, note:

                                • If no malware is detected, the image contents will be sent to the backend and follow the regular evaluation.

                                • If malware is detected, the container will exit with error code 1.

                              • --malware-scan-output <DIR-PATH>: Save JSON output of scan to path. Will be saved to <PATH>/malware_findings.json. Path must exist and must be a directory; remember to mount this path from an external directory if you want to persist the data.

                              • --malware-exclude REGEX: It is possible to exclude image directories to speed up the malware analysis (for example directories that only contain signed software or sizable files).

                              Arguments are passed to ClamAV. For --exclude AND --exclude-dir options, please refer to their official documentation.

                              Note that /absolute/path/to/clamdb/folder (and its contained files) must have read and execute permissions set for the current Docker user.

                              Refer to ClamAV official documentation.for how to download and keep a local database in sync.

                              docker run --rm -v /absolute/path/to/clamdb/folder:/malwaredb quay.io/sysdig/secure-inline-scan:2 --sysdig-token <API_Token> --malware-scan-enable --malware-scan-db-path /malwaredb malwares/malware-example:7
                              
                              Skipping send analysis to Secure backend due to Malware scan failure.
                              This behaviour can be tuned via --malware-fail-fast option.
                              Path                                                                        | Signature
                              /data/29D6161522C7F7F21B35401907C702BDDB05ED47.bin
                              | Win.Trojan.Emotet-6799923-0
                              /data/29D6161522C7F7F21B35401907C702BDDB05ED47.bin
                              | Win.Trojan.Emotet-9769817-0
                              /data/29D6161522C7F7F21B35401907C702BDDB05ED47.bin
                              | Win.Trojan.Emotet-9769818-0
                              /data/29D6161522C7F7F21B35401907C702BDDB05ED47.bin
                              | Win.Trojan.Agent-1280578
                              /data/29D6161522C7F7F21B35401907C702BDDB05ED47.bin!(0)
                              | Win.Trojan.Agent-1280578
                              

                              Example: Download Malware Database Inline

                              docker run --rm quay.io/sysdig/secure-inline-scan:2 --sysdig-token <API_Token> --malware-scan-enable malwares/malware-example:7
                              

                              Malware detection is provided by a third-party software. Sysdig cannot directly remediate false negatives or false positives reported by this functionality.

                              Pipeline Integration Examples

                              There are well-documented examples for a variety of pipelines:

                              Additional Options

                              You can also:

                              1.1 -

                              Integrate with Jenkins

                              Sysdig has a plugin to integrate Sysdig image scanning into a Jenkins-based build process.

                              Review the Types of Secure Integrations table for more context. The CI/CD Tools column lists the various options and their levels of support.

                              Install and Configure the Jenkins Plugin

                              The Sysdig Secure Jenkins Plugin documentation (at jenkins.io) describes:

                              • Prerequisites

                              • Obtaining the plugin

                              • Necessary system configuration steps in the Jenkins UI

                              • Adding Sysdig Secure Image Scanning as build step (in the Jenkins UI)

                              • Configuring the actions to take on scanned builds (e.g. when to fail a build or issue a warning).

                              Obtain Scan Results in Jenkins

                              The Sysdig plugin generates a scan report listed in the Jenkins build list:

                              Click on the Sysdig Scanning Report to view the summary information and a list of policy checks and results.

                              2 -

                              Integrate with Container Registries

                              Some image registries can trigger an automatic event or action every time a new container is pushed into the registry. Sysdig has provided seamless integration with AWS Elastic Container Registries (ECR) for this kind of automatic scanning. See ECR Registry Scanning.

                              Other image scanning pipelines use the container registry as a “passive” element; when you know which image you want to scan, you retrieve the target image from the registry. For this type of integration, you must provide the registry credentials in the Sysdig Secure interface. See Manage Registry Credentials, below.

                              Review the Types of Secure Integrations table for more context. The Container Registries column lists the various options and their levels of support.

                              ECR Registry Scanning

                              ECR Registry Scanning automatically scans all container images pushed to all your Elastic Container Registries, so you have a vulnerability report available in your Sysdig Secure dashboard at all times, without having to set up any additional pipeline.

                              An ephemeral CodeBuild pipeline is created each time a new image is pushed, which executes an inline scan based on your defined scan policies. Default policies cover vulnerabilities and dockerfile best practices, and you can define advanced rules yourself.

                              Usage Steps

                              1. Deploy: Deploy Sysdig Secure for cloud on AWS and choose the ECR Image Registry Scanning option.

                              2. Insights becomes your default landing page in Sysdig Secure.

                              3. Review the Scan Results to confirm that AWS Registry appears and use the feature.

                              Manage Registry Credentials

                              Registry credentials are required for Sysdig Secure to pull and analyze images. Each of the registry types has unique input fields for the credentials required (e.g., username/password for docker.io; JSON key for Google Container Registry).

                              The login requires at least read permissions.

                              Add a New Registry

                              1. From the Image Scanning module, select Registry Credentials and click Add Registry.

                                The New Registry page is displayed.

                              2. Enter the basic identification information:

                                Registry Name:Self-defined

                                Path The path to the registry, e.g. docker.io

                                NOTE: In some cases, you may have a registry with various namespaces, each with different permissions.

                                You can use a partial path name with a wildcard (*) to subsume all those credentials into the single set of credentials you configure on this page.

                                The wildcard indicates that any image located under the partial path inside the registry (/rg-2-1er in the screenshot) will use the registry credentials configured in step 3, below.

                                Type Select from the from the drop-down menu.

                              3. Configure the registry-specific credentials (based on the Type chosen).

                                Docker V2 There are many Docker V2 registries, and the credential requirements may differ.

                                For Azure Container Registry:

                                1. Admin Account

                                  Username: in the 'az acr credentials show --name <registry name>' command result

                                  Password: The password or password2 value from the 'az acr credentials show' command result

                                2. Service Principal

                                  Username: The service principal app id

                                  Password: The service principal password

                                Google Container Registry:

                                JSON Key

                              4. (Primarily for OpenShift clusters): Add an internal registry address.

                                The recommended way to run an image registry for an OpenShift cluster is to run it locally. The Sysdig agent will detect the internal registry names, but for the Anchore engine to pull and scan the image it needs access to the internal registry itself.

                                Example:

                                External name: mytestregistry.example.com

                                Internal name: docker-registry.default.svc:5000

                                Sysdig maps the internal registry name to the external registry name, so the Runtime and Repository lists will show only the external names.

                              5. Optional: Toggle the switch to Allow Self-Signed certificates.

                                By default, the UI will only pull images from a TLS/SSL-enabled registry.

                                Toggle Allow Self-Signed to instruct the UI not to validate the certificate (if the registry is protected with a self-signed certificate or a cert from an unknown certificate authority).

                              6. Optional: Toggle the Test Credentials switch to validate your entries.

                                When enabled, Sysdig will attempt to pull the image using the entered credentials. If it succeeds, the registry will be saved. If it fails, you will receive an error and can correct the credentials or image details.

                                If enabled, then enter the test registry path in the format :

                                registry/repo:tag
                                

                                E.g. quay.io/sysdig/agent:0.89

                              7. Click Save.

                              Edit a Registry

                              1. From the Image Scanning module, select Registry Credentials.

                              2. Select an existing registry to open the Edit window.

                              3. Update the parameters as necessary and click Save.

                                The registry Type cannot be edited.

                              Delete a Registry

                              1. From the Image Scanning module, select Registry Credentials.

                              2. Select the existing registry to open the Edit window.

                              3. Click Delete Registry and click Yes to confirm the change.

                              Next Steps

                              When at least one registry has been added successfully, it is possible to scan images and review scan results, taking advantage of the Default scanning policy provided.

                              3 -

                              Scan Running Images

                              To automatically trigger scans of running images, install a node-based image analyzer alongside the agent. Alternatively, you can scan individual images manually from the UI.

                              Auto-Scan with the Image Analyzer

                              What is the Image Analyzer?

                              The (node) image analyzer (NIA) provides the capability to scan images as soon as they start running on hosts where the analyzer is installed. It is typically installed alongside the Sysdig agent container.

                              On container start-up, the analyzer scans all pre-existing running images present in the node. Additionally, it will scan any new image that enters a running state in the node. It will scan each image once, then forward the results to the Sysdig Secure scanning backend. Image metadata and the full scan report is then available in the Sysdig Secure UI.

                              The analyzer performs the image analysis directly on the local host. This poses several benefits:

                              • Automation: Every image executed on your environments will be automatically scanned and checked against the vulnerability databases and configured scanning policies, without requiring any manual intervention

                              • Privacy: Using local analysis, only image metadata is sent to the Sysdig backend, as opposed to pulling the entire image to be evaluated with backend scanning, which provides improved privacy

                              • Improved registry security: Since the Sysdig backend will not pull the image from a registry, there is no need to configure registry credentials on the Sysdig-side, nor open up the registry endpoints to be accessed over public networks

                              If the node image analyzer is installed, there is no longer any need to manually trigger running image scans.

                              Installing the Image Analyzer

                              If you have run the single line agent install with the --image-analyzer flag, then this component is already running in your infrastructure.

                              The feature is available for Kubernetes environments in Sysdig Secure SaaS and in On-Premises version 3.5.1+.

                              Otherwise, the Image Analyzer is now deployed as a part of the Node Analyzer: Multi-Feature Installation.

                              Manually Scan an Image

                              If the node image analyzer is not installed, then when a new image is added to a running environment it may need to be scanned manually. This can be done from either the Runtime tab, or the Scan Results tab.

                              From the Runtime Tab

                              To manually scan an image from the Runtime tab:

                              1. From the Scanning module, choose the Runtime tab.

                              2. Sort by Unscanned and select an image from the list of unscanned images.

                              3. Click Scan Now if the option is displayed. You may be prompted to install the Image Analyzer if the digest could not be detected.

                              From the Image Results Tab

                              1. From the Scanning module, choose the Image Results tab.

                              2. Click Scan Image.

                              3. Define the path to the image, and click Scan.

                              4 -

                              Manage Scanning Policies

                              Image scanning policies define several scenarios, such as:

                              • The build process may be stopped.

                              • Administrators may be alerted to potential risks within container images.

                              Each scanning policy is comprised of rules built of gates and triggers. Sysdig includes default policies that can be used to run scans as soon as registry credentials have been configured.

                              Users can create additional rules or policies from the available Scanning Policy Gates and Triggers.

                              Preconfigured Policies

                              Sysdig provides four baseline policies that can be used as-is or as templates on which to build.

                              Default Policy

                              This policy covers the most common image scanning cases, such as:

                              • checking for medium and high vulnerabilities

                              • checking configuration items (e.g., ensuring health checks in an image or disallowing exposed ports)

                              • validating that the vulnerability feed data is up-to-date.

                              This policy is a basic catch-all that cannot be deleted. If no other policy assignments are made, the Default policy is automatically used.

                              You can edit the Default policy and edits will be retained even when you upgrade Sysdig Secure.

                              Preconfigured Compliance Policies

                              The three other preconfigured policies deal with compliance rules. To use them, you may be prompted to activate them.

                              If you want to edit a preconfigured compliance policy, create a new policy with matching rules, and edit that.

                              Otherwise, your customizations may be overwritten and lost during Sysdig Secure upgrades.

                              Configuration Policy - Dockerfile Best Practices

                              This policy provides out-of-the-box rules around Dockerfile best practices, such as disallowing:

                              • secrets baked in as environment variables

                              • root user configuration

                              • exposed ports

                              • run instructions that include .yum upgrades.

                              Audit Policy - NIST 800-190

                              This policy maps NIST 800-190 controls to a Sysdig Secure scanning policy, such as disallowing:

                              • non-official node or Ruby packages

                              • add instructions in a Docker file

                              • the use of base distributions outside of expected values.

                              Audit Policy - PCI

                              This policy maps PCI (Payment Card Industry) controls to a Sysdig Secure scanning policy, such as disallowing vulnerabilities or credentials to be included in the image.

                              Customized Policies

                              Remember not to edit preconfigured compliance scanning policies directly. Create a matching policy and edit that one.

                              Create a Scanning Policy

                              1. From the Image Scanning module, select Scanning Policies and click Add Policy(+).

                                The New Policy page is displayed.

                              2. Define a Name and an optional Description for the new policy.

                              3. Add a Rule:

                                Select the Gate and then the Trigger from the drop-down menus.

                                Configure relevant parameters. (Some triggers do not require parameters to be set.)

                                See Scanning Policy Gates and Triggers for details on each option.

                                The example below uses the vulnerabilities gate with the package  trigger.

                              1. Optional: Repeat step 5 to add rules as necessary.

                              2. Click Save.

                              Edit a Policy

                              1. From the Image Scanning module, select Scanning Policies.

                              2. Select the desired policy from the list.

                              3. Edit the policy rules as required, and click Save Policy.

                              Delete a Policy

                              1. From the Image Scanning module, select Scanning Policies.

                              2. Select the desired policy from the list.

                              3. Click the Delete (trash can) icon and choose Yes to confirm the change.

                              Globally Trust|Untrust

                              You can add images to a globally trusted or untrusted list, or put CVEs on defined Global Exceptions lists, if desired. See Manage Vulnerability Exceptions and Global Lists. This does not affect the policy evaluation order.

                              Manage Policy Assignments

                              Unless you use a very simple, single-policy approach to scanning, you will probably assign particular policies to particular registries, repositories, or tags.

                              Use the Policy Assignments page to do this.

                              For example:

                              • To evaluate all images with a “Prod” tag with your Example Prod Image Policy, use the assignment (registry/repo/tag): */*/Prod

                              • To evaluate all images from gcr.io with an Example Google Policy, use the assignment (registry/repo/tag): gcr.io/*/*

                              Assign a Policy

                              1. From the Image Scanning module, select Scanning Policies and choose +Policy Assignments.

                                The previously defined assignments are listed in priority order.

                              2. Click +Add Policy Assignment.

                                A new entry line appears at the top of the Assignment page. Enter the desired assignment details:

                                1. Priority: Priority is the order of evaluation against the assigned policy. Each new assignment is auto-placed at Priority 1. Once a policy assignment is created and saved, you can change its priority order by dragging it into a new position on the list. See also Using Priorities.

                                2. **Registry:**Any registry domain (e.g. quay.io). Wildcards are supported; an asterisk * specifies any registry.

                                3. **Repository:**Any repository (typically = name of the image). Wildcards are supported; an asterisk * specifies any repository.

                                4. Tag: Any tag. Wildcards are supported; an asterisk * specifies any tag.

                                5. Assigned Policy: Name of policy to use for evaluation. Select from the drop-down menu.

                              3. Click Save.

                              4. Optional: Reorganize the Priority order by clicking the drag handle (the four dots to the left of a line) and dragging the assignment to a different spot on the list.

                              Using Priorities

                              When you use more than one scanning policy, the Anchore engine evaluates them in top-down order, starting from Priority 1 in the Policy Assignment list. The first policy assignment rule that matches an input image will be evaluated, and all subsequent rules ignored. Therefore, the priority order is important.

                              For example, imagine a list with two defined policy assignments:

                              Priority 1 Registry = quay.io Repository = sysdig/*

                              Priority 2 Registry = quay.io Repository = sysdig/myrepo

                              Since the first rule uses a wild card, the evaluation applies to all repos beginning with sysdig/ and will stop before evaluating sysdig/myrepo.

                              Reverse the priority order to get the behavior you want.

                              There is a catch-all entry at the bottom of the Policy Assignment list that cannot be removed. It has the format :

                              registry = * repository = * tag = * assigned policy = default
                              

                              ``(You can change the assigned policy, but other fields cannot be edited.)

                              The purpose of this row is to ensure that any registries that do not fall under another policy evaluation will at least be evaluated against the system-configured Default policy.

                              4.1 -

                              Manage Vulnerability Exceptions and Global Lists

                              Sysdig Secure allows users to put specific CVEs on Global Exception lists. Common reasons to exempt a vulnerability from consideration while scanning an image include, for example:

                              • Knowing that the vuln does not apply to your runtime or cannot be exploited

                              • Knowing that the suggested “fix version” will break a chain of dependencies, and you plan to evaluate how to patch this vulnerability in more detail

                              • Knowing that there is no available fix for the vulnerability yet and you absolutely must deploy this application in production. (You decide to use a temporary alternate security strategy to protect from the vulnerability.)

                              When devising exception lists, you can detail what exceptions you introduce, for which images, and for how long, establishing a vulnerability exception management workflow.

                              Additionally, specific images can be marked as untrusted or globally trusted to ensure they always/never pass a scan.

                              Previous versions of Sysdig Secure called this feature Whitelist and Blacklist, and the options were located under the Scanning Policies tab.

                              Note that “blacklist” options for other entities, such as users, ports, packages, etc., are listed in Scanning Policy Gates and Triggers.

                              Create Multiple Exception Lists

                              By default, a single list is provided. Its name, Default exceptions list, can be retitled or removed if desired.

                              To create additional lists:

                              1. Select Image Scanning > Vulnerability Exceptions and click the Add button on the left side of the screen.

                              2. Enter a Name and Description and click Save.

                                Hover over the info bubble on an existing list to see its name, description, and last-modified date.

                              3. For an exception list to be applied to an image during a scan, you must set up a scanning policy assignment to map the image to the list.

                              If you delete or rename an exception list, the modification will be also applied to the policy assignments that contain that list.

                              Add a Vulnerability to a List

                              There are two ways to add a vulnerability to a list: from the Exceptions List page, or from the Scan Results.

                              From the Exceptions List Page

                              1. SelectImage Scanning > Vulnerability Exceptions and choose the desired list from the left menu. (In this example, the Exception list is named “Python exceptions”.)

                              2. Click the Add button on the right side of the screen.

                              3. Enter the identifying details:

                                • VULN ID: Required

                                • Expiration Date: Required, but can be ‘never’

                                • Note Optional.

                              From the Scan Results

                              The scan results for an image may flag vulnerabilities you don’t consider necessary. From the results list, you can quickly append those entries to exception lists as follows:

                              1. Select Image Scanning > Scan Results.

                              2. Select the Vulnerability type from the left menu and review the resulting list of flagged vulnerabilities.

                                Note: The Exceptions column displays the number of lists already containing this vulnerability.

                              3. Click the hover button to open the “Add Exception” dialog .

                              4. Enter the details and click Save.

                                • List: Sysdig will indicate with a “radar” icon the lists that are being applied to this image according to the policy assignments which are relevant for the evaluation of this particular image

                                  You can also enter additional list names in the field to create a new list.

                                • Expiration Date: Required, but can be ‘never’

                                • Note Optional.

                              Manage Vulnerabilities in a List

                              An exception list can contain any number of vulnerabilities. Each vulnerability listing displays additional properties to help the security team understand the context, feed sources, and the justification and time span for the vulnerability to be on the list.

                              Fields in the List View

                              Select Image Scanning > Vulnerability Exceptions and choose a list from the left menu to review the vulnerability list details.

                              Review the column data:

                              • Enabled: On/off toggle for whether the exception for this vulnerability is active. If the vulnerability exception is disabled, it will not disappear from the list but will not be taken into account when evaluating an image. Rows that have met their expiration date are automatically disabled.

                              • Name: String entered by the user to identify the vulnerability. For example, CVE-2019-9639 or VULNDB-213986.

                              • Description: Vulnerability description, provided by Sysdig once the Vuln ID is provided by the user.

                              • Notes: User-defined exception notes. Could be used to justify the decision or to append any additional links or information.

                              • Expiration date: Day configured by the user for this exception to expire.

                                • Default is never, for a vulnerability that should not expire. If an expiration is set, then day is the minimum time resolution.

                                • All expiration dates are evaluated against 0:00 UTC timezone

                              Access and Edit Additional Details

                              Click on an exception row to see additional details about the vulnerability and to edit its properties.

                              You can:

                              • View the full description

                              • View and modify user notes

                              • View and modify Expiration date

                                Disabled exceptions cannot be re-enabled until a future date is set.

                              • View segmented feed information, for every feed that is reporting this vulnerability:

                                • Severity of the vulnerability as reported per each individual feed (color-coded)

                                • Link to vulnerability details as provided per feed

                              Add Images to a Global List

                              There are two ways to add images to a Global Trusted or Untrusted list: from the list or from a scan result.

                              From the Global list:

                              1. From the Image Scanning module, select either Global - Trusted Images or Global - Untrusted Images.

                                The list of previously added images is displayed.

                              2. Click the Add Image button.

                              3. Add each image in a comma-separated list, then click Ok.

                                A tag name must be valid ASCII and may contain lowercase and uppercase letters, digits, underscores, periods and dashes.

                                A tag name may not start with a period or a dash and may contain a maximum of 128 characters.

                              From the Scan Results:

                              1. From the Image Scanning module, choose the Scan Results tab.

                              2. Select the relevant repository from the list and open the relevant image.

                              3. Click Add to List at the top of the page.

                              4. Select either Add Image to Trusted Images or Add Image to Untrusted Images as needed.

                              4.2 -

                              Scanning Policy Gates and Triggers

                              This document describes the gates (and their respective triggers / parameters) that are supported within Sysdig Secure policy bundles. Use these policy gates, triggers, and parameters to build in-depth scanning policies, from whitelisting / blacklisting partial file names to defining what login shells are approved.

                              This information can also be obtained using the CLI:

                              user@host:~$ anchore-cli policy describe (--gate <gatename> (--trigger <triggername))
                              

                              For more information, see Manage Scanning Policies and Dockerfile Gate and Triggers Deep Dive.

                              Always

                              This gate provides users with a valuable testing resource, as it will be triggered unconditionally.

                              always

                              The always trigger / gate will trip if it is present in the policy.

                              The Always gate is useful for testing whether the image blacklist/whitelist is working as expected.

                              Dockerfile

                              The dockerfile gate reviews the contents of a Dockerfile, or the assumed contents of a dockerfile if one is not provided, for exposed ports and instructions that do not follow best practices.

                              The gate can assume what the contents would be based on the Docker layer history. See also: Dockerfile Gate and Triggers Deep Dive

                              effective_user

                              This trigger reviews whether the effective user matches the user provided, and will fire based on the configured type.

                              ParameterDescriptionExample
                              typeDetermines whether the user should be whitelisted or blacklisted.N/A
                              userThe name of the user.root,docker

                              exposed_ports

                              This trigger evaluates the set of exposed ports to determine whether they should be whitelisted or blacklisted.

                              ParameterDescriptionExample
                              actual_dockerfile_onlyDefines whether the evaluation should skip inferred or guessed Dockerfiles, and only evaluate user-provided Dockerfiles. The default value is false.true
                              portsA comma-separated list of port numbers.80,8080,8088
                              typeDefines whether the ports should be whitelisted or blacklisted.N/A

                              instruction

                              This trigger evaluates whether any directives/instructions in the list match the conditions in the Dockerfile.

                              ParameterDescriptionExample
                              actual_dockerfile_onlyDefines whether the evaluation should skip inferred or guessed dockerfiles, and only evaluate user-provided dockerfiles. The default value is false.true
                              checkThe type of check to perform.=
                              instructionThe dockerfile instruction to check.FROM
                              valueThe value to check the dockerfile instruction against.scratch

                              no_dockerfile_provided

                              This trigger will trip if there is no Dockerfile supplied with the image. No parameters are required for this trigger.

                              Files

                              The Files gate reviews files within the analyzed image. This evaluation covers file content, names, and filesystem attributes.

                              content_regex_match

                              This trigger is tripped for each file where a match has been found using the configured regex in the analyzer_config.yaml content_search section.

                              For more information regarding the regex values, refer to the analyzer_config.yaml file.

                              ParameterDescriptionExample
                              regex_nameThe regex string that appears in the FILECHECK_CONTENTMATCH analyzer parameter..*password.*

                              name_match

                              This trigger is tripped if the name of a file in the container matches the provided regex.

                              This trigger has a performance impact on policy evaluation.

                              ParameterDescriptionExample
                              regexThe regex to search for..*\.pem

                              suid_or_guid_set

                              This trigger is tripped for each file that has a set-user identification (SUID) or set-group identification (SGID) configured. No parameters are required.

                              Licenses

                              This gate is used to review software licenses found in the container image, to ensure, for example, that packages that violate internal company policy are not being used.

                              blacklist_exact_match

                              This trigger will be tripped if the image contains packages distributed under the exact license specified.

                              ParameterDescriptionExample
                              licensesA comma-separated list of license names to blacklist.GPLv2+,GPL-3+,BSD-2-clause

                              blacklist_partial_match

                              This trigger will be tripped if the image contains packages distributed under a license that includes the partial strings provided.

                              ParameterDescriptionExample
                              licensesA comma-separated list of strings to blacklist for licenses.LGPL,BSD

                              Metadata

                              This gate reviews image metadata, including the size, operating system, and architecture.

                              attribute

                              The attribute trigger is tripped if a named image metadata value matches the given condition.

                              ParameterDescriptionExample
                              attributeThe attribute name to check.size
                              checkThe operation to perform for the evaluation.>
                              valueThe value used for the evaluation.1073741824

                              Packages

                              The Packages gate reviews all packages within the image, verifying names, versions, and whitelisted / blacklisted packages.

                              blacklist

                              This trigger is tripped if the image contains packages that have been blacklisted by either name, or name and version.

                              ParameterDescriptionExample
                              nameThe name of blacklisted package/s.openssh-server
                              versionThe exact version of the package that should be blacklisted.1.0.1

                              required_package

                              The required_package trigger is tripped if the specified package / version is not found in the image.

                              ParameterDescriptionExample
                              nameThe name of the required package.libssl
                              versionThe required package version.1.10.3rc3
                              version_match_typeDefines whether the trigger should require the exact package and version (exact), or just a version of the package (minimum). This is only relevant if the version is defined.exact

                              verify

                              This trigger reviews the package integrity against the package database in the image, and is tripped for change or removal of content in either all or a defined list of directories provided.

                              ParameterDescriptionExample
                              checkDefines whether the check should focus on missing packages, changed packages, or all.changed
                              only_directoriesDefines the list of directories the check should be limited to./usr,/var/lib
                              only_packagesDefines the list of packages that should be verified.libssl,openssl

                              Passwd File

                              This gate reviews /etc/passwd for blacklisted users, groups, and shells.

                              blacklist_full_entry

                              This trigger trips if the whole password is found in the /etc/password file.

                              ParameterDescriptionExample
                              entryThe full entry to match in /etc/passwd.ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin

                              blacklist_groupids

                              This trigger is tripped if the designated group id/s are found in the /etc/passwd file.

                              ParameterDescriptionExample
                              group_idsA numeric, comma separated list of group ids that will cause the trigger to trip.999,20

                              blacklist_shells

                              This trigger will trip if a designated login shell is found under any user in the /etc/passwd file.

                              ParameterDescriptionExample
                              shellsThe list of shell commands to blacklist./bin/bash,/bin/zsh

                              blacklist_userids

                              This trigger will be tripped if the specified user ID is present in /etc/passwd.

                              ParameterDescriptionExample
                              user_idsThe numerical, comma-separated list of user IDs to blacklist.0,1

                              blacklist_usernames

                              The blacklist_usernames trigger will trip if the specified username is found in the /etc/passwd file.

                              ParameterDescriptionExample
                              user_namesA comma-separated list of usernames to blacklist.daemon,ftp

                              content_not_available

                              The content_not_available trigger will trip if the /etc/passwd file is not present in the image. No parameters are required.

                              Secret Scans

                              Secret scans determine, based on configured regex, whether secrets that could be available if an image was compromised have been baked into the image.

                              content_regex_checks

                              The content_regex_checks trigger trips if the content search analyzer finds a match with the configured and named regexes. Matches are filtered by the content_regex_name, and the filename_regex, if either are set.

                              The content_regex_name should be a value from the secret_search section of analyzer_config.yaml.

                              Parameter

                              Description

                              Example

                              content_regex_name

                              The name of the variable / content. If found in the image, this should trip the trigger.

                              The names available by default are AWS_ACCESS_KEY, AWS_SECRET_KEY, PRIV_KEY, DOCKER_AUTH, and API_KEY.

                              AWS_ACCESS_KEY

                              filename_regex

                              Filters the files that should be analyzed for the presence of the content_regex_name.

                              /etc/.*

                              Vulnerabilities

                              CVE / vulnerability checks can be used to ensure the included packages don’t have vulnerabilities above a set level, are older than a designated period, or if data is unavailable.

                              package

                              The package trigger is tripped if a vulnerability in an image matches the configured comparison criteria. The table below outlines the available parameters and criteria:

                              ParameterDescriptionExample
                              fix_availableIf present, the fix availability for the vulnerability record must match the value of the parameter.true
                              package_typeThe specific type of package.all
                              severityThe vulnerability severity.high
                              severity_comparisonThe type of comparison to perform for the security evaluation.>
                              vendor_onlyIf true, an available fix for this CVE must not be explicitly marked as “Won’t be addressed by the vendor”.true

                              stale_feed_data

                              The stale_feed_data trigger will be tripped if the CVE data is older than the window specified.

                              ParameterDescriptionExample
                              max_days_since_syncDetermines how old in days sync data can be before the trigger is tripped.10

                              vulnerability_data_unavailable

                              If no vulnerability data is available, the vulnerability_data_unavailable trigger will trip. No parameters are required for this trigger.

                              4.3 -

                              Dockerfile Gate and Triggers Deep Dive

                              This article reviews the dockerfile gate and its triggers. Review the documentation from Docker if you want more background on Dockerfiles themselves.

                              Conventions note: In this article, “Dockerfile” refers to the actual file, while “dockerfile” refers to the Sysdig Secure gate used in Policies.

                              The dockerfile gate in Sysdig Secure allows users to perform checks on the content of the Dockerfile, or the Docker history for an image, and make policy actions based on the construction of an image, not just its content. This is particularly useful for enforcing best practices or metadata inclusion (e.g. labels) on images.

                              Sysdig is either given a Dockerfile or infers one from the docker image layer history. There are implications to what data is available and what it means depending on these differing sources, so first, we’ll cover the input data for the gate and how it impacts the triggers and parameters used.

                              The “Dockerfile”

                              The data that this gate operates on can come from two different sources:

                              1. The actual Dockerfile used to build an image, as provided by the user at the time of running sdc-cli image add <img ref> --dockerfile <filename>; or the corresponding API call to: POST /images?dockerfile=

                              2. The history from layers as encoded in the image itself (see docker history<img>for this output)

                              All images have data from history available, but data from the actual Dockerfile is only available when a user provides it. This also means that any images analyzed by automated alerts or the image analyzer will not have an actual Dockerfile.

                              Differences between Dockerfile and Docker History

                              Actual Dockerfile

                              • FROM line is preserved, so the parent tag of the image is easily available

                              • Instruction checks are all against instructions created during the build for that exact image, not any parent images

                                Note: When the actual_dockerfile_only parameter is set to true, all instructions from the parent image are ignored in policy processing. This may have some unexpected consequences depending on how your images are structured and layered (e.g. golden base images that establish common patterns of volumes, labels, healthchecks).

                              • COPY/ADD instructions will maintain the actual values used

                              • Multistage-builds in that specific dockerfile will be visible with multiple FROM lines in the output

                              Docker history data (with no Dockerfile provided)

                              This is a best-effort option and can catch some things, but not all.

                              • FROM line is not accurate, and will nearly always default to FROM scratch

                              • Instructions are processed from all layers in the image

                              • COPY and ADD instructions are transformed into SHAs rather than the actual file path/name used at build-time

                              • Multi-stage builds are not tracked with multiple FROM lines, only the copy operations between the phases

                              Using the actual_dockerfile_only Parameter to Avoid Checking History

                              The actual file vs history impacts the semantics of the Dockerfile gate’s triggers. To allow explicit control of the differences, most triggers in this gate includes a parameter: actual_dockerfile_only that if set to true or false will ensure the trigger check is only done on the source of data specified.

                              If actual_dockerfile_only = true, then the trigger will evaluate only if an actual Dockerfile is available for the image and will skip evaluation if not.

                              If actual_dockerfile_only is false or omitted, then the trigger will run on the actual Dockerfile if available, or the history data if the Dockerfile was not provided.

                              Understanding the FROM Line

                              In the actual Dockerfile, the FROM instruction is preserved and available as used to build the image. However, in the history data, the FROM line will always be the very first FROM instruction used (to build the image and all of its dependent images). In this case, the value in the history will be omitted and the scanning engine will automatically infer a FROM-scratch line, which is logically inserted for this gate if the history does not contain an explicit FROM entry.

                              The files below show how this would play out. See also: Using the Parameter to Avoid Checking History, to work around this outcome.

                              For example, using the docker.io/jenkins/jenkins image:

                              IMAGE                                                                     CREATED             CREATED BY                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       SIZE                COMMENT
                              sha256:3b9c9666a66e53473c05a3c69eb2cb888a8268f76935eecc7530653cddc28981   11 hours ago        /bin/sh -c #(nop) COPY file:3a15c25533fd87983edc33758f62af7b543ccc3ce9dd570e473eb0702f5f298e in /usr/local/bin/install-plugins.sh                                                                                                                                                                                                                                                                                                                                                                                                                                8.79kB
                              <missing>                                                                 11 hours ago        /bin/sh -c #(nop) COPY file:f97999fac8a63cf8b635a54ea84a2bc95ae3da4d81ab55267c92b28b502d8812 in /usr/local/bin/plugins.sh                                                                                                                                                                                                                                                                                                                                                                                                                                        3.96kB
                              <missing>                                                                 11 hours ago        /bin/sh -c #(nop)  ENTRYPOINT ["/sbin/tini" "--" "/usr/local/bin/jenkins.sh"]                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    0B
                              <missing>                                                                 11 hours ago        /bin/sh -c #(nop) COPY file:dc942ca949bb159f81bbc954773b3491e433d2d3e3ef90bac80ecf48a313c9c9 in /bin/tini                                                                                                                                                                                                                                                                                                                                                                                                                                                        529B
                              <missing>                                                                 11 hours ago        /bin/sh -c #(nop) COPY file:a8f986413b77bf4d88562b9d3a0dce98ab6e75403192aa4d4153fb41f450843d in /usr/local/bin/jenkins.sh                                                                                                                                                                                                                                                                                                                                                                                                                                        1.45kB
                              <missing>                                                                 11 hours ago        /bin/sh -c #(nop) COPY file:55594d9d2aed007553a6743a43039b1a48b30527f8fb991ad93e1fd5b1298f60 in /usr/local/bin/jenkins-support                                                                                                                                                                                                                                                                                                                                                                                                                                   6.12kB
                              <missing>                                                                 11 hours ago        /bin/sh -c #(nop)  USER jenkins                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  0B
                              <missing>                                                                 11 hours ago        /bin/sh -c #(nop)  ENV COPY_REFERENCE_FILE_LOG=/var/jenkins_home/copy_reference_file.log                                                                                                                                                                                                                                                                                                                                                                                                                                                                         0B
                              <missing>                                                                 11 hours ago        /bin/sh -c #(nop)  EXPOSE 50000                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  0B
                              <missing>                                                                 11 hours ago        /bin/sh -c #(nop)  EXPOSE 8080                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   0B
                              <missing>                                                                 11 hours ago        |9 JENKINS_SHA=e026221efcec9528498019b6c1581cca70fe9c3f6b10303777d85c6699bca0e4 JENKINS_URL=https://repo.jenkins-ci.org/public/org/jenkins-ci/main/jenkins-war/2.161/jenkins-war-2.161.war TINI_VERSION=v0.16.1 agent_port=50000 gid=1000 group=jenkins http_port=8080 uid=1000 user=jenkins /bin/sh -c chown -R ${user} "$JENKINS_HOME" /usr/share/jenkins/ref                                                                                                                                                                                                  328B
                              <missing>                                                                 11 hours ago        /bin/sh -c #(nop)  ENV JENKINS_INCREMENTALS_REPO_MIRROR=https://repo.jenkins-ci.org/incrementals                                                                                                                                                                                                                                                                                                                                                                                                                                                                 0B
                              <missing>                                                                 11 hours ago        /bin/sh -c #(nop)  ENV JENKINS_UC_EXPERIMENTAL=https://updates.jenkins.io/experimental                                                                                                                                                                                                                                                                                                                                                                                                                                                                           0B
                              <missing>                                                                 11 hours ago        /bin/sh -c #(nop)  ENV JENKINS_UC=https://updates.jenkins.io                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     0B
                              <missing>                                                                 11 hours ago        |9 JENKINS_SHA=e026221efcec9528498019b6c1581cca70fe9c3f6b10303777d85c6699bca0e4 JENKINS_URL=https://repo.jenkins-ci.org/public/org/jenkins-ci/main/jenkins-war/2.161/jenkins-war-2.161.war TINI_VERSION=v0.16.1 agent_port=50000 gid=1000 group=jenkins http_port=8080 uid=1000 user=jenkins /bin/sh -c curl -fsSL ${JENKINS_URL} -o /usr/share/jenkins/jenkins.war   && echo "${JENKINS_SHA}  /usr/share/jenkins/jenkins.war" | sha256sum -c -                                                                                                                  76MB
                              <missing>                                                                 11 hours ago        /bin/sh -c #(nop)  ARG JENKINS_URL=https://repo.jenkins-ci.org/public/org/jenkins-ci/main/jenkins-war/2.161/jenkins-war-2.161.war                                                                                                                                                                                                                                                                                                                                                                                                                                0B
                              <missing>                                                                 11 hours ago        /bin/sh -c #(nop)  ARG JENKINS_SHA=5bb075b81a3929ceada4e960049e37df5f15a1e3cfc9dc24d749858e70b48919                                                                                                                                                                                                                                                                                                                                                                                                                                                              0B
                              <missing>                                                                 11 hours ago        /bin/sh -c #(nop)  ENV JENKINS_VERSION=2.161                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     0B
                              <missing>                                                                 11 hours ago        /bin/sh -c #(nop)  ARG JENKINS_VERSION                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           0B
                              <missing>                                                                 11 hours ago        /bin/sh -c #(nop) COPY file:c84b91c835048a52bb864c1f4662607c56befe3c4b1520b0ea94633103a4554f in /usr/share/jenkins/ref/init.groovy.d/tcp-slave-agent-port.groovy                                                                                                                                                                                                                                                                                                                                                                                                 328B
                              <missing>                                                                 11 hours ago        |7 TINI_VERSION=v0.16.1 agent_port=50000 gid=1000 group=jenkins http_port=8080 uid=1000 user=jenkins /bin/sh -c curl -fsSL https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini-static-$(dpkg --print-architecture) -o /sbin/tini   && curl -fsSL https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini-static-$(dpkg --print-architecture).asc -o /sbin/tini.asc   && gpg --no-tty --import ${JENKINS_HOME}/tini_pub.gpg   && gpg --verify /sbin/tini.asc   && rm -rf /sbin/tini.asc /root/.gnupg   && chmod +x /sbin/tini   866kB
                              <missing>                                                                 11 hours ago        /bin/sh -c #(nop) COPY file:653491cb486e752a4c2b4b407a46ec75646a54eabb597634b25c7c2b82a31424 in /var/jenkins_home/tini_pub.gpg                                                                                                                                                                                                                                                                                                                                                                                                                                   7.15kB
                              <missing>                                                                 11 hours ago        /bin/sh -c #(nop)  ARG TINI_VERSION=v0.16.1                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      0B
                              <missing>                                                                 11 hours ago        |6 agent_port=50000 gid=1000 group=jenkins http_port=8080 uid=1000 user=jenkins /bin/sh -c mkdir -p /usr/share/jenkins/ref/init.groovy.d                                                                                                                                                                                                                                                                                                                                                                                                                         0B
                              <missing>                                                                 11 hours ago        /bin/sh -c #(nop)  VOLUME [/var/jenkins_home]                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    0B
                              <missing>                                                                 11 hours ago        |6 agent_port=50000 gid=1000 group=jenkins http_port=8080 uid=1000 user=jenkins /bin/sh -c mkdir -p $JENKINS_HOME   && chown ${uid}:${gid} $JENKINS_HOME   && groupadd -g ${gid} ${group}   && useradd -d "$JENKINS_HOME" -u ${uid} -g ${gid} -m -s /bin/bash ${user}                                                                                                                                                                                                                                                                                            328kB
                              <missing>                                                                 11 hours ago        /bin/sh -c #(nop)  ENV JENKINS_SLAVE_AGENT_PORT=50000                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            0B
                              <missing>                                                                 11 hours ago        /bin/sh -c #(nop)  ENV JENKINS_HOME=/var/jenkins_home                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            0B
                              <missing>                                                                 11 hours ago        /bin/sh -c #(nop)  ARG JENKINS_HOME=/var/jenkins_home                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            0B
                              <missing>                                                                 11 hours ago        /bin/sh -c #(nop)  ARG agent_port=50000                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          0B
                              <missing>                                                                 11 hours ago        /bin/sh -c #(nop)  ARG http_port=8080                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            0B
                              <missing>                                                                 11 hours ago        /bin/sh -c #(nop)  ARG gid=1000                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  0B
                              <missing>                                                                 11 hours ago        /bin/sh -c #(nop)  ARG uid=1000                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  0B
                              <missing>                                                                 11 hours ago        /bin/sh -c #(nop)  ARG group=jenkins                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             0B
                              <missing>                                                                 11 hours ago        /bin/sh -c #(nop)  ARG user=jenkins                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              0B
                              <missing>                                                                 11 hours ago        /bin/sh -c apt-get update && apt-get install -y git curl && rm -rf /var/lib/apt/lists/*                                                                                                                                                                                                                                                                                                                                                                                                                                                                          0B
                              <missing>                                                                 3 weeks ago         /bin/sh -c set -ex;   if [ ! -d /usr/share/man/man1 ]; then   mkdir -p /usr/share/man/man1;  fi;   apt-get update;  apt-get install -y --no-install-recommends   openjdk-8-jdk="$JAVA_DEBIAN_VERSION"  ;  rm -rf /var/lib/apt/lists/*;   [ "$(readlink -f "$JAVA_HOME")" = "$(docker-java-home)" ];   update-alternatives --get-selections | awk -v home="$(readlink -f "$JAVA_HOME")" 'index($3, home) == 1 { $2 = "manual"; print | "update-alternatives --set-selections" }';  update-alternatives --query java | grep -q 'Status: manual'                    348MB
                              <missing>                                                                 3 weeks ago         /bin/sh -c #(nop)  ENV JAVA_DEBIAN_VERSION=8u181-b13-2~deb9u1                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    0B
                              <missing>                                                                 3 weeks ago         /bin/sh -c #(nop)  ENV JAVA_VERSION=8u181                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        0B
                              <missing>                                                                 3 weeks ago         /bin/sh -c #(nop)  ENV JAVA_HOME=/docker-java-home                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               0B
                              <missing>                                                                 3 weeks ago         /bin/sh -c ln -svT "/usr/lib/jvm/java-8-openjdk-$(dpkg --print-architecture)" /docker-java-home                                                                                                                                                                                                                                                                                                                                                                                                                                                                  33B
                              <missing>                                                                 3 weeks ago         /bin/sh -c {   echo '#!/bin/sh';   echo 'set -e';   echo;   echo 'dirname "$(dirname "$(readlink -f "$(which javac || which java)")")"';  } > /usr/local/bin/docker-java-home  && chmod +x /usr/local/bin/docker-java-home                                                                                                                                                                                                                                                                                                                                       87B
                              <missing>                                                                 3 weeks ago         /bin/sh -c #(nop)  ENV LANG=C.UTF-8                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              0B
                              <missing>                                                                 3 weeks ago         /bin/sh -c apt-get update && apt-get install -y --no-install-recommends   bzip2   unzip   xz-utils  && rm -rf /var/lib/apt/lists/*                                                                                                                                                                                                                                                                                                                                                                                                                               2.21MB
                              <missing>                                                                 3 weeks ago         /bin/sh -c apt-get update && apt-get install -y --no-install-recommends   bzr   git   mercurial   openssh-client   subversion     procps  && rm -rf /var/lib/apt/lists/*                                                                                                                                                                                                                                                                                                                                                                                         142MB
                              <missing>                                                                 3 weeks ago         /bin/sh -c set -ex;  if ! command -v gpg > /dev/null; then   apt-get update;   apt-get install -y --no-install-recommends    gnupg    dirmngr   ;   rm -rf /var/lib/apt/lists/*;  fi                                                                                                                                                                                                                                                                                                                                                                             7.81MB
                              <missing>                                                                 3 weeks ago         /bin/sh -c apt-get update && apt-get install -y --no-install-recommends   ca-certificates   curl   netbase   wget  && rm -rf /var/lib/apt/lists/*                                                                                                                                                                                                                                                                                                                                                                                                                23.2MB
                              <missing>                                                                 3 weeks ago         /bin/sh -c #(nop)  CMD ["bash"]                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  0B
                              <missing>                                                                 3 weeks ago         /bin/sh -c #(nop) ADD file:da71baf0d22cb2ede91c5e3ff959607e47459a9d7bda220a62a3da362b0e59ea in /                                                                                                                                                                                                                                                                                                                                                                                                                                                                 101MB
                              
                              Where the actual dockerfile for that image is:
                              FROM openjdk:8-jdk-stretch
                              
                              RUN apt-get update && apt-get install -y git curl && rm -rf /var/lib/apt/lists/*
                              
                              ARG user=jenkins
                              ARG group=jenkins
                              ARG uid=1000
                              ARG gid=1000
                              ARG http_port=8080
                              ARG agent_port=50000
                              ARG JENKINS_HOME=/var/jenkins_home
                              
                              ENV JENKINS_HOME $JENKINS_HOME
                              ENV JENKINS_SLAVE_AGENT_PORT ${agent_port}
                              
                              # Jenkins is run with user `jenkins`, uid = 1000
                              # If you bind mount a volume from the host or a data container,
                              # ensure you use the same uid
                              RUN mkdir -p $JENKINS_HOME \
                                && chown ${uid}:${gid} $JENKINS_HOME \
                                && groupadd -g ${gid} ${group} \
                                && useradd -d "$JENKINS_HOME" -u ${uid} -g ${gid} -m -s /bin/bash ${user}
                              
                              # Jenkins home directory is a volume, so configuration and build history
                              # can be persisted and survive image upgrades
                              VOLUME $JENKINS_HOME
                              
                              # `/usr/share/jenkins/ref/` contains all reference configuration we want
                              # to set on a fresh new installation. Use it to bundle additional plugins
                              # or config file with your custom jenkins Docker image.
                              RUN mkdir -p /usr/share/jenkins/ref/init.groovy.d
                              
                              # Use tini as subreaper in Docker container to adopt zombie processes
                              ARG TINI_VERSION=v0.16.1
                              COPY tini_pub.gpg ${JENKINS_HOME}/tini_pub.gpg
                              RUN curl -fsSL https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini-static-$(dpkg --print-architecture) -o /sbin/tini \
                                && curl -fsSL https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini-static-$(dpkg --print-architecture).asc -o /sbin/tini.asc \
                                && gpg --no-tty --import ${JENKINS_HOME}/tini_pub.gpg \
                                && gpg --verify /sbin/tini.asc \
                                && rm -rf /sbin/tini.asc /root/.gnupg \
                                && chmod +x /sbin/tini
                              
                              COPY init.groovy /usr/share/jenkins/ref/init.groovy.d/tcp-slave-agent-port.groovy
                              
                              # jenkins version being bundled in this docker image
                              ARG JENKINS_VERSION
                              ENV JENKINS_VERSION ${JENKINS_VERSION:-2.121.1}
                              
                              # jenkins.war checksum, download will be validated using it
                              ARG JENKINS_SHA=5bb075b81a3929ceada4e960049e37df5f15a1e3cfc9dc24d749858e70b48919
                              
                              # Can be used to customize where jenkins.war get downloaded from
                              ARG JENKINS_URL=https://repo.jenkins-ci.org/public/org/jenkins-ci/main/jenkins-war/${JENKINS_VERSION}/jenkins-war-${JENKINS_VERSION}.war
                              
                              # could use ADD but this one does not check Last-Modified header neither does it allow to control checksum
                              # see https://github.com/docker/docker/issues/8331
                              RUN curl -fsSL ${JENKINS_URL} -o /usr/share/jenkins/jenkins.war \
                                && echo "${JENKINS_SHA}  /usr/share/jenkins/jenkins.war" | sha256sum -c -
                              
                              ENV JENKINS_UC https://updates.jenkins.io
                              ENV JENKINS_UC_EXPERIMENTAL=https://updates.jenkins.io/experimental
                              ENV JENKINS_INCREMENTALS_REPO_MIRROR=https://repo.jenkins-ci.org/incrementals
                              RUN chown -R ${user} "$JENKINS_HOME" /usr/share/jenkins/ref
                              
                              # for main web interface:
                              EXPOSE ${http_port}
                              
                              # will be used by attached slave agents:
                              EXPOSE ${agent_port}
                              
                              ENV COPY_REFERENCE_FILE_LOG $JENKINS_HOME/copy_reference_file.log
                              
                              USER ${user}
                              
                              COPY jenkins-support /usr/local/bin/jenkins-support
                              COPY jenkins.sh /usr/local/bin/jenkins.sh
                              COPY tini-shim.sh /bin/tini
                              ENTRYPOINT ["/sbin/tini", "--", "/usr/local/bin/jenkins.sh"]
                              
                              # from a derived Dockerfile, can use `RUN plugins.sh active.txt` to setup /usr/share/jenkins/ref/plugins from a support bundle
                              COPY plugins.sh /usr/local/bin/plugins.sh
                              COPY install-plugins.sh /usr/local/bin/install-plugins.sh
                              

                              Where the actual Dockerfile for that image is:

                              FROM openjdk:8-jdk-stretch
                              
                              RUN apt-get update && apt-get install -y git curl && rm -rf /var/lib/apt/lists/*
                              
                              ARG user=jenkins
                              ARG group=jenkins
                              ARG uid=1000
                              ARG gid=1000
                              ARG http_port=8080
                              ARG agent_port=50000
                              ARG JENKINS_HOME=/var/jenkins_home
                              
                              ENV JENKINS_HOME $JENKINS_HOME
                              ENV JENKINS_SLAVE_AGENT_PORT ${agent_port}
                              
                              # Jenkins is run with user `jenkins`, uid = 1000
                              # If you bind mount a volume from the host or a data container,
                              # ensure you use the same uid
                              RUN mkdir -p $JENKINS_HOME \
                                && chown ${uid}:${gid} $JENKINS_HOME \
                                && groupadd -g ${gid} ${group} \
                                && useradd -d "$JENKINS_HOME" -u ${uid} -g ${gid} -m -s /bin/bash ${user}
                              
                              # Jenkins home directory is a volume, so configuration and build history
                              # can be persisted and survive image upgrades
                              VOLUME $JENKINS_HOME
                              
                              # `/usr/share/jenkins/ref/` contains all reference configuration we want
                              # to set on a fresh new installation. Use it to bundle additional plugins
                              # or config file with your custom jenkins Docker image.
                              RUN mkdir -p /usr/share/jenkins/ref/init.groovy.d
                              
                              # Use tini as subreaper in Docker container to adopt zombie processes
                              ARG TINI_VERSION=v0.16.1
                              COPY tini_pub.gpg ${JENKINS_HOME}/tini_pub.gpg
                              RUN curl -fsSL https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini-static-$(dpkg --print-architecture) -o /sbin/tini \
                                && curl -fsSL https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini-static-$(dpkg --print-architecture).asc -o /sbin/tini.asc \
                                && gpg --no-tty --import ${JENKINS_HOME}/tini_pub.gpg \
                                && gpg --verify /sbin/tini.asc \
                                && rm -rf /sbin/tini.asc /root/.gnupg \
                                && chmod +x /sbin/tini
                              
                              COPY init.groovy /usr/share/jenkins/ref/init.groovy.d/tcp-slave-agent-port.groovy
                              
                              # jenkins version being bundled in this docker image
                              ARG JENKINS_VERSION
                              ENV JENKINS_VERSION ${JENKINS_VERSION:-2.121.1}
                              
                              # jenkins.war checksum, download will be validated using it
                              ARG JENKINS_SHA=5bb075b81a3929ceada4e960049e37df5f15a1e3cfc9dc24d749858e70b48919
                              
                              # Can be used to customize where jenkins.war get downloaded from
                              ARG JENKINS_URL=https://repo.jenkins-ci.org/public/org/jenkins-ci/main/jenkins-war/${JENKINS_VERSION}/jenkins-war-${JENKINS_VERSION}.war
                              
                              # could use ADD but this one does not check Last-Modified header neither does it allow to control checksum
                              # see https://github.com/docker/docker/issues/8331
                              RUN curl -fsSL ${JENKINS_URL} -o /usr/share/jenkins/jenkins.war \
                                && echo "${JENKINS_SHA}  /usr/share/jenkins/jenkins.war" | sha256sum -c -
                              
                              ENV JENKINS_UC https://updates.jenkins.io
                              ENV JENKINS_UC_EXPERIMENTAL=https://updates.jenkins.io/experimental
                              ENV JENKINS_INCREMENTALS_REPO_MIRROR=https://repo.jenkins-ci.org/incrementals
                              RUN chown -R ${user} "$JENKINS_HOME" /usr/share/jenkins/ref
                              
                              # for main web interface:
                              EXPOSE ${http_port}
                              
                              # will be used by attached slave agents:
                              EXPOSE ${agent_port}
                              
                              ENV COPY_REFERENCE_FILE_LOG $JENKINS_HOME/copy_reference_file.log
                              
                              USER ${user}
                              
                              COPY jenkins-support /usr/local/bin/jenkins-support
                              COPY jenkins.sh /usr/local/bin/jenkins.sh
                              COPY tini-shim.sh /bin/tini
                              ENTRYPOINT ["/sbin/tini", "--", "/usr/local/bin/jenkins.sh"]
                              
                              # from a derived Dockerfile, can use `RUN plugins.sh active.txt` to setup /usr/share/jenkins/ref/plugins from a support bundle
                              COPY plugins.sh /usr/local/bin/plugins.sh
                              COPY install-plugins.sh /usr/local/bin/install-plugins.sh
                              

                              The scanning engine will detect the history/“dockerfile” as follows:

                              [
                                 {
                                    "Size" : 45323792,
                                    "Tags" : [],
                                    "Comment" : "",
                                    "Id" : "sha256:cd8eada9c7bb496eb685fc6d2198c33db7cb05daf0fde42e4cf5bf0127cbdf38",
                                    "Created" : "2018-12-28T23:29:37.981962131Z",
                                    "CreatedBy" : "/bin/sh -c #(nop) ADD file:da71baf0d22cb2ede91c5e3ff959607e47459a9d7bda220a62a3da362b0e59ea in / "
                                 },
                                 {
                                    "Size" : 0,
                                    "Tags" : [],
                                    "Comment" : "",
                                    "Id" : "<missing>",
                                    "Created" : "2018-12-28T23:29:38.226681736Z",
                                    "CreatedBy" : "/bin/sh -c #(nop)  CMD [\"bash\"]"
                                 },
                                 {
                                    "Size" : 10780911,
                                    "Comment" : "",
                                    "Tags" : [],
                                    "CreatedBy" : "/bin/sh -c apt-get update && apt-get install -y --no-install-recommends \t\tca-certificates \t\tcurl \t\tnetbase \t\twget \t&& rm -rf /var/lib/apt/lists/*",
                                    "Created" : "2018-12-29T00:04:28.920875483Z",
                                    "Id" : "sha256:c2677faec825930a8844845f55454ee0495ceb5bea9fc904d5b3125de863dc1d"
                                 },
                                 {
                                    "Comment" : "",
                                    "Tags" : [],
                                    "Size" : 4340024,
                                    "CreatedBy" : "/bin/sh -c set -ex; \tif ! command -v gpg > /dev/null; then \t\tapt-get update; \t\tapt-get install -y --no-install-recommends \t\t\tgnupg \t\t\tdirmngr \t\t; \t\trm -rf /var/lib/apt/lists/*; \tfi",
                                    "Created" : "2018-12-29T00:04:34.642152001Z",
                                    "Id" : "sha256:fcce419a96b1219a265bf7a933d66b585a6f8d73448533f3833c73ad49fb5e88"
                                 },
                                 {
                                    "Size" : 50062697,
                                    "Tags" : [],
                                    "Comment" : "",
                                    "Id" : "sha256:045b51e26e750443c84216071a1367a7aae0b76245800629dc04934628b4b1ea",
                                    "CreatedBy" : "/bin/sh -c apt-get update && apt-get install -y --no-install-recommends \t\tbzr \t\tgit \t\tmercurial \t\topenssh-client \t\tsubversion \t\t\t\tprocps \t&& rm -rf /var/lib/apt/lists/*",
                                    "Created" : "2018-12-29T00:04:59.676112605Z"
                                 },
                               ... <truncated for brevity> ...
                                 {
                                    "Tags" : [],
                                    "Comment" : "",
                                    "Size" : 0,
                                    "Id" : "<missing>",
                                    "CreatedBy" : "/bin/sh -c #(nop)  ENTRYPOINT [\"/sbin/tini\" \"--\" \"/usr/local/bin/jenkins.sh\"]",
                                    "Created" : "2019-01-21T08:56:30.737221895Z"
                                 },
                                 {
                                    "Size" : 1549,
                                    "Tags" : [],
                                    "Comment" : "",
                                    "Id" : "sha256:283cd3aba8691a3b9d22d923de66243b105758e74de7d9469fe55a6a58aeee30",
                                    "Created" : "2019-01-21T08:56:32.015667468Z",
                                    "CreatedBy" : "/bin/sh -c #(nop) COPY file:f97999fac8a63cf8b635a54ea84a2bc95ae3da4d81ab55267c92b28b502d8812 in /usr/local/bin/plugins.sh "
                                 },
                                 {
                                    "Comment" : "",
                                    "Tags" : [],
                                    "Size" : 3079,
                                    "Created" : "2019-01-21T08:56:33.158854485Z",
                                    "CreatedBy" : "/bin/sh -c #(nop) COPY file:3a15c25533fd87983edc33758f62af7b543ccc3ce9dd570e473eb0702f5f298e in /usr/local/bin/install-plugins.sh ",
                                    "Id" : "sha256:b0ce8ab5a5a7da5d762f25af970f4423b98437a8318cb9852c3f21354cbf914f"
                                 }
                              ]
                              

                              Triggers

                              This section provides more detail on four triggers than is found in the Scanning Policy Gates and Triggers reference.

                              Trigger: instruction

                              This trigger evaluates instructions found in the “dockerfile”.

                              Parameters

                              • actual_dockerfile_only (optional). See Using the actual_dockerfile_only section, above.

                              • instruction: The dockerfile instruction to check against. One of:

                                • ADD

                                • ARG

                                • COPY

                                • CMD

                                • ENTRYPOINT

                                • ENV

                                • EXPOSE

                                • FROM

                                • HEALTHCHECK

                                • LABEL

                                • MAINTAINER

                                • ONBUILD

                                • USER

                                • RUN

                                • SHELL

                                • STOPSIGNAL

                                • VOLUME

                                • WORKDIR

                              • check: The comparison/evaluation to perform. One of: =, != , exists, not_exists, like, not_like, in, not_in

                              • value (optional): A string value to compare against, if applicable

                              Examples

                              Ensure an image has a HEALTHCHECK defined in the image. Warn if not found

                              {
                                "gate": "dockerfile",
                                "trigger": "instruction",
                                "action": "warn",
                                "parameters": [
                                  {
                                    "name": "instruction",
                                    "value": "HEALTHCHECK"
                                  },
                                  {
                                    "name": "check",
                                    "value": "not_exists"
                                  }
                                ]
                              }
                              

                              Check for AWS environment variables set

                              {
                                "gate": "dockerfile",
                                "trigger": "instruction",
                                "action": "stop",
                                "parameters": [
                                  {
                                    "name": "instruction",
                                    "value": "ENV"
                                  },
                                  {
                                    "name": "check",
                                    "value": "like"
                                  },
                                  {
                                    "name": "value",
                                    "value": "AWS_.*KEY"
                                  }
                                ]
                              }
                              

                              Trigger: effective_user

                              This trigger processes all USER directives in the Dockerfile or history to determine which user will be used to run the container by default (assuming no user is set explicitly at runtime). The detected value is then subject to a whitelist or blacklist filter depending on the configured parameters. Typically, this is used for blacklisting the root user.

                              Parameters

                              • actual_dockerfile_only (optional). See Using the actual_dockerfile_only section, above.

                              • users: A string with a comma-delimited list of username to check for

                              • type: The type of check to perform. One of: blacklist or whitelist. This determines how the value of the users parameter is interpreted.

                              Examples

                              Blacklist root user

                              {
                                "gate": "dockerfile",
                                "trigger": "effective_user",
                                "action": "stop",
                                "parameters": [
                                  {
                                    "name": "users",
                                    "value": "root"
                                  },
                                  {
                                    "name": "type",
                                    "value": "blacklist"
                                  }
                                ]
                              }
                              

                              Blacklist root user but only if set in actual Dockerfile, not inherited from parent image

                              {
                                "gate": "dockerfile",
                                "trigger": "effective_user",
                                "action": "stop",
                                "parameters": [
                                  {
                                    "name": "users",
                                    "value": "root"
                                  },
                                  {
                                    "name": "type",
                                    "value": "blacklist"
                                  },
                                  {
                                    "name": "actual_dockerfile_only",
                                    "value": "true"
                                  }
                                ]
                              }
                              

                              Warn if the user is not either “nginx” or “jenkins”

                              {
                                "gate": "dockerfile",
                                "trigger": "effective_user",
                                "action": "warn",
                                "parameters": [
                                  {
                                    "name": "users",
                                    "value": "nginx,jenkins"
                                  },
                                  {
                                    "name": "type",
                                    "value": "whitelist"
                                  }
                                ]
                              }
                              

                              Trigger: exposed_ports

                              This trigger allows checks on the way the image was added, firing if the Dockerfile was not explicitly provided at analysis time. This is useful in identifying and qualifying other trigger matches.

                              Parameters

                              • actual_dockerfile_only (optional). See Using the actual_dockerfile_only section, above.

                              • ports: String of comma-delimited port numbers to be checked

                              • type: The type of check to perform. One of: blacklist or whitelist. This determines how the value of the users parameter is interpreted.

                              Examples

                              Allow only ports 80 and 443. Trigger will fire on any port defined to be exposed that is not 80 or 443

                              {
                                "gate": "dockerfile",
                                "trigger": "exposed_ports",
                                "action": "warn",
                                "parameters": [
                                  {
                                    "name": "ports",
                                    "value": "80,443"
                                  },
                                  {
                                    "name": "type",
                                    "value": "whitelist"
                                  }
                                ]
                              }
                              

                              Blacklist ports 21 (ftp), 22 (ssh), and 53 (dns) . Trigger will fire a match on ports 21, 22, 53 if found in EXPOSE directives

                              {
                                "gate": "dockerfile",
                                "trigger": "exposed_ports",
                                "action": "warn",
                                "parameters": [
                                  {
                                    "name": "ports",
                                    "value": "21,22,53"
                                  },
                                  {
                                    "name": "type",
                                    "value": "blacklist"
                                  }
                                ]
                              }
                              

                              Trigger: no_dockerfile_provided

                              This trigger allows checks on the way the image was added, firing if the Dockerfile was not explicitly provided at analysis time. This is useful in identifying and qualifying other trigger matches.

                              Parameters

                              None

                              Examples

                              Raise a warning if no Dockerfile was provided at analysis time

                              {
                                "gate": "dockerfile",
                                "trigger": "no_dockerfile_provided",
                                "action": "warn",
                                "parameters": []
                              }
                              
                              

                              5 -

                              Manage Scanning Alerts

                              Image scanning alerts, like all Sysdig alerts, can be configured to notify users when an issue in the infrastructure arises. Scanning alerts can be created for static images in the repository or for running (runtime) images. Scanning alerts focus on when unscanned images are added to the environment, images fail a policy evaluation, scanning results change, or CVEs are updated.

                              Examples of when users might implement alerts:

                              • I want to know if there are new CVE updates for the 3 different images I handle

                              • I want to be notified if any of the common images from docker hub that are used all over my organization have a policy status that has changed

                              Manage the Scanning Alert List

                              From the Image Scanning module, choose the Alerts tab. The Scanning Alert list is displayed.

                              From here you can search for existing alerts, and create, duplicate or delete alerts.

                              Add an Alert

                              1. To create a new alert: From the Image Scanning module, choose the Alerts tab and click Add Alert.

                              2. Select either Runtime or Repository alert type.

                              3. Fill in the appropriate New Alert page (below).

                              Create a Runtime Alert

                              Use Runtime alerts to scan running images and trigger a notification in case of a policy violation, status change, or unscanned image added to the environment. Enter the alert parameters and click Save.

                              Basic Parameters

                              Enter a Name and optional Description.

                              Scope

                              Use Everywhere or define a narrower scope.

                              Triggers

                              Unscanned Image

                              Check the box to trigger an alert. To have images scanned automatically instead of simply triggering the alert, install the Node Image Analyzer.

                              Note that this is a change from the way automated scanning was handled in previous releases.

                              Scan Result Change
                              • Pass/Fail: Choose this option to be notified when an image that had previously passed now fails its policy evaluation.

                              • Any Change: Choose this option to be notified when there is any change on a previously scanned image result.

                              Note that if Scan Result Change is checked and a notification channel is configured, an alert will be sent. If no channel is set up, nothing will happen.

                              For example, the following image shows a Slack notification that was triggered when “Any Change” was configured.

                              CVE Update

                              Choose this option to be notified whenever a vulnerability is added, updated, or removed from a running image.

                              Notification Channel

                              Click **+ Add Channel **to select a configured notification channel (e.g. email) to be used for alert notifications.

                              If no notification channels have been defined for your Sysdig Secure environment yet, see Set Up Notification Channels.

                              OpsGenie and ViktorOps notification channels are not supported for image scanning alerts.

                              Create a Repository Alert

                              Use Repository alerts to scan static images in the repository and trigger a notification in case of a policy violation, status change, or a new image added to the environment. Enter the alert parameters and click Save.

                              Basic Parameters

                              Enter a Name and optional Description.

                              Registry/Repo/Tag

                              Enter the registry scope to be considered in the alert. Wildcards * are supported. If a wildcard is used for either the registry or the repo, the only alert option will be New Image Analyzed.

                              Triggers

                              New Image Analyzed

                              Check the box to be alerted whenever a new image is analyzed, regardless of the result.

                              Scan Result Change
                              • Pass/Fail: Choose this option to be notified when an image that had previously passed now fails its policy evaluation.

                              • Any Change: Choose this option to be notified when there is any change on a previously scanned image result.

                              Note that if Scan Result Change is checked and a notification channel is configured, an alert will be sent. If no channel is set up, nothing will happen.

                              CVE Update

                              Choose this option to be notified whenever a vulnerability is added, updated, or removed from an image within the repository alert scope.

                              For example, the following image shows a Slack notification that was triggered when “CVE Update” was configured.

                              Notification Channel

                              Click + Add Channel to select a configured notification channel (e.g. email) to be used for alert notifications.

                              If no notification channels have been defined for your Sysdig Secure environment yet, see Set Up Notification Channels.

                              Edit an Alert

                              1. From the Image Scanning module, choose the Alerts tab.

                              2. Select the desired alert from the list.

                              3. Edit the alert trigger, scope, and notification channels as necessary, and click Save.

                              Duplicate an Alert

                              1. From the Image Scanning module, choose the Alerts tab.

                              2. Select the desired alert from the list.

                              3. Click the More (three dots) icon and click Duplicate Alert from the drop-down, then Yes to confirm.

                              Delete an Alert

                              1. From the Image Scanning module, choose the Alerts tab.

                              2. Select the desired alert from the list.

                              3. Click the More (three dots) icon and click Delete Alert from the drop-down, then Yes to confirm.

                              6 -

                              Review Scan Results

                              When you have set up your build environment for scanning (if applicable), added the desired registries, and either triggered a scan manually or configured an alert to scan automatically, then an image scanning report is generated.

                              There are different ways to access scan results:

                              • Externally (for developers): From an external Continuous Integration (CI) tool such as Jenkins.

                              • Internally (for security personnel): From the Runtime tab or the Scan Results tab (formerly titled “Repositories”) in the Image Scanning module of Sysdig Secure.

                              NOTE: Images containing RPM packages with SHA512 hashes are not supported.

                              Scan Results Landing Page

                              Once a scan has been run, choose Image Scanning > Scan Results to see the landing page.

                              From here you can:

                              • Check quick-view charts for at-a-glance summaries of:

                                • Number of images scanned

                                • Pass/fail status

                                • Origins of image feeds

                              • Search and filter results, by:

                                • Keyword

                                • Pass/fail status

                                • Origin (drop-down menu)

                                • Registry (drop-down menu)

                                Save or Reset a search from the three-dots menu to the right of the nav bar.

                              • Sort the results list by date.

                              • Select an Image to see its Summary page.

                              Summary View

                              Select Image Scanning > Scan Results and select an Image to land on the results summary.

                              On the Summary page you can:

                              • Review results of vulnerability matching and policy evaluations in two separate sections

                              • Check the date and time of the vulnerability match and the most recent policy evaluation. These usually differ.

                              • Expand/collapse the policy breakdown for ease of view and removal of visual clutter

                              • Click Reevaluate Policies to trigger new policy results.

                              • Download results as a PDF, including all the policy and vulnerability details.

                              Select detail pages from the left navigation to see detail views.

                              Runtime View

                              Runtime provides an always-updated report on images that have been running in your environment over the past 1 hour.

                              In the left column: view the Entire Infrastructure or drill down to a namespace.

                              In the Image Overview: See the percentage of Unscanned, Failed, and Passed images and click on each to get the relevant filtered list.

                              Use the Search bar: To find images based on Registry, Image Name, or Tag.

                              You can drill down to the Scan Result Details.

                              Unscanned Images

                              Select an unscanned image to manually trigger a scan.

                              Scanned Images

                              Select a scanned image to drill down into the details: a Summary page, Policy details, Vulnerability details, and Content violations (e.g., licenses).

                              6.1 -

                              Scan Result Details

                              When you drill down into the Scan Results list, the details menu provides a variety of ways to view vulnerability and policy violation data at a glance.

                              • Policy Summary views

                              • Vulnerabilities summaries

                              • Content summaries

                              These summaries provide:

                              • An easy-to-parse view of why a specific image failed

                              • Which rules generated the most Warn and Stop actions

                              • Overview of how an image has performed against the various audit policies that have been put in place

                              • Ability to filter for high-severity CVEs, and see which have an available fix

                              You can also download the Policy Summary to PDF and the Vulnerabilities Summary to a CSV file.

                              Policy Results Views

                              Summary

                              The landing page of a Scan Results detail is the Policy Summary view.

                              You can:

                              • Get a birds-eye view of scanning status

                              • Drill down to a detail page

                              • Click Download as PDF to get a full report, including all underlying CVEs.

                              • Added On: See the date and time the scan was added.

                              • Added By: See the mechanism by which the scan was reported.

                                Possible values are: Sysdig Secure UI, Node Image Analyzer, API, Sysdig Inline Scanner, or Scanning alert.

                              • Re-evaluate: Click the button to fetch the newest scan results

                              Select Dates for Past Scans

                              From the dropdown, select the date of the scan you’d like to analyze.

                              Review Scanning Policy Details

                              Select a listed Policy to see details about the STOP and WARN actions triggered in the Evaluation,

                              as well as the underlying Rules affected.

                              Review Vulnerability Summaries

                              Select either Operating System-related or Non-Operating System-related Vulnerability summaries to review.

                              You can:

                              • Get a birds-eye-view of vulnerability status

                              • Click a CVE number to get the full details and/or add it to an Exceptions list

                              • Search or filter by severity: Critical, High, Medium, Negligible, Unknown. Also filter by whether it “Has a Fix”.

                              • Click Download CSV to get the vulnerabilities data as a CSV file

                              • Open the Vulnerabilty Details panel on the right by selecting an image from the list

                              • Added On: See the date and time the scan was added.

                              Red Hat Vulnerability Details

                              For Red Hat vulnerabilities, the details panel provides both the Sysdig severity rating and the equivalent severity label from the Red Hat Security Tracker.

                              The labels are mapped as follows:

                              Sysdig SeverityRed Hat SeverityRed Hat Definition
                              CriticalCriticalThis rating is given to flaws that could be easily exploited by a remote unauthenticated attacker and lead to system compromise (arbitrary code execution) without requiring user interaction. Flaws that require authentication, local or physical access to a system, or an unlikely configuration are not classified as Critical impact. These are the types of vulnerabilities that can be exploited by worms.
                              HighImportantThis rating is given to flaws that can easily compromise the confidentiality, integrity or availability of resources. These are the types of vulnerabilities that allow local or authenticated users to gain additional privileges, allow unauthenticated remote users to view resources that should otherwise be protected by authentication or other controls, allow authenticated remote users to execute arbitrary code, or allow remote users to cause a denial of service.
                              MediumModerateThis rating is given to flaws that may be more difficult to exploit but could still lead to some compromise of the confidentiality, integrity or availability of resources under certain circumstances. These are the types of vulnerabilities that could have had a Critical or Important impact but are less easily exploited based on a technical evaluation of the flaw, and/or affect unlikely configurations.
                              LowLowThis rating is given to all other issues that may have a security impact. These are the types of vulnerabilities that are believed to require unlikely circumstances to be able to be exploited, or where a successful exploit would give minimal consequences. This includes flaws that are present in a program’s source code but to which no current or theoretically possible, but unproven, exploitation vectors exist or were found during the technical analysis of the flaw.
                              Negligiblen/an/a

                              Vulnerability Comparison

                              The vulnerability comparison allows users to compare two different tags within the same repo to see which vulnerabilities are new or have been fixed in version X compared to version Y.

                              This allows developers easily to compare the latest image to a previous version to easily report on which vulnerabilities have been addressed and which are new.

                              1. Select an image from a line in the Scan Results list.

                              2. From the Compare To drop-down, select another version of this image with which to compare.

                              3. The comparison report is displayed.

                              Review Content Details

                              Navigate through node, ruby, python, java, OS packages, and the files in a container to search for details about a particular package or file.

                              7 -

                              Scheduled Reports

                              Image Scanning Reports [BETA]

                              Overview

                              You need to enable this feature from the Sysdig Labs setting on the User Profile page. Once enabled, it will replace the Reporting v2 UI in the product page. (Reporting v2 API endpoints will still be available at this time, though deprecated eventually).

                              The Image Scanning Reports feature has been thoroughly updated and has moved from a synchronous model to an asynchronous mode, in which you schedule the reports you need and then receive them through your normal notification channels (email, Slack, webhook.). The new version also includes:

                              • A preview function to check report structure in the UI

                              • A more advanced query builder

                              • Extended set of data columns (i.e. CVSS base score and vector) and extended set of available filters (i.e. package type)

                              Asynchronous Reports can be run on vulnerabilities and on policies.

                              There are two different types of asynchronous reports:

                              • Vulnerabilities: Vulnerabilities, package and image data

                              • Policies: Images and scanning policies data

                              Create Report Definition

                              1. Log in to Sysdig Secure with Advanced User or higher permissions, and select Image Scanning|Reports.

                                Note: For Runtime Reports, the runtime scope must fall within your team’s designated scope. (For static reports, there is no scope requirement.)

                              2. From the Reports list page, click Add Report.

                              3. Define the Report Configuration and Data as described below. Optionally, Preview the selected Data.

                              4. Click Save and review the entry on the Report list page.

                              Define Report Configuration

                              Reporting creates a point-in-time snapshot of the scanning results state whenever the process starts, regardless of reports frequency.

                              Here you define the report name, description, schedule, and the notification channel(s) used to deliver the report.

                              Define the following properties:

                              • Name and Description: Choose a meaningful title and description

                              • Schedule- Report creation starts: Choose the cadence (daily, weekly, monthly) and the time (by half-hour) at which you want this report generated.

                                The schedule determines when the report data collection begins. As soon as evaluation is complete, you will receive a notification in the configured notification channels.

                              • Notification channel: The options presented in the drop-down list correspond to the notification channels you have set up in your environment.

                                Since reports are typically large, the actual data is not sent to the notification channel; you receive a link to download it. You must be a valid Sysdig Secure user (Advanced User+) to access the link .

                              Define Report Data

                              Here you define the data to be included in the report.

                              Select from the options:

                              • Type: Choose whether to report on Vulnerabilities or Policies.

                                Vulnerability Vulnerabilities, package and image data

                                Columns:

                                • Vulnerability ID

                                • Severity

                                • Vulnerability type (OS / NON-OS)

                                • Vulnerability feed link

                                • Fix version (if any)

                                • Image name

                                • Image tag

                                • Image added date (to the Sysdig backend)

                                • Package name

                                • Package version

                                • CVSS v2 vector (if any), CVSS v2 base score (if any), CVSS v3 vector (if any), CVSS v3 base score (if any)

                                • Image ID

                                • Vuln exception (Whether you have configured an exception for this vulnerability)

                                • Runtime scope (only if configuring a runtime scope)

                                Policies: Images and scanning policies data

                                Columns:

                                • Policy name

                                • Policy evaluation (pass / fail)

                                • Image name

                                • Image tag

                                • Image ID

                                • Image added date (to the Sysdig backend)

                                • Last evaluation date (against this scanning policy)

                                • Runtime scope (only if configuring a runtime scope)

                              • Scope: Choose Registry or Runtime.

                                Registry: Report on the images belonging to a registry and present on the Sysdig Secure scan results. The Rgistry field is mandatory (i.e. docker.io), repository and tag are optional, if you want to narrow down the report to a specific set of images.

                                Runtime: Report on the runtime images present on the Sysdig Secure scan results. You can select Entire infrastructure or scope down using Sysdig runtime scope labels (i.e. kubernetes.cluster.name = mycluster).

                                Note that the runtime scope must fall within your team’s designated scope, and only those options will be displayed.

                              • Condition: (Optional) You can configure one or more conditions that will filter the data that you deem relevant for the report.

                                Vulnerability Report Filters

                                • Vulnerability type (OS/Non-OS)

                                • Vulnerability ID

                                • Vulnerability added to feed (x days ago)

                                • Package name: supports startswith, i.e. ‘cur’ will match ‘curl’

                                • Severity: supports exact match, equals or greater than and equals or lower than

                                • CVSS v2 score greater than ‘value’, one decimal place supported

                                • CVSS v3 score greater than ‘value’, one decimal place supported

                                • Feed source (multi-select)

                                • Fix Available (yes/no)

                                • Severity (critical, high, medium, low,. negligible, unknown)

                                • Package type (i.e. rpm, apk, python)

                                • OS name, i.e. debian, supports startswith

                                • Image added to the Sysdig scan results ‘more than’ or ‘less than’ X days ago

                                • Vuln exception (true/false)

                              • Policy Report Filters

                                • Policy: Filter by images evaluated by a specific policy (i.e. NIST scan policy)

                                • Policy evaluation (pass/fail)

                                • Last evaluation ‘more than’ or ‘less than’ X days ago

                                • OS Name, i.e. ‘debian’, supports startswith

                                • Docker file available (yes/no)

                                • Image added to the Sysdig scan results ‘more than’ or ‘less than’ X days ago

                              Preview or Clear

                              Preview offers a quick sample of the rows that will be obtained given the current report configuration. Preview can be used to verify format, filters and expected output. Take into account that preview data, although extracted from the real environment data, is too reduced to be significant.

                              The Clear button will reset the filters.

                              Sample Use Cases and their Previews
                              • Show me all Vulnerabilities in my Runtime with High Severity and a Fix Available, which are not on an Exclusions list.

                              • Show Images in my docker.io registry failing the NIST 800-190 scanning policy.

                              Manage Reports List

                              • Enable/Disable: By default, all report definitions are enabled. To disable, toggle the button by the Name on the List view. The report definition will be saved, but the report will not be run. It can be re-enabled at any time.

                              • Use the More (three dot) menu to:

                                • Edit Report Definition

                                • Duplicate the Report Definition

                                • Delete Report Definition

                              Instrumenting Reports

                              From email notification:

                              If you have configured email as a notification channel for reports (see sample screenshot) :

                              then click the button to automatically download the report, provided your browser contains a valid Sysdig Secure user session. If no session is found, you will be redirected to the login screen.

                              From a webhook or Slack notification:

                              These methods will also send a link to the report, which you can download programmatically using the your Sysdig API token, for example:

                              curl -L -H "Authorization: Bearer <my_API_token>" https://secure.sysdig.com/api/reporting/v1/scanning/reports/1q8gX9ErBwpDdNZKDbYm5Zzzyyxxx -o report.csv
                              
                              

                              8 -

                              Host Scanning

                              With Host Scanning, Sysdig is now able to check for vulnerabilities in the host operating system, whether OS (e.g rpm, dpkg) or non-OS (e.g. Java packages, Ruby gems). This contrasts with all other Sysdig scanning tools, which are focused on container images, rather than the host itself.

                              The analyzer component of host scanning works by inspecting the files on the host root filesystem, looking for installed packages, and sending them to the Sysdig backend.

                              By default, host scanning:

                              • Is triggered every 24 hours

                              • Includes a default list of directories that are scanned by the analyzer.

                              It is possible to configure the schedule and/or the list of directories to be scanned using the Host Scanning Configuration Options if needed.

                              The feature is installed using the Node Analyzer component and is currently available for Sysdig Secure SaaS.

                              Supported Operating Systems

                              Supported OSs:

                              • Ubuntu 16.04, 18.04, 20.04

                              • RedHat Enterprise Linux 7, 8

                              • Debian 8, 9, 10

                              • Amazon Linux 2

                              Unsupported OSs:

                              • RedHat CoreOS (currently not supported)

                              • Google COS (this system does not have a package manager or standard packages and therefore cannot be supported)

                              Access Host Scanning

                              1. Follow the steps for the Node Analyzer: Multi-Feature Installation.

                              2. Log in to Sysdig Secure with at least Advanced User privileges.

                                The results you can see in the Host Scanning list are affected by your user and team privileges.

                              3. Select Scanning > Hosts. The Host Scanning list page is displayed.

                                From here you can:

                              Search Results or Filter by Scope

                              On the Host Scanning landing page, you can:

                              • Search: by hostname, mac, cluster name

                              • Filter by Team Scope: Your active team scope is applied when viewing Host Scanning results, but you can further narrow down from Entire Infrastructure using the scope filters.

                                You can compose a scope filter using various operators (in, not-in, equal, not-equal, etc.).

                              Then proceed to review the vulnerabilities.

                              Purge Disabled Hosts

                              On the Host Scanning list page, click the three dot selector on the far right to access the Purge Disabled Hosts from Scope button.

                              Use this feature for hosts that have been removed from your cluster, to ensure they are also removed from the host scan list page.

                              Review Host Vulnerabilities

                              There are multiple ways to access the result details:

                              • Select a host (line item) from the landing page, or

                              • Choose View Vulnerabilities from the expanded selector at the end of a line item

                              Either choice opens a Host Results page.

                              From the Host Results page, you can:

                              • Filter by severity and whether the vulnerability has a fix

                              • Select a vulnerability to review details and remediation steps in a pull-out

                              • Compare earlier results and/or view the diff

                                By default, host scans are run every 24 hours, so you can view the Current results, the Previous (one day ago) results, or the Difference in findings between the two.

                                If nothing was changed or fixed between the two scans, the findings will look the same. The summary is displayed.

                              • Download report as a CSV or JSON file

                              See Scanning Results for Containers on the Host

                              For any given host, you can also check the image scan results of its containers from the Host Scanning landing page.

                              1. Select Scanning > Hosts.

                              2. Hover over a line item and choose View Runtime Images from the far-right selector.

                                The Scanning Results page is displayed, showing the detailed runtime scanning results for the containers on your selected host.

                              9 -

                              Feeds Status

                              The Feeds Status page shows the different vulnerability feeds with which Sysdig integrates.

                              It displays the vulnerability feed group (often the distro version), the time of the last synchronization, and how many CVE records are present in the feed group.

                              To review the Feeds Status:

                              1. Navigate to the Settings menu in the Sysdig Secure UI.

                              2. Select Feeds Status.

                              10 -

                              Admission Controller

                              This feature is offered through Sysdig Labs and is installed as its own component. See Admission Controller: Installation

                              Understanding the Admission Controller

                              Kubernetes' admission controllers help you define and customize which requests are allowed on your cluster. An admission controller intercepts and processes requests to the Kubernetes API prior to persistence of the object, but after the request is authenticated and authorized.

                              Image Scanning Capabilities: Sysdig’s Admission Controller (UI-based) builds upon Kubernetes and enhances the capacity of the image scanner to check images for Common Vulnerabilities and Exposures (CVEs), misconfigurations, outdated images, etc., elevating the scan policies from detection to actual prevention. Container images that do not fulfill the configured admission policies will be rejected from the cluster before being assigned to a node and allowed to run.

                              Kubernetes Audit Logging Capabilities: Enable the features.k8sAuditDetections=true option to use Kubernetes audit logging features with the admission controller. (See also: Kubernetes Audit Logging.)

                              Usage Steps for Image Scanning with the AC

                              The Admission Controller is installed per-cluster. The workflow is straightforward:

                              Installation:

                              • Enable the feature in Sysdig Labs to activate it in the Sysdig Secure backend, for image scanning.

                              • Install the Admission Controller in the target cluster(s) and verify that it appears in the Sysdig UI as “Connected.”

                              Usage:

                              Create Admission Controller Policies

                              Admission Controller Policies define the criteria to accept or reject a given container image at admission time. Remember that Policies must be assigned to a cluster to be enforced.

                              1. Log in as Administrator to Sysdig Secure and select Image Scanning> Admission Controller|Policies.

                                The Admission Controller Policies page displays a list of any previously defined policies.

                              2. Click +Policy and enter a meaningful Name and Description.

                              3. Define the policy Rules:

                                • Evaluation Failure: Whether to reject images that are failing scanning policy evaluation

                                • Evaluation Age: Whether to reject images when the evaluation is older than X days. You might set this condition to force a new vulnerability check, for example.

                                • Unscanned Image: Whether to reject images that do not have an existing evaluation at admission time. Choose from three options:

                                  • Ignore: Ignore this condition

                                  • Reject: Reject the request

                                  • Reject and Scan: Reject the request and scan the image in parallel.

                                    Typically, Kubernetes will retry creating the pending image, so eventually the image will have a valid evaluation and then the other conditions will apply. Since scanning during admission can potentially slow down the deployment process, we don’t recommend this option unless you are confident that most images will have an evaluation before admission (i.e. instrumenting the CI/CD pipelines).

                              4. Click Save.

                              How Policy Conditions are Applied

                              Policy conditions are applied using an AND operator.

                              For example, if I set Evaluation Fail to Reject, AND Evaluation Age to Reject for older than 15 days, then if I receive an image with an existing evaluation that is passing, and that evaluation is 20 days old, the request will be rejected.

                              Assign Admission Controller Policies

                              1. Log in as Administrator to Sysdig Secure and select Image Scanning> Admission Controller|Policy Assignment.

                                The admission controller policy assignment page displays the list of Kubernetes clusters with Admission Controllers, and their current status.

                                • Connected/disconnected clusters: Clusters where the admission controller was never installed will not appear at all. Otherwise:

                                  • Connected: Clusters with a connected and healthy admission controller will show under the “Connected” label. 

                                  • Disconnected: A Kubernetes cluster that had an admission controller installed, but the admission controller component is not reporting back to the Sysdig backend, will appear under the “Disconnected” label.

                                • Enabled/disabled Admission Controllers: You enable/ disable the admission controller for each cluster using the switch on the top right.

                                  • Enabled: A green dot by the cluster name shows the admission controller is enabled (enforcing)

                                  • Disabled: A grey dot means the admission controller is disabled.

                              2. Click +Add Assignment and enter the basic assignment details.

                                A cluster can have multiple assignments at different levels of granularity, and the policies are evaluated from top to bottom. See also: ???.

                                • Namespace: Leave blank to match any namespace, or add a relevant entry.

                                • Prefix: Leave blank to match any image name, or limit by entering a particular prefix. For example, the redis prefix would match images declared as redis:latest or redis:v2 in the container creation request.

                                • Policy: Select a policy from the drop-down list.

                              3. Choose Default policy if no other assignment matches: Select to Allow by default or Reject by default.

                                Be very careful with the Reject by default option. Be sure to explicitly allow critical workloads in your system.

                              4. Click Save.

                              5. Optional: Drag the new assignment to a different position in the evaluation list if it should be applied before another assignment.

                              Understanding Evaluation Order

                              Assignments are evaluated from top to bottom. The first match dictates which policy will be applied,. The default cluster action will be applied if no assignment matches.

                              For example:

                              Assignment 1:  Namespace kube-system; any Image path uses Policy1

                              Assignment 2: All namespaces; Image path starts with quay.io/myimage uses Policy2

                              Default policy: If no other assignment matches, them Reject

                              Then:

                              • Requesting to create a container with path docker.io/myimage in the kube-system namespace will apply Policy1

                              • Requesting to create a container with path quay.io/myimage in the kube-system namespace will apply Policy1

                              • Requesting to create a container with path quay.io/myimage in the mynamespace namespace will apply Policy2

                              • Requesting to create a container with path docker.io/myimage in the mynamespace namespace will be Rejected.

                              Usage Steps for Kubernetes Audit Logging with the AC

                              • When Installing the Admission Controller, set features.k8sAuditDetections to true.

                              • Create policies of the Kubernetes Audit Policy type.

                              • Check the Events UI for entries.

                              Enable/Disable the Admission Controller

                              It is recommended to develop the policies and assignments while the Admission Controller is Disabled. Enable on a staging cluster to test before enabling in production.

                              When you are happy with the defined behavior:

                              1. Log in as Administrator to Sysdig Secure and select Image Scanning> Admission Controller|Policy Assignment.

                              2. Select the relevant cluster from the left side menu.

                              3. Slide the Admission Controller to Enabled.

                              4. Monitor any resulting events as usual.

                              The Disable function can also be used to quickly stop the Admission Controller if unexpected behavior is detected that adversely affects the function of a cluster.

                              10.1 -

                              Admission Controller (CLI-Based)

                              A UI-based Admission Controller is now available, and is not backward-compatible with the CLI-based version. We advise not installing the CLI-based version at this time.

                              Sysdig Admission Controller

                              Sysdig’s Admission Controller (UI-based) combines the Sysdig Secure image scanner with a policy language to evaluate scan results and the admission context, providing great flexibility in the admission decision. It also provides the first line of defense against image-based security threats.

                              By using Kubernetes API extensions to perform image scanning and other security checks on admission, we cover a major threat-prevention and hardening use case: “Only the images that are explicitly approved will be allowed to run on my cluster”.

                              The admission decision relies not only on the image name and tag but also on additional context from the admission review, including namespace, pod metadata, etc.

                              Features

                              • Registry and repository whitelist / blacklist

                              • Global and per-namespace admission configuration

                              • Configurable pre-scan and post-scan behavior, i.e.:

                                • Accept only the images that pass the scan (default)

                                • Directly reject non-whitelisted registries / repos, without scanning

                                • Accept the image even if it doesn’t pass the scan

                                • Do not accept any image that hasn’t been scanned already

                              • Pod mutation: image tag is replaced by digest to prevent TOCTOU (Time of Check, Time of Use) issue if the tag is updated between the scan and the pod scheduling

                              Requirements

                              • Helm 3

                              • Kubernetes 1.15 or higher

                              More Information

                              11 -

                              New Scanning Engine [Preview]

                              Sysdig is developing a new scanning engine with major improvements and additional features. Some of the features offered with the first iteration of the new engine are:

                              • Provides faster scan times when analyzing an image from the CI/CD pipeline or from your developer machine.
                              • Offers more advanced and accurate vulnerability data and CVSS vector scoring from different vendors and exploitability metrics.
                              • Features improved and more intuitive user experience.

                              The new engine is currently under development, but it can be enabled already as a Preview.

                              About Preview

                              In Sysdig parlance, Preview means showcasing a new feature that is under heavy development. In this case:

                              • The new scanning engine cannot be used for production data or flows and there are no forward compatibility guarantees for the data or the configuration yet. We recommend that you do not store any data beyond testing and evaluation.

                              • The new scanning engine is distinct and independent from the existing scan engine. What it means is that, for example, an image scanned with the new inline scanner will be available only in the new scanning engine menu options.

                              However, it is safe to test the new scanning engine while you are still using the current scanning engine for production. These features will not interfere with each other in any way.

                              • The main goal of Preview is to collect feedback from you, and use it to keep advancing the feature set.

                              Enable the New Scanning Engine for Your Account

                              1. Log in to Sysdig Secure.

                              2. Navigate to Settings > User Profile.

                              3. In the Sysdig Labs section, enable New Scanning Engine.

                              4. Check whether the Vulnerability Management section is displayed.

                              Scan results are separated from the scan results in the current scanning engine to indicate that data and configurations for these interfaces are completely detached from the current scanning engine.

                              Get the Inline Scanner Binary

                              1. Download the inline scanner binary and use it to scan the target containers:

                              Linux

                              curl -LO "https://download.sysdig.com/scanning/inlinescan/inlinescan_$(curl -L -s https://download.sysdig.com/scanning/inlinescan/latest_version.txt)_linux_amd64"
                              

                              MacOS

                              curl -LO "https://download.sysdig.com/scanning/inlinescan/inlinescan_$(curl -L -s https://download.sysdig.com/scanning/inlinescan/latest_version.txt)_darwin_amd64"
                              
                              1. On both Linux and MacOS, ensure that you make the inline scan executable by using chmod +x ./inlinescan_<version>_<arch>. Replace <version> with the latest version that you have downloaded. Replace <arch> with your OS/architecture version.

                              Currently supported OS and arch:

                              • linux_amd64
                              • darwin_amd64

                              For example: ./inlinescan_0.1.0_linux_amd64

                              Analyze an Image with Inline Scanner

                              Run the following command:

                              SECURE_API_TOKEN=<user_API_token> ./inlinescan_<version>_<arch> --apiurl https://secure.sysdig.com mongo-express:0.54.0

                              You can get the inline help by running -h or --help from the command line. For example:

                              ./inlinescan_<version>_<arch> -h

                              Usage

                              inlinescan_<version>_<arch> [OPTIONS] ImageName

                              Mandatory Parameters

                              • SECURE API TOKEN : The SECURE_API_TOKEN is an environment variable. Navigate to Settings > User Profile to find the API token associated with your user account.
                              • API URL: --apiurl specifies the Secure backend location where you want to push the scanning results.
                              • Image: The image that you want to scan. In the example given, it is mongo-express:0.54.0.

                              Arguments

                              ImageName: Required parameter. Specify the image name.

                              Help Options

                              -h, --help: Show the command line help.

                              Example

                              Application Options:
                                -a, --apiurl=           Secure API base URL
                                -t, --apitimeout=       Secure API timeout (seconds) (default: 120)
                                    --output-json=      Output path of the scan result report in json format
                                -s, --skiptlsverify     Skip TLS certificate verification (default: false)
                                -u, --skipupload        Skip the scan results upload (default: false)
                                -d, --dbpath=           Database full path. By default it uses main.db.gz from the same directory
                                -p, --cachepath=        Cache path
                                -c, --clearcache        Clear the cache before to run (default: false)
                                -l, --loglevel=         Log level (default: info)
                                -o, --logfile=          File destination for logs, used if --console-log not passed
                                    --console-log       Force logs to console, --logfile will be ignored
                                    --full-vulns-table  Show the entire list of packages found
                              
                              Help Options:
                                -h, --help              Show this help message
                              
                              Arguments:
                                ImageName:              Image name
                              

                              Compatibility and Supported Modes

                              Supported Registries and Image Types

                              • Docker Registry V2 - compatible
                              • Docker Daemon
                              • Podman
                              • Docker Archive (tar)
                              • OCI Archive

                              Supported Package Types

                              • Debian
                              • Alpine
                              • RHEL
                              • Ubuntu
                              • Java Maven
                              • Pypi
                              • NPM (JS)
                              • Ruby Gems
                              • NuGet
                              • Cargo (Rust)

                              12 -

                              Windows Container Image Scanning [BETA]

                              Overview

                              Sysdig provides a standalone vulnerability scanning and policy engine for Windows containers called the Scanning Inspector. It can be used on both Windows and Linux hosts.

                              This is a standalone scanning engine. There is no centralized UI, management, or historical data. These features are planned for a future release.

                              Features

                              • Identify Windows container image vulnerabilities from:

                                • Windows OS CVEs
                              • Windows or Linux hosts

                              • Reports in JSON and PDF

                              • Policy support

                                • Severity

                                • Fix available

                                • Days since fixed

                              Ways to Use

                              The Windows Scanning Inspector can be integrated into the CI/CD pipeline or deployed ad hoc during development.

                              CI/CD Pipeline

                              The image below shows how the Scanning Inspector fits within a development pipeline. A policy can pass or fail the workflow and provide a PDF or JSON report for each CI/CD job.

                              Ad Hoc Scanning

                              Developers can run the Windows Scanning Inspector anywhere Docker can be run: a machine (Mac, Windows, or Linux), VM, or Cloud. It provides immediate feedback on Windows OS or .NET vulnerabilities, allowing quick mitigation of known security vulnerabilities.

                              Installation

                              Prerequisites

                              Request a Quay secret from your Sysdig sales agent.

                              Install Scanning Inspector

                              1. Use the provided secret to authenticate with Quay:

                                PULL_SECRET="enter secret"
                                AUTH=$(echo $PULL_SECRET | base64 --decode | jq -r '.auths."quay.io".auth'| base64 --decode)
                                QUAY_USERNAME=${AUTH%:*}
                                QUAY_PASSWORD=${AUTH#*:}
                                docker login -u "$QUAY_USERNAME" -p "$QUAY_PASSWORD" quay.io
                                
                              2. Pull the Scanning Inspector component for Windows or Linux:

                                • Window Host/Kernel: quay.io/sysdig/scanning-inspector-windows:latest

                                • Linux Host/Kernel: :quay.io/sysdig/scanning-inspector-linux:latest

                              3. Run the --help command to see the parameters available for the Scanning Inspector.

                                docker run --rm -v $(pwd):/outdir quay.io/sysdig/scanning-inspector-linux:latest --help
                                

                              Parameters for Scanning Inspector

                              The --help command lists the available parameters and their usage. They can be divided into those related to scanning for vulnerabilities and generating a report, and those related to creating policies.

                              FlagDescriptionRequiredArgumentType
                              -f stringoutput formatyespdf or jsonVuln scan
                              -i or -image_identifier stringidentifier of the imageyes[my_image:my_tag]Vuln scan
                              -image_type stringimage typeyestar, daemon, pullVuln scan
                              -o string or -output string output file pathyesVuln scan
                              -output_format string output formatyespdf or jsonVuln scan
                              -fix_availablepolicy check for fixnoPolicy creation
                              -min_days_fix intMinimum number of days once a fix for the specific vulnerability is availablenodefault -1Policy Creation
                              -min_severity stringMinimum severity to fail for policy evaluationnoPolicy creation
                              t-stringThe image typeyestar, daemon, pull

                              Use Cases

                              Scan Remote Image and Save PDF Report

                              In this example, the Inspector should scan a remote image on a Linux host and save the resulting report as a PDF to ./scanResults.pdf

                              docker run --rm -v $(pwd):/outdir quay.io/sysdig/scanning-inspector-linux:latest \
                                -t pull \ # pull image from remote repo
                                -i mcr.microsoft.com/windows/nanoserver:10.0.17763.1518 \ # inspect container name
                                -f pdf \ # format
                                -o /outdir/scanResults.pdf # output name
                              

                              Scan Local Image Apply Policy Conditions and Generate JSON Report

                              In this example, the Inspector should:

                              • Scan a local image on a Windows host

                              • Mount the Docker socket to access the local image. This can be done with -v "//./pipe/docker_engine://./pipe/docker_engine" in Windows

                              • Apply a policy to specify vulnerabilities with a minimum severity of high and a minimum number of days after the vulnerability fix is available set to 7.

                              • If the scan does not pass, the container will have an exit 1 error.

                              • The report is in JSON

                              docker run --rm -v $(pwd):/outdir -v "//./pipe/docker_engine://./pipe/docker_engine" quay.io/sysdig/scanning-inspector-windows:latest \
                                -t daemon \ # Use local daemon for image scan
                                -i nanoserver:10.0.17763.1518 # local image name
                                -min_severity high # Any sev high or greater CVEs will fail the image scan policy
                                -min_days_fix 7 # Only fail scan if found vulnerabilities have a fix for more than 7 days
                                -f json \ # format
                                -o /outdir/scanResults.json # output name