XrayScan

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"

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 `buildName`and `buildNumber`of the input BuildInfo resource.	Optional

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.Creating Xray Policies and Rules Default is `true`.	Optional

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.Creating Xray Policies and Rules

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

onExecute, onStart, onSuccess, onFailure, 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.

This example require a GitHub Integration and an Artifactory Integration.GitHub Integration
The Pipelines DSL for this example is available in t his repository in the JFrog GitHub account.

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)