XrayScan

JFrog Pipelines Documentation

ft:sourceType
Paligo

The XrayScan native step triggers a JFrog Xray scan for security vulnerabilities and license compliance. If there was a watch created that covers the selected build, Xray will scan the indexed build artifacts.

YAML Schema

The YAML schema for XrayScan native step is as follows:

XrayScan

pipelines:
  - name:   <string>
    steps:
      - name: scan
        type: XrayScan
        configuration:
          #inherits all the tags from bash
          failOnScan:       <boolean>                      # default true
          inputResources:
            - name:         <BuildInfo resource>           # required
              trigger: false
                  outputResources:
            - name:         <BuildInfo resource>           # optional

        execution:
          onStart:
            - echo "Preparing for work..."
            - echo "Prepping build environment"
          onSuccess:
            - echo "Job well done!"
          onFailure:
            - echo "uh oh, something went wrong"
          onComplete: #always
            - echo "Cleaning up some stuff"
Tags
name

An alphanumeric string (underscores are permitted) that identifies the step.

type

Must be XrayScan for this step type.

configuration

Specifies all configuration selections for the step's execution environment. This step inherits the Bash/ PowerShell step configuration tags, including these pertinent tags:

Tag

Description of usage

Required/Optional

inputResources

Must specify a BuildInforesource . The buildName and buildNumber are used to trigger the scan.

Required

outputResources

May specify a BuildInforesource. The BuildInfo will be updated with the buildNameand buildNumberof the input BuildInfo resource.

Optional

In addition, these tags can be defined to support the step's native operation:

Tags derived from Bash

All native steps derive from the Bash step. This means that all steps share the same base set of tags from Bash, while native steps have their own additional tags as well that support the step's particular function. So it's important to be familiar with the Bash step definition, since it's the core of the definition of all other steps.

Tag

Description of usage

Required/Optional

failOnScan

When set to true, and when the Xray Policy Rule Fail Build checkbox is checked, a failed Xray scan will result in a failure of the step.

Default is true.

Optional

execution

Declares collections of shell command sequences to perform for pre- and post-execution phases:

Tag

Description of usage

Required/Optional

onStart

Commands to execute in advance of the native operation

Optional

onSuccess

Commands to execute on successful completion

Optional

onFailure

Commands to execute on failed completion

Optional

onComplete

Commands to execute on any completion

Optional

The actions performed for the onExecute phase are inherent to this step type and may not be overridden.

Note

onExecuteonStartonSuccessonFailure, and onComplete are reserved keywords. Using these keywords in any other context in your execution scripts can cause unexpected behavior.

Examples

The following examples show how to configure a XrayScan step.

Trigger an Xray Scan for Build Name and Number

Triggers an Xray scan for the build name and number provided by an input BuildInfo resource.

XrayScan

template: true   # required for local templates
valuesFilePath: ./values.yml

resources:
  - name: app_repo
    type: GitRepo
    configuration:
      gitProvider: {{ .Values.gitIntegration }}                      
      path: {{ .Values.gitRepositoryPath }}    
      branches:
        include: master

  - name: app_buildinfo
    type: BuildInfo
    configuration:
      sourceArtifactory: {{ .Values.artifactoryIntegration }}

  - name: app_promoted_buildinfo
    type: BuildInfo
    configuration:
      sourceArtifactory: {{ .Values.artifactoryIntegration }}

pipelines:
  - name: app_dev_pipeline
    steps:
      - name: app_build
        type: DockerBuild
        configuration:
          affinityGroup: docker_group
          dockerFileLocation: .
          dockerFileName: Dockerfile
          dockerImageName: {{ .Values.artifactoryUrl }}/{{ .Values.sourceRepository }}/{{ .Values.imageName }}  
          dockerImageTag: ${run_number}
          inputResources:
            - name: app_repo
          integrations:
            - name: {{ .Values.artifactoryIntegration }}         
            
      - name: app_push
        type: DockerPush
        configuration:
          affinityGroup: docker_group
          targetRepository: {{ .Values.sourceRepository }}
          integrations:
            - name: {{ .Values.artifactoryIntegration }}                            
          inputSteps:
            - name: app_build

      - name: publish_app_build
        type: PublishBuildInfo
        configuration:
          affinityGroup: docker_group
          inputSteps:
            - name: app_push
          outputResources:
            - name: app_buildinfo
            
      - name: xrayScanStep
        type: XrayScan
        configuration:
          inputResources:
            - name: app_buildinfo 
Update Output BuildInfo Resource

Updates an output BuildInfo resource that can be used as an input to future steps. Using an output resource means that you can be sure that those versions have been scanned when using that resource as an input.

XrayScan

pipelines: 
  - name: xrayScanPipeline
    steps:
      - name: xrayScanStep
        type: XrayScan
        configuration:
          inputResources:
            - name: inputBuildInfo
          outputResources:
            - name: outputBuildInfo
How it Works

When you use the XrayScan native step in a pipeline, it performs the following functions in the background:

  • jfrog rt config (if there is a BuildInfo output, configure the JFrog CLI with the credentials of the input BuildInfo resource)

  • jfrog rt use (specify the configured credentials to use)

  • jfrog rt build-scan (trigger a scan)

  • replicate_resource (if there is an output BuildInfo, copy the properties of the input BuildInfo resource to the output)

  • write_output (if there is an output BuildInfo, update the output BuildInfo resource buildName and buildNumber)