SCM, CI/ CD and Container Registry tokens

Why are these tokens required?

Our scanner performs checks against your SCM, CI/ CD systems and container registries to recover information about your repository and organization, as part of the scanning process to validate if there are misconfigurations affecting them.

For image scanning, authentication with the container registry for pulling the image may require credentials, often in the form of access tokens.

For that, it is important to provide tokens with the permissions allowing the scanner to collect the data needed for analyses.

Providing the token

Navigate to your scanner folder and look at the file conf/xygeni.yml. Under the scm, cicd and containerRegistry elements you are going to discover the currently available systems and how to provide their tokens to the scanner. This is done in entries under tokenSources. Each token source is tested until a valid token is found. Token sources could be an environment variable, a local file, or a hardcoded value (not recommended).

Usually, the preferred option it to pass the token in an environment variable (like GITHUB_TOKEN or GITLAB_TOKEN).

# List of different Source Code Management (SCM) systems
# supporting projects for the organization
scm:
  # One of: github, azure_devops, bitbucket, gitlab.
  -
    kind: github
    # Which projects are held in this SCM?
    # Use a regex pattern, like 'project1|project2|project3' or 'prefix_.*'
    # Leave empty for matching any project for the given scm kind)
    usedBy: ''
    # The (optional) default username to connect to the SCM API.
    # If not given it could be extracted from the repository URL, when available.
    user: null
    # How the access token should be fetched:
    # From environment/system property (env:),
    # From file (use ${scanned.dir} for scanned directory, ${XYGENI_DIR} for scanner directory, ${user.home} for $HOME),
    # or encode directly (use encryption to protect the token against casual readers)
    tokenSources:
      - env:GITHUB_TOKEN
      - env:GITHUB_PAT
      - file:${user.home}/.github.token
      - file:${XYGENI_DIR}/conf/.github.token
  -
    kind: azure_devops
    # Which projects are held in this SCM?
    # Use a regex pattern, like 'project1|project2|project3' or 'prefix_.*'
    # Leave empty for matching any project for the given scm kind)
    usedBy: ''
    # The (optional) default username to connect to the SCM API.
    # If not given it could be extracted from the repository URL, when available.
    user: null
    # How the access token should be fetched:
    # From environment/system property (env:),
    # From file (use ${scanned.dir} for scanned directory, ${XYGENI_DIR} for scanner directory, ${user.home} for $HOME),
    # or encode directly (use encryption to protect the token against casual readers)
    tokenSources:
      - env:AZURE_TOKEN
      - env:AZURE_PAT
      - file:${user.home}/.azure.token
      - file:${XYGENI_DIR}/conf/.azure.token
  -
    kind: bitbucket
    # Which projects are held in this SCM?
    # Use a regex pattern, like 'project1|project2|project3' or 'prefix_.*'
    # Leave empty for matching any project for the given scm kind)
    usedBy: ''
    # The (optional) default username to connect to the SCM API.
    # If not given it could be extracted from the repository URL, when available.
    user: null
    # How the access token should be fetched:
    # From environment/system property (env:),
    # From file (use ${scanned.dir} for scanned directory, ${XYGENI_DIR} for scanner directory, ${user.home} for $HOME),
    # or encode directly (use encryption to protect the token against casual readers)
    tokenSources:
      - env:BITBUCKET_TOKEN
      - env:BITBUCKET_PAT
      - file:${user.home}/.bitbucket.token
      - file:${XYGENI_DIR}/conf/.bitbucket.token
  -
    kind: gitlab
    # Which projects are held in this SCM?
    # Use a regex pattern, like 'project1|project2|project3' or 'prefix_.*'
    # Leave empty for matching any project for the given scm kind)
    usedBy: ''
    # The (optional) default username to connect to the SCM API.
    # If not given it could be extracted from the repository URL, when available.
    user: null
    # How the access token should be fetched:
    # From environment/system property (env:),
    # From file (use ${scanned.dir} for scanned directory, ${XYGENI_DIR} for scanner directory, ${user.home} for $HOME),
    # or encode directly (use encryption to protect the token against casual readers)
    tokenSources:
      - env:GITLAB_TOKEN
      - env:GITLAB_PAT
      - file:${user.home}/.gitlab.token
      - file:${XYGENI_DIR}/conf/.gitlab.token

# CI/CD tools used, if you not configure this, the system will assume that the SCM is used as CI/CD tool.
cicd:
  -
    kind: jenkins
    # Jenkins base URL
    url: ''
    # Which projects use this CI/CD system?
    # Use a regex pattern, like 'project1|project2|project3' or 'prefix_.*'
    # Leave empty for matching any project for the given jenkins kind
    usedBy: ''
    # The username to connect to the CI/CD API.
    user: null
    # How the access token should be fetched:
    # From environment/system property (env:),
    # From file (use ${scanned.dir} for scanned directory, ${XYGENI_DIR} for scanner directory, ${user.home} for $HOME),
    # or encode directly (use encryption to protect the token against casual readers)
    tokenSources:
      - env:JENKINS_TOKEN
      - file:${user.home}/.jenkins.token
      - file:${XYGENI_DIR}/conf/.jenkins.token
  -
    kind: circle_ci
    # CircleCI base URL
    url: 'https://circleci.com/api/'
    tokenSources:
      - env:CIRCLECI_TOKEN
      - file:${user.home}/.circleci.token
      - file:${XYGENI_DIR}/conf/.circleci.token

# Container (OCI) Registries
containerRegistry:
  -
    # Docker Hub
    # The hostname to match in the image name. This is the default when no hostname provided.
    hostname: docker.io
    # Docker registry official URL
    url: 'https://registry-1.docker.io'
    # Which projects use this registry? A hostname is often given in the image name.
    # Use a regex pattern, like 'project1|project2|project3' or 'prefix_.*'
    # Leave empty for matching by hostname.
    usedBy: ''
    # The username to connect to the registry api.
    user: null
    # How the access token should be fetched:
    # From environment/system property (env:),
    # From file (use ${scanned.dir} for scanned directory, ${XYGENI_DIR} for scanner directory, ${user.home} for $HOME),
    # or encode directly (use encryption to protect the token against casual readers)
    tokenSources:
      - env:DOCKER_TOKEN
      - file:${user.home}/.docker.token
  #... Additional popular registries follow ...

Required token permissions

For Azure Devops, these are the required token permissions/ scopes:

  • Build: Read

  • Code: Read, Status

  • Graph: Read

  • Identity: Read

  • Packaging: Read

  • Project and Team: Read

  • Release: Read

  • Security: Manage

See Creating a PAT if you have doubts about setting up a Personal Access Token.

See Create a token with repository-scoped permissions for further information about permissions for pulling images under a repository, if you need to scan private images pushed into Azure CR registry.

For Bitbucket, these are the required token permissions/ scopes:

  • Account: Read

  • Pipelines: Read

  • Projects: Read

  • Pull Requests: Read

  • Repositories: Admin

  • Runners: Read

  • Webhooks: Read and Write

  • Workspace membership: Read

See Using Workspace Access Tokens and App Passwords if you have doubts about setting up a Bitbucket token.

For GitHub, these are the required token permissions/ scopes:

  • enterprise: read

  • org: admin

  • packages: read

  • project: read

  • repo: full

  • repo_hook: read

  • user: read

See Creating a GH PAT if you have doubts about setting up a Personal Access Token.

For GitLab, these are the required token permissions/ scopes:

  • api

  • read_api

  • read_user

  • read_repository

  • read_registry

See Creating a GitLab PAT if you have doubts about setting up a Personal Access Token.

Last updated