Integration with CI/CD

Kaspersky Container Security lets you scan images of containers and IaC residing in code repository management systems in the

At the project build stage in the repository management system, you can run the Kaspersky Container Security scanner to check the objects in the repository for compliance with the enabled security policies. The scanner is started from a registry using an agent, such as GitLab Runner in GitLab. Data on the scan job and sending scan results are forwarded through the application programming interface (API).

When running an object scan during the project build stage, you must make sure that the Fail CI/CD step is not selected in the settings of the applied assurance policy. If this setting is activated, the solution will notify you of an error during the scan.

The scan results are displayed in the list of images in the Inventory → CI/CD → Scanning in CI/CD section.

For each of the objects in the table, Kaspersky Container Security displays the following:

• Date and time of the last scan.
• Name.
• Risk rating.
• Summary scan results with an indication of the identified objects related to vulnerabilities, malware, sensitive data and misconfigurations.
• Artifact type.
• The number and pipeline of the build in which the image was scanned.

In the section Resources → CI/CD → Scanning in CI/CD section, you can also generate a report on images that are scanned within the CI/CD process.

Reports are generated only for objects with the Image artifact type. In this section, a report cannot be generated for other types of artifacts.

Image scanning in CI/CD processes

Kaspersky Container Security allows you to scan images that are used in CI/CD. To scan images from CI/CD, you should configure the integration of Kaspersky Container Security with CI/CD processes.

Data from listening to and intercepting network traffic must be securely transferred between the CI/CD environment and the solution.

To scan images or repositories (in order to scan configuration files) used in the CI/CD process, add a stage to the CI/CD pipeline that runs the Kaspersky Container Security scanner.

To scan images from CI/CD, in the configuration file used to integrate the repository, specify the API_BASE_URL (web-address of the Kaspersky Container Security API server) and API_TOKEN (token to access API of the Kaspersky Container Security) environment variables for the scanner. You must also specify API_CA_CERT (certificate for verifying host server of the API solution) or SKIP_API_SERVER_VALIDATION = true to skip this scan.

The scanning results are forwarded to the server and displayed in the Management Console in the Resources → CI/CD section. The provided table lists the images that were scanned, shows the results of the risk assessment, and indicates the detected vulnerabilities.

You can click the image name link to open a page with detailed information about image scanning results. This page is similar to the page showing the results of registry images scanning.

Kaspersky Container Security also displays the type of artifact for each object. Two main artifacts are used:

• File system is repository containing configuration files.
• Container image is template used for runtime implementation of the container.

For each scan object, you can specify the build number (BUILD_NUMBER) and the build

For CI/CD images, rescanning is not provided.

Kaspersky Container Security performs the following types of scans in CI/CD:

