Installation

The FTSnext setup consists of three agents that must be deployed.

Templates

For each agent, we provide an archive with all the necessary files and directories to run it using Docker Compose.

Clinical Domain Agent	Trust Center Agent	Research Domain Agent
cd-agent.tar.gz Checksum · Provenance	tc-agent.tar.gz Checksum · Provenance	rd-agent.tar.gz Checksum · Provenance

For example use wget and tar to download and unpack the agent template:

CD Agent

wget https://github.com/medizininformatik-initiative/fts-next/releases/download/v5.2.0/cd-agent.tar.gz
tar -xvf cd-agent.tar.gz

TC Agent

wget https://github.com/medizininformatik-initiative/fts-next/releases/download/v5.2.0/tc-agent.tar.gz
tar -xvf tc-agent.tar.gz

RD Agent

wget https://github.com/medizininformatik-initiative/fts-next/releases/download/v5.2.0/rd-agent.tar.gz
tar -xvf rd-agent.tar.gz

It will provide the following directory structure:

CD Agent

cd-agent/
├── application.yaml       # server-related configurations, such as SSL, file paths, etc.
├── compose.yaml           # container image reference, network settings, healthcheck
└── projects/              # project configuration directory
    ├── example.yaml       # example project configuration  
    └── example/           # other files needed for the example project to function
        └── deidentifhir/  # deidentifhir configuration used in the example project

TC Agent

tc-agent/
├── application.yaml       # server-related configurations, such as SSL, file paths, etc.
└── compose.yaml           # container image reference, network settings, healthcheck



# Trust Center Agent has no projects

RD Agent

rd-agent/
├── application.yaml       # server-related configurations, such as SSL, file paths, etc.
└── compose.yaml           # container image reference, network settings, healthcheck
└── projects/              # project configuration directory
    ├── example.yaml       # example project configuration  
    └── example/           # other files needed for the example project to function
        └── deidentifhir/  # deidentifhir configuration used in the example project

Verification Since 5.3

To ensure trust and security in the software supply chain, verification of release artifacts confirms that the downloaded files are authentic, unaltered, and originate from the intended source. This process helps to protect users from tampered or malicious builds by using cryptographic proofs of provenance. Each release uses SLSA and cosign to generate provenance metadata for both release archives and container images. These artifacts are signed during the build process, enabling independent verification of their origin and integrity.

For container images, we use cosign also to sign images and attach SBOMs, stored alongside the image in the container registry. This allows users to confirm the image was built by the expected CI pipeline and has not been modified after publication.

Release archives include SLSA provenance files that can be verified using the slsa-verifier tool. Together, these mechanisms provide a robust foundation for validating downloaded components.

Release Archives

Each agent archive is accompanied by a provenance file in SLSA format, which verifies the authenticity and integrity of the downloaded files. The slsa-verifier tool checks that the artifact was built from the correct source and tag. ¹

CD Agent

wget https://github.com/medizininformatik-initiative/fts-next/releases/download/v5.2.0/cd-agent.tar.gz.intoto.jsonl
slsa-verifier verify-artifact cd-agent.tar.gz \
  --source-uri github.com/medizininformatik-initiative/fts-next \
  --source-tag v5.2.0 \
  --provenance-path cd-agent.tar.gz.intoto.jsonl

TC Agent

wget https://github.com/medizininformatik-initiative/fts-next/releases/download/v5.2.0/tc-agent.tar.gz.intoto.jsonl
slsa-verifier verify-artifact tc-agent.tar.gz \
  --source-uri github.com/medizininformatik-initiative/fts-next \
  --source-tag v5.2.0 \
  --provenance-path tc-agent.tar.gz.intoto.jsonl

RD Agent

wget https://github.com/medizininformatik-initiative/fts-next/releases/download/v5.2.0/rd-agent.tar.gz.intoto.jsonl
slsa-verifier verify-artifact rd-agent.tar.gz \
  --source-uri github.com/medizininformatik-initiative/fts-next \
  --source-tag v5.2.0 \
  --provenance-path rd-agent.tar.gz.intoto.jsonl

If the verification passes the output should contain confirmation that the artifact is valid and matches the signed provenance:

PASSED: SLSA verification passed

---

1. Please see official slsa-verifier installation instructions

Container Images

Each release archive includes a verify.sh utility script for verifying the provenance of the container images used in the corresponding compose files, by running ./verify.sh. Use ./verify.sh v5.2.0, if the image versions in the docker compose file have been updated since first installation. The verify script uses slsa-verifier and cosign to check whether the image was built by the FTSnext GitHub actions.

Example output:

$ ./verify.sh v5.2.0
# Verifying image provenance, assert image was built 
- from github.com/medizininformatik-initiative/fts-next 
- for tag v5.2.0
* Using slsa-verifier ✔ 
* Using cosign ✔