fortifydocker/fcli repository overview

⁠Fortify CLI (fcli) Docker images

This repository provides Docker images for fcli⁠, allowing to easily run fcli commands without having to install fcli locally.

⁠Image variants

For now, we provide the following image variants:

• Scratch image containing fcli only; no shell or other tools
• UBI9-based image with fcli only; full UBI9 environment including shell
• UBI9-based image with fcli and ScanCentral Client; full UBI9 environment including shell

The UBI9-based images may provide a better user experience as they allow for running a sequence of fcli commands in an image-provided shell, storing any state across those commands within the container. For example, through the UBI9-provided shell, you can run fcli session login commands, then use those sessions in subsequent commands, followed by the appropriate session logout commands.

In comparison, as the scratch image only allows for executing a single fcli command per container invocation, you'll need to use a persistent volume to store fcli state between those invocations. However, the scratch image is much smaller and more secure as it doesn't include any potentially vulnerable packages from a base image.

⁠Important Note

These images do not include any build tools, and are therefore not suitable for for packaging source code through ScanCentral Client for languages that require build tool integration. If the scancentral package command is being run within containers created from this image (for example through fcli ci or package actions or direct ScanCentral Client invocation), the -bt none option must be passed to avoid errors due to missing build tools. Depending on source code language, using -bt none may produce inaccurate scan results.

If you do require packaging capabilities with build tool integration, there are two options:

• Use a fortifydocker/fcli (non-scratch) image as the base image for a custom image, adding any build tools to your custom image as required for your project(s)
• Use your standard build tool image as the base image for a custom image, adding fcli and optionally other Fortify tools like ScanCentral Client to your custom image

⁠Image tags

Image tags identify the fcli version they contain. For example, 3.14.1 contains fcli v3.14.1. Semantic version tags are also provided: 3 points to the latest v3.<minor>.<patch> release, and 3.14 points to the latest v3.14.<patch> release. The latest tag points to the latest stable fcli release.

By default, image tags target Linux x64 (linux/amd64). UBI9 and UBI9+ScanCentral Client images also have separate Linux arm64 variants, using the same tag pattern with an -arm64 suffix, when the fcli release provides an arm64 binary. Scratch images are available for Linux x64 only.

UBI9-based images use a -ubi9 suffix. UBI9 images with ScanCentral Client use a -ubi9-sc<version> suffix. The ScanCentral Client version is in YY.Q form, and the image includes the latest available patch release in that quarter when the image is built. ScanCentral Client variants do not have a latest tag.

Examples:

• 3: Scratch image containing the latest fcli v3.<minor>.<patch> release
• 3.14.1: Scratch image containing fcli v3.14.1
• latest-ubi9: UBI9 image containing the latest stable fcli release
• 3-ubi9: UBI9 image containing the latest fcli v3.<minor>.<patch> release
• 3-ubi9-arm64: Linux arm64 UBI9 image containing the latest fcli v3.<minor>.<patch> release available for arm64
• 3.14-ubi9: UBI9 image containing the latest fcli v3.14.<patch> release
• 3-ubi9-sc25.4: UBI9 image containing the latest fcli v3.<minor>.<patch> release built with ScanCentral Client 25.4.<patch>
• 3.16-ubi9-sc25.2: UBI9 image containing the latest fcli v3.16.<patch> release built with ScanCentral Client 25.2.<patch>
• 3.30.0-ubi9-sc26.2-arm64: Linux arm64 UBI9 image containing fcli v3.30.0 and ScanCentral Client 26.2.<patch>

Note that 'latest' above refers to the latest version that was available at the time the image was published. For example, if a new ScanCentral Client patch release is published after the image was last published, the image will contain the earlier patch release until the image is refreshed as described above.

Image tags as described above may be refreshed at any time, for example to utilize a newer base image version, update fcli or ScanCentral Client versions to latest version that matches the semantic version tag, or implement Dockerfile improvements and fixes. For users that require absolute stability, we also provide timestamped image tags; these are guaranteed to never change (other than deletion of images over 2 years old). Some examples:

• 3.14.1-20251219151716: Scratch image containing the fcli v3.14.1 release, published at 2025-12-19 15:17:16
• fcli:3.14.1-ubi9-20251219151716: Same as above, but UBI9-based image

As these timestamped images are meant to provide stability, there are no timestamped semantic version tags like latest-<timestamp> or 3.14-<timestamp>.

Which tag to use depends on your requirements:

• Use of latest is discouraged
• Use 3 or 3-ubi9 if you want to automatically benefit from new fcli features and bug fixes, Dockerfile improvements, and base image updates
• Use 3.<minor> or 3.<minor>-ubi9 if you need a stable set of fcli features, while benefiting from fcli bug fixes, Dockerfile improvements, and base image updates
• Use 3.<minor>.<patch> or 3.<minor>.<patch>-ubi9 if you want a stable fcli version, while still benefiting from Dockerfile improvements and base image updates
• Use 3.<minor>.<patch>-<timestamp> or 3.<minor>.<patch>-ubi9-<timestamp> if you require absolute stability with an image that will never change

Note that this repository only contains images for fcli production releases; images for development releases have moved to https://hub.docker.com/r/fortifydocker/fcli-dev⁠.

For backward compatibility, there are also some gitlab-installer-svc images. These are deprecated and should no longer be used; existing tags may be removed during a future clean-up.

⁠Usage - UBI9

Easiest way to use the UBI9-based image is by running a sequence of fcli commands through the UBI9-provided shell, for example:

docker run --rm -it fortifydocker/fcli:<version>-ubi9
  fcli ssc session login ...
  fcli ssc av ls
  fcli ssc session logout
  exit

The above will run the given fcli commands in the image-provided shell, storing any state like fcli session data in the current container; any state will be lost once the container exits. For image variants that include ScanCentral Client, the scancentral command can be invoked in a similar way.

If you require persistence or access to files on your host system, you may pass volume mappings, fcli environment variables, etcetera on the docker run command. Usage information for the scratch image below provides some pointers; most of these options apply to the UBI9-based image as well.

⁠Usage - scratch

To have the fcli Docker image behave virtually the same as a locally installed fcli, you can use the following command:

docker run --rm -v "${HOME}:${HOME}" -v "${PWD}:${PWD}" -e "FCLI_USER_HOME=${HOME}" -w "${PWD}" -u $(id -u):$(id -g) fortifydocker/fcli:<tag> <fcli-args>

Of course, being a relatively long command, you may want to set up an alias, shell function or wrapper script for invoking the Docker command.

Explanation of the various elements in the command above:

• --rm:
  • Automatically remove container after the fcli command has completed.
• -v "${HOME}:${HOME}" and -v "${PWD}:${PWD}":
  • Mount local user home and current working directories to similarly named directories inside the container.
  • This allows the containerized fcli to read and write files in both home and current working directories on the host system, for example for storing fcli state data, reading/writing files to be up/downloaded from/to the current working directory, ...
  • If ${HOME} and ${PWD} are the same, this would result in having two equal -v options, however Docker seems to accept this without issues.
• -e "FCLI_USER_HOME=${HOME}"
  • Set the fcli user home directory to the home directory on the host system, as mounted through the corresponding -v option.
  • This will make fcli store state & configuration data into the ${HOME}/.fortify directory on the host system, and have fcli tool commands install tools into the ${HOME}/fortify directory on the host system.
• -w "${PWD}"
  • Sets the fcli working directory to the current working on the host system, as mounted through the corresponding -v option.
  • This will allow fcli to access any files to be uploaded/downloaded/generated into the current host system working directory.
• -u $(id -u):$(id -g)
  • Run the container/fcli as the current host system user.
  • If this option is not specified, the container/fcli would be executed with UID 10001, which likely doesn't exist on the host system and wouldn't have read/write access to directories mounted through the -v option.
• <tag>
  • Image tag corresponding to the fcli version that you want to run; see 'Image tags' section above.
• <fcli-args>
  • Any arguments to be passed to the fcli executable, like fod app ls
  • For convenience and compatibility with the UBI9 image and potential future image variants, you may include the fcli command itself in <fcli-args>, so both fod app ls and fcli fod app ls will be accepted as <fcli-args>.

Of course, many variations of this command are possible. For example:

• If you'd like to have a dedicated home directory for fcli rather than current user home, you can replace all references to ${HOME} with an alternative directory like ${HOME}/fcli-docker.
• You may wish to add additional -v options if you'd like the containerized fcli to have access to additional host system directories. As an example, to have the containerized fcli install ScanCentral Client to /opt/fortify on the host system (assuming current user has write access to those directories), you could:
  • Add -v /opt/fortify:/opt/fortify Docker option
  • Add --base-dir /opt/fortify option on the fcli tool sc-client install command (or use corresponding environment variable like FCLI_TOOL_BASE_DIR)