• Scanning images from the image registry. The solution runs a scan after a successful build and saves the image into the image registry.
• Scanning of images in TAR archives. A TAR archive is stored as a build artifact that the solution scans in the next build pipeline.
• Scanning a Git repository, which can be performed in one of the following ways:
  • for a project branch (individual development path) in the Git repository
  • for a commit (state snapshot or checkpoint in the project's timeline)

To scan an image from an image registry:

Start the scan by running a command in the following format:

/scanner [TARGET] --stdout

where:

• <TARGET>—full address of the image in the registry;
• <--stdout> is the output to the security event log.

To access the registry, enter in the environment variables the login COMPANY_EXT_REGISTRY_USERNAME password (token) COMPANY_EXT_REGISTRY_PASSWORD.

Examples of scanning images in GitLab CI/CD and Jenkins CI/CD.

To scan an image from a TAR archive:

1. Build an image and save it as a TAR archive using any application for creating containerized images.
2. Start the scan by running a command in the following format:

   /scanner [TARGET] --file --stdout

   where:

   • <TARGET>—path to the file with the image to be scanned
   • <--file>—flag indicating scanning of the TARGET file
   • <--stdout> is the output to the security event log.

   Example of a configuration file with settings for scanning a TAR archive

   stages:

   - build_tar

   - scan_tar

   - push_image

   build_tar:

   stage: build_tar

   tags:

   - k8s

   - docker

   image:

   name: gcr.io/kaniko-project/executor:v1.9.0-debug

   entrypoint: [""]

   dependencies:

   - scan_source_branch

   - scan_source_commit

   script:

   - mkdir -p /kaniko/.docker

   - echo "${DOCKER_AUTH_CONFIG}" > /kaniko/.docker/config.json

   - /kaniko/executor

   --context "${CI_PROJECT_DIR}"

   --dockerfile "${CI_PROJECT_DIR}/Dockerfile"

   --destination "${CI_REGISTRY_IMAGE}:${CI_COMMIT_REF_NAME}"

   --compressed-caching=false

   --build-arg GITLAB_USER=gitlab-ci-token

   --build-arg GITLAB_TOKEN=${CI_JOB_TOKEN}

   --no-push

   --tarPath=image.tar

   artifacts:

   paths:

   - image.tar

   expire_in: 2 hours

   scan_tar:

   stage: scan_tar

   tags:

   - k8s

   - docker

   dependencies:

   - build_tar

   image:

   name: "company.gitlab.cloud.net:5050/companydev/example/scanner:master-with-db"

   pull_policy: always

   entrypoint: [""]

   variables:

   API_BASE_URL: ${API_BASE_URL}

   API_TOKEN: ${API_TOKEN}

   API_CA_CERT: ${KCS_CA_CERT}

   script:

   - /scanner image.tar --file --stdout

   artifacts:

   paths:

   - image.tar

   expire_in: 2 hours

   push_image:

   stage: push_image

   tags:

   - k8s

   image:

   name: gcr.io/go-containerregistry/crane:debug

   entrypoint: [""]

   dependencies:

   - scan_tar

   script:

   - mkdir -p $HOME/.docker

   - echo "${DOCKER_AUTH_CONFIG}" > $HOME/.docker/config.json

   - /ko-app/crane push image.tar "${CI_REGISTRY_IMAGE}:${CI_COMMIT_REF_NAME}"

To scan the Git repository:

1. In the configuration file of the Git repository, in the environment variables specify the token to access the repository (GITHUB_TOKEN or GITLAB_TOKEN).
2. Start the scan by running a command in the following format:

   /scanner [TARGET] --repo [--branch BRANCH] [--commit COMMIT] --stdout

   where:

   • <TARGET>—web address (URL) of the Git repository
   • <--repo> —flag indicating scanning of the TARGET file
   • <--branch BRANCH>—branch of the repository to be scanned
   • <--commit COMMIT>—hash of the commit to be scanned
   • <--stdout> is the output to the security event log.

   Example of a configuration file with environment variables for scanning an image from a Git repository

   stages:

   - scan_source_branch

   - scan_source_commit

   scan_source_branch:

   stage: scan_source_branch

   image:

   name: "company.gitlab.cloud.net:5050/companydev/example/scanner:master-with-db"

   pull_policy: always

   entrypoint: [""]

   tags:

   - k8s

   - docker

   variables:

   API_BASE_URL: ${API_BASE_URL}

   API_TOKEN: ${API_TOKEN}

   API_CA_CERT: ${KCS_CA_CERT}

   script:

   - GITLAB_TOKEN=${CI_JOB_TOKEN} /scanner --repo ${CI_REPOSITORY_URL} --branch ${CI_COMMIT_BRANCH} --stdout

   scan_source_commit:

   stage: scan_source_commit

   image:

   name: "company.gitlab.cloud.net:5050/companydev/example/scanner:master-with-db"

   pull_policy: always

   entrypoint: [""]

   tags:

   - k8s

   - docker

   variables:

   API_BASE_URL: ${API_BASE_URL}

   API_TOKEN: ${API_TOKEN}

   API_CA_CERT: ${KCS_CA_CERT}

   script:

   - GITLAB_TOKEN=${CI_JOB_TOKEN} /scanner --repo ${CI_REPOSITORY_URL} --commit ${CI_COMMIT_SHA} --stdout

Scan results can be viewed in Resources → CI/CD, or downloaded in the .SPDX, .JSON, and .HTML formats.

Configuring integration with GitLab CI/CD

This example uses a specific scanner image with the built-in vulnerability databases located in the image registry of the Kaspersky Container Security manufacturer.

To use the image scanning feature in the GitLab CI/CD process, you should enable the use of the GitLab Container Registry.

Integration configuration includes the following steps:

1. Authorization of GitLab CI/CD in the image registry of the Kaspersky Container Security manufacturer.
   1. On the cluster operator's workstation, prepare a Base64 hash of the authorization data by running the following command:

      printf "login:password" | openssl base64 -A

      where login and password are the user name and password of an account in the image registry of the Kaspersky Container Security manufacturer.

   2. In the GitLab CI/CD environment variables, create the DOCKER_AUTH_CONFIG variable (in the GitLab repository select Settings → CI/CD, click the Expand button to expand Variables, and then click the Add variable button).
   3. Specify the variable in the following form:

      {

      "auths": {

      "repo.cloud.example.com": {

      "auth": "base64hash"

      }

      }

      }

      where base64hash is the string obtained in step 1a.

2. Authorization of requests from GitLab CI/CD when sending data to Kaspersky Container Security.
   1. Copy the API token on the My profile page.
   2. Specify the copied API token value in the API_TOKEN variable in the .gitlab-ci.yml configuration file.
3. Adding the image scanning stage to the CI/CD process.

   To add scanning to the CI/CD pipeline, you should add the following lines to the .gitlab-ci.yml file:

   1. Add information about the scanner image that contains databases of vulnerabilities and other malicious objects after the code build stage in the following form:

      scan_image:

      stage: scanner

      image:

      name: repo.cloud.example.com/repository/company/scanner:v1.2-with-db

      entrypoint: [""]

      pull_policy: always

      We recommend that you specify always for the pull_policy parameter to receive relevant builds with updated databases of vulnerabilities and other malicious objects for each scan.

   2. Specify the tag, build ID, pipeline ID and API token for authorization of the CI/CD scanner requests to Kaspersky Container Security as follows:

      SCAN_TARGET: ${CI_REGISTRY_IMAGE}:master

      BUILD_NUMBER: ${CI_JOB_ID}

      BUILD_PIPELINE: ${CI_PIPELINE_ID}

      API_TOKEN: <API token value>

      The example here contains the master tag, you can also specify another tag.

   3. If you configure scanning for a private repository, specify the authorization data to ensure the scanner can access an image. The authorization data can be set as variables.

      COMPANY_EXT_REGISTRY_USERNAME: ${COMPANY_EXT_REGISTRY_USERNAME}

      COMPANY_EXT_REGISTRY_PASSWORD: ${COMPANY_EXT_REGISTRY_PASSWORD}

   4. If necessary, specify a variable to check the data receiving server in CI/CD using the CA certificate of the Ingress controller:

      API_CA_CERT: ${KCS_CA_CERT}

      The CA certificate of the Ingress controller is specified in the text field as a string in the .PEM format:

      ----- BEGIN CERTIFICATE ----- \ n... <certificate details> ...\ n ----- END CERTIFICATE -----

      If the API_CA_CERT variable is not set, scanning will start but will not be completed.

      Use of the CA certificate of the Ingress controller allows the scanner running in CI/CD to verify the authenticity of the data receiving server.

      If you use a self-signed certificate, or want to skip checking the data receiving server using the CA certificate of the Ingress controller, specify the value of the variable to skip the check as follows:

      SKIP_API_SERVER_VALIDATION: 'true'

   5. Specify the web address of the API host server for Kaspersky Container Security:

      API_BASE_URL: <web address>

      variables:

      API_BASE_URL: ${API_BASE_URL}

      script:

      - /bin/sh /entrypoint.sh $SCAN_TARGET --stdout > artifact-result.json

      artifacts:

      paths:

      - artifact-result.json

After configuring integration with an external registry, you can scan images within the CI/CD process, including scanning in SBOM mode. Scan results can be viewed in Resources → CI/CD, or downloaded in the .SPDX, .JSON, and .HTML formats.

Configuring integration with Jenkins CI/CD

Configuring integration with Jenkins CI / CD consists of the following steps:

1. Authorization of Jenkins CI/CD in the image registry of the Kaspersky Container Security manufacturer. To do so, on the cluster operator's workstation, prepare a Base64 hash of the authorization data by running the following command:

   printf "login:password" | openssl base64 -A

   where login and password are the user name and password of an account in the image registry of the Kaspersky Container Security manufacturer.

2. Authorization of Kaspersky Container Security API. To perform authorization, complete the following steps:
   1. Copy the API token on the My profile page.
   2. Specify the copied API token value in the API_TOKEN variable in the Jenkinsfile configuration file.
3. Authentication of the data receipt server in CI/CD using the CA certificate of the Ingress controller. To perform authentication, in the Jenkinsfile configuration file, specify one of the following variables:
   1. -e API_CA_CERT=${KCS_CA_CERT} means the authentication is performed, and the scanner started in CI/CD can make sure the receiving server is authentic.
   2. -e SKIP_API_SERVER_VALIDATION=true means authentication of the receiving server using the CA certificate of the Ingress controller is not performed.
4. Creating Jenkins environment variables.

   To create environment variables, add the following lines to Jenkinsfile:

   1. Add information about the container registry where the scanner is located as follows:

      LOGIN: the name of the account in the scanner registry

      PASS: the password for the scanner registry

   2. If you configure scanning for a private repository, specify the following authorization data to ensure the scanner access to an image:

      COMPANY_EXT_REGISTRY_USERNAME: the name of the account in the registry of the scanned image

      COMPANY_EXT_REGISTRY_PASSWORD: the password for the registry of the image being scanned

5. Adding information to start the scanner. Information for starting the scanner that contains databases of vulnerabilities and other malicious objects is added to the Jenkinsfile configuration file in the form of a declarative or scripted pipeline.

   Example of information for starting the scanner in the form of a declarative pipeline

   pipeline {

   agent any

   stages {

   stage('run scanner') {

   steps {

   sh 'docker login -u ${LOGIN} -p ${PASS} company.example.com'

   sh 'docker run -e API_BASE_URL=https://kcs.cust02.int.example.com/ -e SKIP_API_SERVER_VALIDATION=true -e API_TOKEN=${API_TOKEN} -e COMPANY_EXT_REGISTRY_USERNAME=${COMPANY_EXT_REGISTRY_USERNAME} -e COMPANY_EXT_REGISTRY_PASSWORD=${COMPANY_EXT_REGISTRY_PASSWORD} company.example.com:5050/company/kcs/scanner:v1.2.0-with-db jfrog.company.com/demo-kcs/bad:bad-project-test --html --stdout > result.html'

   }

   }

   }

   }

   Example of data for starting a scanner in the form of a scripted pipeline

   node {

   stage ('run scanner') {

   sh 'docker login -u ${LOGIN} -p ${PASS} company.example.com'

   sh 'docker run -e API_BASE_URL=https://kcs.cust02.int.company.com/ -e API_CA_CERT=${KCS_CA_CERT} -e API_TOKEN=${API_TOKEN} -e COMPANY_EXT_REGISTRY_USERNAME=${COMPANY_EXT_REGISTRY_USERNAME} -e COMPANY_EXT_REGISTRY_PASSWORD=${COMPANY_EXT_REGISTRY_PASSWORD} company.example.com:5050/company/kcs/scanner:v1.2.0-with-db jfrog.company.com/demo-kcs/bad:bad-project-test --html --stdout > result.html'

   }

   }

6. Generating an artifact for downloading.

   You can generate an artifact for downloading in the .HTML, or .JSON format to receive the scan results. You can specify an artifact format in --stout as follows:

   pipeline {

   agent any

   stages {

   stage('run scanner') {

   steps {

   sh 'docker login -u ${LOGIN} -p ${PASS} company.example.com'

   sh 'docker run -e API_BASE_URL=https://kcs.int.company.com -e SKIP_API_SERVER_VALIDATION=true -e API_TOKEN=${API_TOKEN} -e COMPANY_EXT_REGISTRY_USERNAME=${COMPANY_EXT_REGISTRY_USERNAME} -e COMPANY_EXT_REGISTRY_PASSWORD=${COMPANY_EXT_REGISTRY_PASSWORD} company.example.com:5050/company/kcs/scanner:v1.2.1-lite jfrog.company.com/demo-kcs/bad:bad-project-test --html --stdout > result.html'

   }

   }

   stage('archive') {

   steps {

   archiveArtifacts artifacts: 'result.html'

   }

   }

   }

   }

   To generate a .JSON artifact, rewrite the --html --stdout> result.html' line in the example above as follows:

   --json --stdout > result.json',

   and in the archiveArtifacts artifacts line, specify the file name in the defined format: 'result.json'.

   Scan results can be obtained in the format you specified and can also be viewed in the Resources → CI/CD section.

Configuring integration with TeamCity CI/CD

To configure integration with TeamCity CI/CD:

1. Copy the API token on the My profile page to authorize the Kaspersky Container Security API in TeamCity.
2. In the settings menu in the TeamCity web interface, select Build Configuration Home → Parameters.
3. Click Add new parameters to add the values of the following environment variables:
   • API_TOKEN— specify the copied value of the Kaspersky Container Security API token.
   • API_BASE_URL — specify the URL of Kaspersky Container Security.
   • RUST_BACKTRACE — If necessary, specify full to use backtracing.
   • SKIP_API_SERVER_VALIDATION — specify true if you are using a self-signed certificate or if you need to skip authentication of the receiving server using the CA certificate of the Ingress controller.
4. Go to the Build Configuration Home → Build Step: Command Line section and click Add build step to add a build step.
5. In the window that opens, specify the following settings of the build step:
   • In the Runner type drop-down list, select Command Line.
   • In the Run drop-down list, select Custom script.
   • In the Custom script field, specify the path to the container for scanning (for example, /bin/sh /entrypoint.sh nginx:latest).
6. Under Docker Settings, specify the following settings:
   • In the Run step within Docker container field, specify the address of the scanner in the Docker registry. For example, company.gitlab.cloud.net:5050/companydev/example/scanner:v1.2.0-with-db.
   • In the Additional docker run arguments field, increase the privilege value to --privileged.
7. Click Save to save the settings.
8. Click Run in the upper-right corner of the page to start the build.
9. If necessary, download the scan results artifact, which is available on the Artifacts tab on the build scan results page in the TeamCity web interface.

Page top

Defining the path to container images

To start scanning, the solution needs to determine the path to the container images that need to be scanned. The path to container images can be specified in two ways:

• By specifying an image tag after the registry name, repository name, and image name. The tag is a changeable and easy-to-read description of the image.

  In this case, the path looks as follows: <registry>/<repository>/<image name>:<tag>. For example, http://docker.io/library/nginx:1.20.1.

• By specifying an image digest after the registry name, repository, and image name. A digest is an integral internal property of an image, specifically a hash of its contents (the SHA256 hash algorithm is used).

  When using a digest, the path is formed as follows: <registry>/<repository>/<image name><digest>. For example, http://docker.io/library/nginx@sha256:af9c...69ce.

A tag can match different digests, whereas digests are unique for each image.

Depending on the method used to specify the image path, Kaspersky Container Security performs one of the following actions before scanning:

• Converts the tag to a trusted digest.
• Checks whether the digest specified in the image path is trusted. A digest is considered trusted if it ensures the required degree of confidence in maintaining the desired protection relative to the object encoded using the hash algorithm.

Only trusted digests are sent to the container runtime.

Before running a container, the content of the image is compared with the received digest. To recognize a digest as trusted and the image as not corrupted, Kaspersky Container Security checks the integrity and authenticity of the image signature.

Page top

Monitoring the integrity and origin of images

When scanning images in CI/CD, Kaspersky Container Security protects against image spoofing at the registry level. The integrity and origin of images of containers deployed in an orchestrator cluster is controlled by verifying image signatures, starting at the build stage in CI.

Image integrity is monitored in two stages:

• Container images are signed after they are created. This process is implemented using external signature applications.
• Image signatures are checked before images are deployed.

  The solution saves a signature key, which is based on the SHA256 hash function and used as the code for signature validation. When deployed in an orchestrator, Kaspersky Container Security asks the signature server to confirm the authenticity of the signature.

Kaspersky Container Security checks image signatures as follows:

1. In the Administration → Integrations → Image signature validators section, you can configure the settings for integrating the solution with external image signature validation applications.
2. In the Policies → Runtime → Policies section, a runtime policy is added to protect the content of the image. This runtime policy validates the authenticity of signatures. Digital signatures are validated based on the configured image signature validators.
3. The orchestrator starts image deployment and uses a
   dynamic admission controller

   A configurable controller to access Kubernetes that helps enforce policies and supports the management and control system.

   to make a deployment request to the agent (kube-agent).

   To send the request to the Kaspersky Container Security agent, configure the dynamic admission controller in the values.yaml configuration file.

4. Based on the applicable runtime policy, the agent checks the signature validation settings configured in the Administration → Integrations → Image signature validators section.
5. If the check confirms the authenticity and validity of the signature, the solution allows image deployment. Otherwise, deployment is blocked.

Running the scanner in SBOM mode

Kaspersky Container Security allows you to start a scanner to check images for vulnerabilities in

The advantages of using SBOM are the following:

• Less resources required to scan images for vulnerabilities.
• Reduced scanning time due to automatic verification of correct operation and proper use of solution components.
• Capability to scan all existing vulnerabilities in an image without exceptions.
• High reliability of scanning results.

In CI/CD, the scanning process consists of two stages: receiving an SBOM file and scanning an image based on the received SBOM file. The image scanning process is implemented as follows:

• The CI/CD scanner generates a list of image components and sends the generated artifact to Kaspersky Container Security.
• Using the image handler, the solution forwards the received SBOM file to the scanner for scanning.

For subsequent scanning, Kaspersky Container Security generates an SBOM file in the

To generate an SBOM file in the .SPDX format when the scanner operates with SBOM creation:

Enter the following command in the .gitlab-ci.yml configuration file:

- /bin/sh /entrypoint.sh $SCAN_TARGET --sbom-json --spdx --stdout > example.spdx

where:

<--sbom-json> indicates the creation of an SBOM file.

<--spdx> indicates that an artifact is generated in the .SPDX format.

<--stdout > example.spdx> indicates data output to a file in the .SPDX format.

To generate an SBOM file in the .JSON format when the scanner operates with SBOM creation:

Enter the following command in the .gitlab-ci.yml configuration file:

- /bin/sh /entrypoint.sh $SCAN_TARGET --sbom-json --stdout > example.json

where:

<--sbom-json> indicates the creation of an SBOM file.

<--stdout > example.json> indicates data output to a file in .JSON format.

The resulting file (for example, example.json) is specified as an artifact: artifacts: paths:

Scanning using an SBOM file is only applicable when scanning an image for vulnerabilities. If your CI/CD process requires scanning for other risks and threats (such as misconfigurations), you must separately run the corresponding scanning and add its results to the image handler in addition to the SBOM file.

Getting scan results in JSON or HTML format

When using Kaspersky Container Security to scan images in CI/CD, you can generate and save an artifact with the scan results within your CI/CD platform. This can be done using a configuration file of the external repository system that is integrated with the solution. For example, you can use a .gitlab-ci.yml configuration file in GitLab.

You can generate an artifact containing scan results in the following scenarios:

• When the scanner conducts a complete CI/CD scan - scanning results file can be generated in the .HTML format or the .JSON format.
• When the scanner operates with SBOM creation - file containing scanning results can be generated in the .SPDX format or the .JSON format.

To generate a scan results file in .HTML format:

Enter the following command in the .gitlab-ci.yml configuration file:

- /bin/sh /entrypoint.sh $SCAN_TARGET --html --stdout > example.html

where:

<--html> indicates that an artifact is generated in .HTML format.

<--stdout > example.html> indicates data output to a file in .HTML format.

To generate a scan results file in .JSON format when performing a complete CI/CD scan:

Enter the following command in the .gitlab-ci.yml configuration file:

- /bin/sh /entrypoint.sh $SCAN_TARGET --stdout > example.json

where:

<--stdout > example.json> indicates data output to a file in .JSON format.

The resulting file (for example, example.json) is specified as an artifact: artifacts: paths:

Page top

Running the scanner in lite SBOM mode

Kaspersky Container Security allows you to start a scanner to check images for vulnerabilities in the lite SBOM mode. In this case, the solution scans a specially created SBOM file, and the results of this scan become available at the CI/CD stage.

Data from listening to and intercepting network traffic must be securely transferred between the CI/CD environment and the solution.

You can generate an artifact for download in the .SPDX, .HTML, or .JSON format to receive the results.

Running a scanner in GitLab

To start the scanner in lite SBOM mode in GitLab, when configuring image scanning in CI/CD process, edit the .gitlab-ci.yml configuration file as follows:

1. Add information about the image of the scanner that is started for image scanning in CI/CD as follows:

   scan_image:

   stage: scanner

   image:

   name:repo.cloud.example.com/repository/company/scanner:v.1.2-lite

   entrypoint: [""]

   pull_policy: always

2. Specify the orchestration platform tag as follows:

   k8s

   In the example provided, the k8s tag is specified for Kubernetes, you can also specify the tag for another supported orchestration platform.

3. Specify such variables as the build ID, private repository details, pipeline ID and API token for authorization of the CI/CD scanner requests to Kaspersky Container Security as follows:

   SCAN_TARGET: ${CI_REGISTRY_IMAGE}:master

   COMPANY_EXT_REGISTRY_USERNAME: ${COMPANY_EXT_REGISTRY_USERNAME}

   COMPANY_EXT_REGISTRY_PASSWORD: ${COMPANY_EXT_REGISTRY_PASSWORD}

   BUILD_NUMBER: ${CI_JOB_ID}

   BUILD_PIPELINE: ${CI_PIPELINE_ID}

   API_TOKEN: <API token value>

4. If necessary, specify a variable to check the data receiving server in CI/CD using the CA certificate of the Ingress controller:

   API_CA_CERT: ${KCS_CA_CERT}

   If the API_CA_CERT variable is not set, scanning will start but will not be completed.

5. Specify the web address of the API host server for Kaspersky Container Security:

   API_BASE_URL: <web address>

6. Specify the command to create an SBOM file when the scanner is started in one of the following supported formats:
   • To generate an artifact in the .JSON format:

     script:

     - /bin/sh /entrypoint.sh $SCAN_TARGET --stdout > artifact-result.json

     artifacts:

     paths:

     - artifact-result.json

   • To generate an artifact in the .HTML format:

     script:

     - /bin/sh /entrypoint.sh $SCAN_TARGET --html --stdout > artifact-result.html

     artifacts:

     paths:

     - artifact-result.html

   • To generate an artifact in the .SPDX format:

     script:

     - /bin/sh /entrypoint.sh $SCAN_TARGET --spdx --stdout > artifact-result.spdx

     artifacts:

     paths:

     - artifact-result.spdx

Example of the scanner configured to operate in the lite SBOM mode and the artifact generation in the .HTML format in GitLab

Running a scanner in Docker

To start the scanner in lite SBOM mode in Docker:

1. Specify the web address of the API host server for Kaspersky Container Security:

   -e API_BASE_URL=https://company.local

2. Specify the value of the variable to skip checking the data receiving server using the CA certificate of the Ingress controller:

   -e SKIP_API_SERVER_VALIDATION=true

3. Specify the API token for authorization of the CI/CD scanner requests to Kaspersky Container Security as follows:

   -e API_TOKEN=<API token value>

4. Specify data to start the scanner:

   repo.kcs.company.com/images/scanner:v1.2-lite

5. If you need to generate an artifact for downloading in the .SPDX, .HTML, or .JSON format, specify the following:

   - <artifact format> --stdout> result. <file format>

   For example:

   --html --stdout > result.html

6. Press the Enter key to start the scanner.

   If a domain name resolution error - Name does not resolve - appears when calling the scanner, you must specify the address before the API_BASE_URL variable before the internal DNS server of your organization. For example:

   --dns 10.0.xx.x

   API_BASE_URL: https://company.local/

Example of the scanner configured to operate in the lite SBOM mode and the artifact generation in the .JSON format in Docker

Scan results can be obtained in the format you specified and can also be viewed in the Resources → CI/CD section.