Security

Reporting a vulnerability

Write to security@ict-baden.de. Please do not open a public issue on GitHub. Every product repository also has a SECURITY.md with the confidential reporting channel on GitHub (“Report a vulnerability”).

What a good report contains

• Product and version (shown in the application’s About window and in the release name)
• Operating system and version; for Vitrine also the sign-in method
• Steps to reproduce, as brief as possible
• The impact as you see it
• Log excerpts if needed – without tenant or client IDs, account names or real log files

What to expect

Acknowledgement

within three business days

Assessment

within ten business days, with a first severity rating

Fix

as soon as possible, depending on severity

Disclosure

coordinated: the fix first, then the advisory

We follow coordinated disclosure. The guideline is 90 days from the report; if a fix takes longer, we agree the date with you. Fixed vulnerabilities are published as a GitHub Security Advisory in the repository concerned, and we credit you there as the finder if you wish. There is no bounty programme.

If you prefer encrypted communication, first write to us unencrypted without details; we then agree a channel (S/MIME or PGP). This information is also available in machine-readable form under RFC 9116 at /.well-known/security.txt.

Security fixes are provided for the latest released version of a product; customers with a support contract also receive them for the previous major version, until twelve months after its successor appears. Customers with a support contract receive security information in advance by email.

How a release is built

The source code of all products is public at github.com/ict-baden, under the MIT licence. Every version is built in GitHub Actions from the repository’s Git tag; the workflow file is in the repository and the log of every run can be inspected. Nobody builds releases on a workstation.

• Tag releases (v1.2.3) are the versions for production. GitHub marks them as “Latest” and the file names carry the version.
• The rolling “latest” release is a pre-release: the newest state of the main branch, for testing. For production use the newest tag release.
• Tests run in every build, before packaging: unit tests for all products, plus Android Lint for the Android apps. For Vitrine the MSI is additionally installed, updated and uninstalled on a fresh Windows runner in GitHub Actions; if that fails, no release is created. Tests on real devices are still outstanding for all products (see “Limits” on the product pages).

The bill of materials (SBOM) in CycloneDX format lists every library in the package with its version and licence. It can be loaded into common tools for vulnerability and licence checks. Industrial Keyboard does not have one yet; we are adding it.

Dependencies are updated by Dependabot: weekly for libraries (NuGet for the Windows products, Gradle for the Android apps), monthly for the GitHub Actions used. Version jumps that would change a library’s licence – such as a move from MIT to AGPL – are excluded in the configuration and are not applied automatically.

Security advisories are published as a GitHub Security Advisory in the affected repository and referenced on this page. No security advisory has been published so far. Customers with a support contract are informed by email before an advisory becomes public.

Signing of the downloads

Windows: Vitrine, Lupe, Zutritt, Riegel

The Windows packages are currently not code-signed. Windows SmartScreen warns the first time an EXE or MSI is started; for Lupe, macOS Gatekeeper asks once. A code signing certificate for ICT Baden has been applied for; signing through a signing service is already prepared in the build workflows and takes effect as soon as the certificate is available. Until then, verify the files with the checksums:

• Windows (PowerShell): Get-FileHash .\Vitrine-x64.msi -Algorithm SHA256 and compare the value with the line in SHA256SUMS.txt
• Linux and macOS: sha256sum -c --ignore-missing SHA256SUMS.txt in the download folder

The checksums are produced in the same build as the files. They prove that a download reached you unchanged – not who built it. Only code signing closes that gap. For this reason Riegel’s documentation explicitly advises against pilots on OT or validated machines before signing; until then its collector is allow-listed by hash.

Android: Industrial Keyboard, Industrial Kiosk Browser

APK and App Bundle are signed in the build with the ICT Baden release key; the key is stored as a secret in GitHub Actions and the build verifies the signature after packaging. Without the key, the build publishes no APK. Industrial Keyboard has been signed this way since version 2.0.0 (October 2026). Industrial Kiosk Browser received a new package name with version 0.7.0; the current builds under this name are signed, and Android treats them as a new app compared with the old packages.

What the software does not do

All six products document in their repository (docs/data-and-privacy.md) what they store where and which connections they make. They have in common:

• No data to ICT Baden. No telemetry, no crash reports, no usage statistics, no update check. Vitrine and Zutritt show this sentence in their About window.
• No cloud requirement, no licence server, no ICT Baden account. The software is MIT-licensed; there are no licence keys. Lupe, Riegel and Industrial Keyboard contain no network code at all; Industrial Keyboard does not even hold Android’s internet permission, and Riegel enforces this with a test against the source code.
• Connections only to what you configure: Vitrine to Microsoft sign-in if you set up Entra ID; Zutritt to the file servers and domain controllers it analyses; Industrial Kiosk Browser to the web applications you enter – the Android System WebView checks addresses with Google Safe Browsing as usual, see the product page.
• The data stays with you. Logs, signatures, analyses and reports are kept on your systems. You are the controller under the GDPR; ICT Baden processes none of it through the software.

The privacy notices the apps link to are on this website (German pages, each with an English section): Vitrine, Lupe, Zutritt, Riegel, Industrial Kiosk Browser, Industrial Keyboard.

NIS2, GxP and the operator’s role

NIS2

Our products are tools that you use as the operator; in your supply chain ICT Baden is the manufacturer. We do not claim that a product is “NIS2 compliant” – that is not a property of software but of your operation. What we provide for it:

• the complete source code and the bill of materials (SBOM) per release, for your supply chain assessment
• checksums for every download and, once the certificate is available, code signatures
• a fixed reporting channel, coordinated disclosure and advisories as GitHub Security Advisories
• security fixes for the latest version; dependencies are updated continuously
• documentation of what the software stores, connects to and deliberately does not do (docs/data-and-privacy.md, docs/limitations.md in every repository)

What remains with you: risk assessment and approval, distribution and patch management, configuration and hardening of the systems, monitoring in operation, and reporting incidents to your authorities.

Pharma and GxP: Part 11 and Annex 11

ICT Baden does not claim for any product that its use meets 21 CFR Part 11, EU GMP Annex 11 or any other regulation. Vitrine provides building blocks that GxP workstations ask for – access control, unique identification, a tamper-evident audit trail and electronic signatures with a meaning; details in the GxP section of the Vitrine page. Documents for your own qualification (specification, risk assessment, test protocols) are produced by effort, see services billed by effort on the support page. Validation and risk assessment are the operator’s responsibility; code and log format are kept simple so that a validation is feasible.

This website

The website is static: no server-side logic, no database, no forms. It sets no cookies, embeds no third-party content (fonts and scripts are served from our own server) and uses no tracking. What the web server logs is described in the privacy policy.

The server sends these security headers with every response:

Content-Security-Policy

default-src 'none'; scripts, stylesheets, images, fonts, media and connections only from our own server; frame-ancestors 'none', base-uri 'none', form-action 'none', object-src 'none'

Strict-Transport-Security

max-age=31536000 (one year, without includeSubDomains, without preload)

X-Content-Type-Options

nosniff

X-Frame-Options

DENY

Referrer-Policy

strict-origin-when-cross-origin

Permissions-Policy

camera, microphone, geolocation, motion sensors, payment and USB disabled

Cross-Origin-Opener-Policy

same-origin

Cross-Origin-Resource-Policy

same-origin

The web server configuration is kept with the website’s source code in the repository ict-baden/website.