Scanning (Legacy)
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:
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:
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
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.
Upgrading
You can rerun this Docker command to upgrade to the latest inline scanning component at any time.
Common Parameters
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
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.
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.
Example: Mounting External Malware Database (Recommended)
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.
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
Deploy: Deploy Sysdig Secure for cloud on
AWS and choose the
ECR Image Registry Scanning option.
Insights becomes
your default landing page in Sysdig Secure.
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
From the Image Scanning module, select Registry Credentials and
click Add Registry.
The New Registry page is displayed.
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.
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:
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
Service Principal
Username: The service principal app id
Password: The service principal password
Google Container Registry:
JSON Key
(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.
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).
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 :
E.g. quay.io/sysdig/agent:0.89
Click Save.
Edit a Registry
From the Image Scanning module, select Registry Credentials.
Select an existing registry to open the Edit window.
Update the parameters as necessary and click Save.
The registry Type cannot be edited.
Delete a Registry
From the Image Scanning module, select Registry Credentials.
Select the existing registry to open the Edit window.
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:
From the Scanning module, choose the Runtime tab.
Sort by Unscanned and select an image from the list of unscanned
images.
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
From the Scanning module, choose the Image Results tab.
Click Scan Image.
Define the path to the image, and click Scan.
4 - Manage Scanning Policies
Image scanning policies define several scenarios, such as:
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.
Sysdig provides a number of Default (read-only) baseline policies that can be used as-is or as
templates on which to build.
DefaultPolicy
This policy covers the most common image scanning cases, such as:
checking for high vulnerabilities that have a fix available
checking Dockerfile best practices (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.
Dockerfile Best Practices
This policy provides out-of-the-box rules around Dockerfile best
practices,
such as disallowing:
The remaining preconfigured default policies deal with compliance rules such as NIST 800, PCI, GDPR, HIPAA, ISO 270001:2013 and SCO2
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
You can’t edit a Default Policy - instead use the Duplicate Policy function and then customize it.
Create a Scanning Policy
From the Image Scanning module, select Scanning Policies and
click Add Policy(+).
The New Policy page is displayed.
Define a Name and an optional Description for the new policy.
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.
Optional: Repeat step 5 to add rules as necessary.
Click Save.
Edit a Policy
From the Image Scanning module, select Scanning Policies.
Select the desired policy from the list.
Edit the policy rules as required, and click Save Policy.
Delete a Policy
From the Image Scanning module, select Scanning Policies.
Select the desired policy from the list.
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
From the Image Scanning module, select Scanning Policies and
choose +Policy Assignments.
The previously defined assignments are listed in priority order.
Click +Add Policy Assignment.
A new entry line appears at the top of the Assignment page. Enter
the desired assignment details:
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.
Registry: Any registry domain (e.g. quay.io). Wildcards
are supported; an asterisk * specifies any registry.
Repository: Any repository (typically = name of the image).
Wildcards are supported; an asterisk * specifies any
repository.
Tag: Any tag. Wildcards are supported; an asterisk *
specifies any tag.
Assigned Policy: Name of policy to use for evaluation.
Select from the drop-down menu.
Click Save.
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 DefaultPolicy.
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:
Select Image Scanning > Vulnerability Exceptions and click the
Add button on the left side of the screen.
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.
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
SelectImage Scanning > Vulnerability Exceptions and choose the
desired list from the left menu. (In this example, the Exception
list is named “Python exceptions”.)
Click the Add button on the right side of the screen.
Enter the identifying details:
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:
Select Image Scanning > Scan Results.
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.
Click the hover button to open the “Add Exception” dialog .
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:
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:
From the Image Scanning module, select either
Global - Trusted Images or Global - Untrusted Images.
The list of previously added images is displayed.
Click the Add Image button.
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:
From the Image Scanning module, choose the Scan Results tab.
Select the relevant repository from the list and open the relevant
image.
Click Add to List at the top of the page.
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.
effective_user
This trigger reviews whether the effective user matches the user
provided, and will fire based on the configured type.
| Parameter | Description | Example |
|---|
type | Determines whether the user should be whitelisted or blacklisted. | N/A |
user | The 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.
| Parameter | Description | Example |
|---|
actual_dockerfile_only | Defines whether the evaluation should skip inferred or guessed Dockerfiles, and only evaluate user-provided Dockerfiles. The default value is false. | true |
ports | A comma-separated list of port numbers. | 80,8080,8088 |
type | Defines 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.
| Parameter | Description | Example |
|---|
actual_dockerfile_only | Defines whether the evaluation should skip inferred or guessed dockerfiles, and only evaluate user-provided dockerfiles. The default value is false. | true |
check | The type of check to perform. | = |
instruction | The dockerfile instruction to check. | FROM |
value | The 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.
| Parameter | Description | Example |
|---|
regex_name | The 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.
| Parameter | Description | Example |
|---|
regex | The 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.
| Parameter | Description | Example |
|---|
licenses | A 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.
| Parameter | Description | Example |
|---|
licenses | A comma-separated list of strings to blacklist for licenses. | LGPL,BSD |
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.
| Parameter | Description | Example |
|---|
attribute | The attribute name to check. | size |
check | The operation to perform for the evaluation. | > |
value | The 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.
| Parameter | Description | Example |
|---|
name | The name of blacklisted package/s. | openssh-server |
version | The 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.
| Parameter | Description | Example |
|---|
name | The name of the required package. | libssl |
version | The required package version. | 1.10.3rc3 |
version_match_type | Defines 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.
| Parameter | Description | Example |
|---|
check | Defines whether the check should focus on missing packages, changed packages, or all. | changed |
only_directories | Defines the list of directories the check should be limited to. | /usr,/var/lib |
only_packages | Defines 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.
| Parameter | Description | Example |
|---|
entry | The 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.
| Parameter | Description | Example |
|---|
group_ids | A 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.
| Parameter | Description | Example |
|---|
shells | The 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.
| Parameter | Description | Example |
|---|
user_ids | The 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.
| Parameter | Description | Example |
|---|
user_names | A 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.
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:
| Parameter | Description | Example |
|---|
fix_available | If present, the fix availability for the vulnerability record must match the value of the parameter. | true |
package_type | The specific type of package. | all |
severity | The vulnerability severity. | high |
severity_comparison | The type of comparison to perform for the security evaluation. | > |
vendor_only | If 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.
| Parameter | Description | Example |
|---|
max_days_since_sync | Determines 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:
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=
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.
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"
}
]
}
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"
}
]
}
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"
}
]
}
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
To create a new alert: From the Image Scanning module, choose the
Alerts tab and click Add Alert.
Select either Runtime or Repository alert type.
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
From the Image Scanning module, choose the Alerts tab.
Select the desired alert from the list.
Edit the alert trigger, scope, and notification channels as
necessary, and click Save.
Duplicate an Alert
From the Image Scanning module, choose the Alerts tab.
Select the desired alert from the list.
Click the More (three dots) icon and click Duplicate Alert from
the drop-down, then Yes to confirm.
Delete an Alert
From the Image Scanning module, choose the Alerts tab.
Select the desired alert from the list.
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:
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.
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 Severity | Red Hat Severity | Red Hat Definition |
|---|
| Critical | Critical | This 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. |
| High | Important | This 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. |
| Medium | Moderate | This 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. |
| Low | Low | This 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. |
| Negligible | n/a | n/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.
Select an image from a line in the Scan Results list.
From the Compare To drop-down, select another version of this
image with which to compare.
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
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.)
Image Scanning Reports has moved from a synchronous model to an asynchronous mode, in which you schedule the reports you need and then receive them through notification channels.
Only email, Slack, and webhook notification channels are supported at this time.
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:
Create Report Definition
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.)
From the Reports list page, click Add Report.
Define the Report Configuration and Data as described below.
Optionally, Preview the selected Data.
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:
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://<Sysdig-SaaS-URL>/api/reporting/v1/scanning/reports/1q8gX9ErBwpDdNZKDbYm5Zzzyyxxx -o report.zip
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:
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, 22.10
RedHat Enterprise Linux 7, 8
Debian 8, 9, 10
Amazon Linux 2
Unsupported OSs:
Access Host Scanning
Follow the steps for the Node Analyzer: Multi-Feature
Installation.
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.
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.
Select Scanning > Hosts.
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:
Navigate to the Settings menu in the Sysdig Secure UI.
Select Feeds Status.
10 - Admission Controller
Features
Kubernetes’ Admission Controllers (AC) 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.
Installing this component will enable the following:
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.)
AC Image Scanning - Usage Steps
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 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.
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.
Click +Policy and enter a meaningful Name and Description.
Define the policy Rules:
Evaluation Failure: Whether to reject images that are failing
scanning policy
evaluation.
Images matching a policy assignment without scan results will also be rejected.
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).
- Click
Save.
Understanding: 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 Controller Policies
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.
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.
Namespace: Leave blank to match any namespace, or add a
regular expression to match the namespace
ex.:
| field | value matches |
|---|
dev | any namespace containing ‘dev’ |
^dev | any namespace starting with ‘dev’ |
^dev$ | a namespace with the exact name ‘dev’ |
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.
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.
- Click
Save.
Saved changes are pulled from the Admission Controller every 5 minutes
- 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:
Given following assignments:
The policies that apply would be the following
kube-system namespace, container with image path docker.io/myimage -> will apply Policy1mynamespace namespace, container with image path quay.io/myimage -> will apply Policy2mynamespace namespace, container with image path docker.io/myimage -> will apply default policy Rejected
Enable/Disable Image Scanning
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:
Log in as Administrator to Sysdig Secure and select
Image Scanning> Admission Controller|Policy Assignment.
Select the relevant cluster from the left side menu.
Slide the Admission Controller to Enabled.
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.
AC Kubernetes Logging - Usage Steps
When Installing the
Admission Controller, ensure value features.k8sAuditDetections is set to true (default value)
Create policies of
the Kubernetes Audit Policy type.
Check the Events UI
for entries.
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
11 - 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
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
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
Pull the Scanning Inspector component for Windows or Linux:
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.
| Flag | Description | Required | Argument | Type |
|---|
-f string | output format | yes | pdf or json | Vuln scan |
-i or -image_identifier string | identifier of the image | yes | [my_image:my_tag] | Vuln scan |
-image_type string | image type | yes | tar, daemon, pull | Vuln scan |
-o string or -output string | output file path | yes | | Vuln scan |
-output_format string | output format | yes | pdf or json | Vuln scan |
-fix_available | policy check for fix | no | | Policy creation |
-min_days_fix int | Minimum number of days once a fix for the specific vulnerability is available | no | default -1 | Policy Creation |
-min_severity string | Minimum severity to fail for policy evaluation | no | | Policy creation |
t-string | The image type | yes | tar, 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
12 - Which Scanning Engine to Use
As of April 20, 2022, Sysdig offers both a Legacy Scanner engine and the newer Vulnerability Management engine.
Which Engine is Enabled Now?
If you have a top level menu entry labeled Scanning, then you are using the [Legacy] Scanning engine, and the relevant documentation is located here.
Instead, if the top level menu entry is labeled Vulnerabilities, then you are using the New Vulnerability Management engine, and the relevant documentation is located here.
You can also enable both engines at the same time, if you need to take advantage of some legacy features (see below)
In general:
- New Users who installed Sysdig Secure for the first time after April 19, 2022 will be using Vulnerability Management by default
- Earlier Users who installed prior versions of Sysdig Secure will be using the Legacy Scanning engine and will need to enable the new Vulnerability Management to use it.
How to Enable/Disable the Two Engines (UI)
Log in to Sysdig Secure as admin and choose Settings > User Profile.
Scroll down to the Sysdig Labs section to toggle on/off the New Vulnerabilities engine and/or the Legacy Scanning engine (with or without the legacy Admission Controller and Scheduled Reports).
New Users (first install after April 19, 2022) must contact their Sysdig representative to have the legacy Labs toggles enabled in their Settings UI.
Safe and transparent:
- The toggles only alter the user interface and in no way impact the function or running of the engine itself.
- It is also safe to run the two engines side-by-side, (below)
How to Enable/Disable the Two Engines (Backend)
The engine backends are enabled via options in the Data Sources page, under Install the Agent and Scan an Image.
