Operating inside a container¶

The Docker image is the recommended way to run ts-sast. Every release is published as trustsource/ts-sast, tagged with the version and latest. Because the DevSkim backend is a .NET tool, the image bundles the .NET runtime, a pinned DevSkim, Python and ts-sast; nothing has to be installed on the host, and every machine and CI runner scans with the same versions. DevSkim is installed in a builder stage on the .NET SDK and copied into a runtime-only image, which keeps the image at roughly half a gigabyte.

Scan a local checkout¶

Mount the sources into /workspace, the image's working directory, and pass paths relative to it:

docker run --rm -v "$(pwd)":/workspace trustsource/ts-sast scan -o /workspace/findings.sarif src

Without -o the result is printed to standard output. The text format is convenient for a quick look:

docker run --rm -v "$(pwd)":/workspace trustsource/ts-sast scan -f text src

CI gate¶

docker run --rm -v "$(pwd)":/workspace trustsource/ts-sast scan \
  --fail-on-findings --devskim:forward --severity,critical,important \
  -o /workspace/findings.sarif src

The container exits with code 1 when a critical or important finding exists, and the SARIF file is available for upload regardless.

Configuration in a container¶

The config file is looked up at ~/.ts-sast/config inside the container, which is empty on every run. Either mount a config file

docker run --rm -v "$(pwd)":/workspace -v "$HOME/.ts-sast:/root/.ts-sast" trustsource/ts-sast scan src

or use environment variables with the TS_SAST_ prefix:

docker run --rm -e TS_SAST_SCAN_FORMAT=text -v "$(pwd)":/workspace trustsource/ts-sast scan src

Build the image yourself¶

docker build -t ts-sast .

The DevSkim version is pinned in the Dockerfile (DEVSKIM_VERSION); override it with --build-arg DEVSKIM_VERSION=.... The CI workflow builds and pushes the image whenever a version tag is pushed.