# Teamscale Security
We at CQSE take security of your data and source code very seriously.
In an on-premise deployment of Teamscale, none of your data leaves your own networks. Teamscale will never connect to remote servers unless you configure it to do so.
All required network connections to and from Teamscale can and should be encrypted.
The goal of this article is to give a short overview of all security-relevant aspects of Teamscale and its integration into your infrastructure. We link to additional documentation in several places for a more detailed explanation.
# Scope of This Article
When you install Teamscale on your own servers, you are of course responsible to apply suitable security measures to the host operating system and operating environment of all the installed tools. This is outside the scope of this article.
This article only deals with the security measures of the Teamscale server application.
CQSE maintains an information security management system, including a business continuity plan, disaster recovery plans, incident management, etc.
We employ both an information security officer and a data protection officer.
TISAX (Trusted Information Security Assessment Exchange), governed by the ENX Association (opens new window) on behalf of the German VDA (opens new window) (Verband der Automobilindustrie, the German Automobile Industry Association), provides a single industry-specific security framework for assessing information security for the wide landscape of suppliers, OEMs, and partners that contribute to the automobile supply chain.
CQSE GmbH is a TISAX participant and was assessed at assessment level 3 (AL 3), meaning we were assessed against the assessment objectives required for data with a very high need for protection under the definition of TISAX, such as data classified as secret. TISAX Assessments are conducted by accredited audit providers that demonstrate their qualification at regular intervals. TISAX and TISAX results are not intended for the general public. The result is exclusively retrievable over the ENX Portal (opens new window).
The scope ID and assessment ID for CQSE GmbH are ST21M5 and ACKPRT-2, respectively.
# Penetration Tests
We run yearly penetration tests of Teamscale. The test scopes include the OWASP Top 10 as well as our roles and permission model.
If you'd like to perform your own penetration test of your Teamscale installation in your own network, please contact us. We welcome such tests, but ask that you share all results with us, so we can effectively fix any found issues.
There are multiple supported deployment modes:
All required services are included in the Teamscale Docker image. The image also includes the in-process NoSQL database used by Teamscale, which can not be run separately.
The following data must be persisted via Docker mounts:
- database files
- persistent logs
- configuration files
The Teamscale process does not run as root inside the Docker container.
# Operating System Service
Teamscale does not require root or administrative privileges when installed as a service.
# Updates and Security Fixes
- Major releases: every 6 weeks
- Patch releases: every week for the latest two major releases
Security fixes are backported to the latest two major releases.
# Security Measures in Teamscale
We recommend you configure LDAP, Active Directory or Single sign-on as your authentication provider. In this case, human users log into Teamscale with their LDAP credentials. Credentials are forwarded to and verified by the LDAP server/SSO/Active Directory.
Technical users authenticate themselves in Teamscale with an access token. Tokens can be revoked and regenerated in Teamscale.
Teamscale has a fine-grained permission model including permission management with roles and rights for both technical and human users.
Naturally, access to Teamscale projects can be granted selectively, enabling you to effectively segregate sensitive information and control which groups of people can see and modify what.
Teamscale’s log files are stored on-disk and must be secured with the host operating system’s permission system by you.
Some log files can also be accessed via Teamscale's web interface by Teamscale administrators. Access to these is secured by Teamscale’s permission management system.
The following security-related events are logged by Teamscale:
- failed login attempts (passwords are not logged, of course)
- invalid API requests (access tokens are not logged, of course)
By default, logs are rotated regularly.
Teamscale's web interface can be configured to be served via HTTPS. You will need to provide the required certificates yourself.
However, for a productive setup, we recommend you terminate SSL yourself, e.g by placing a reverse proxy like Nginx (opens new window) before Teamscale. This gives you additional flexibility and usually has better performance.
# Settings Encryption
Teamscale automatically encrypts sensitive settings with symmetric encryption, e.g. credentials for external systems it connects to. The encryption key can be configured in Teamscale's admin interface.
Teamscale can be configured to automatically create backups of itself in regular intervals. These include all information needed to restore a Teamscale instance. They are stored on-disk as zip files.
Backups can be configured so they are automatically rotated in configurable intervals.
Backups can be encrypted symmetrically. The encryption key can be configured in Teamscale's admin interface.
# Connections to Other Systems
To perform its functions, Teamscale needs to connect to and integrate with other systems in your infrastructure. Which exact systems it requires access to depends on which features of Teamscale you intend to use.
For further information about these connections and their authentication mechanisms, as well as required permissions for Teamscale's technical users in these tools, see the respective part of our documentation:
Version Control Systems and Code Collaboration Platforms:
Authentication and Single sign-on (SSO):
- Active Directory, LDAP
- Azure DevOps Authorization Server
- Single sign-on with SAML 2.0 and OpenID Connect
Build and Test Environments:
- Upload of external analysis results, e.g. test coverage, results of checkers run in your build, ...