Securing LGTM Enterprise
LGTM Enterprise integrates into your existing IT infrastructure. This means that it can often use existing secure systems. For example, users can log in using the same two-factor authentication that you've mandated for access to code repositories.
Each organization's infrastructure and security policies are different, so the recommendations below are not exhaustive. Instead, they are guidelines on general good security practice. Talk to your Semmle support contact if you'd like to discuss your specific security requirements or concerns.
System setup guidelines
We recommend that you:
- Run LGTM on servers without access to or from the internet.
- Run the LGTM web application as a secure server by installing an SSL certificate.
- Configure LGTM to use HTTP strict transport security (HSTS) headers. This option is not enabled by default because it requires you to ensure that SSL certificates are always updated before they expire.
- Keep the default access settings, that is, anonymous access and the ability for users to register for an account on LGTM are both disabled.
- Before you connect LGTM to a third-party system, such as a repository or issue tracker, verify that this system meets your security policies.
- Where possible, use authentication providers to give users access to the LGTM web application instead of creating users within LGTM. This allows them to use their credentials for an existing system to log in and avoids an extra administration overhead. Many of the external systems available for LGTM authentication support two-factor authentication, providing an additional level of security.
- After configuring one or more authentication providers, replace the LGTM account that was created during installation, for initial administration, with an externally managed account.
- Sign up to receive release notifications by email so that you are always up to date with information about maintenance releases and any security advisory notes. Follow any advice on mitigating security concerns as soon as possible. Typically, this is achieved by upgrading to the latest version.
Repository host integration guidelines
Each repository that's added to LGTM is checked out and built on an LGTM worker host. When the repository includes an LGTM configuration file, the commands in this file control the build and analysis process. Consequently, individuals with write access to a repository can specify exactly which commands are run during the build/analysis of that repository by LGTM. In addition, if LGTM is unable to analyze one or more languages in a project, users can enter a configuration in the user interface and reanalyze.
Our recommendations for mitigating the risks inherent in analyzing code that's being actively developed are:
- When you define a repository provider, configure the repository host system as an authorization provider. This restricts access to data about each repository to users who have access to that codebase in the repository host system. For detailed information about user access to LGTM data, see About authorization levels.
- Restrict adding projects to LGTM administrators.
- Deploy a separate instance of LGTM to analyze any highly sensitive codebases. Specify worker daemons on machines that serve exclusively as worker hosts for this instance of LGTM. This allows you to segregate those projects entirely. You could use worker labeling to achieve some separation of analysis, but this would not stop a determined attacker.
- If you want to analyze code stored in public services, see the guidelines below.
Public service integration guidelines
If you want to analyze code stored in public services, such as Azure DevOps Services, BitBucket Cloud, GitHub.com, or GitLab.com, LGTM and the public service must be able to access each other. We recommend the following configuration in this case:
- Set up a separate installation of LGTM to integrate only with these services.
- Add a login whitelist so that only users within your organization can log in.
- Restrict LGTM's outbound network access as much as possible. For example, the IP addresses used by GitHub.com for various purposes are available from https://api.github.com/meta and could be used to create a set of firewall rules.
- If automated code review isn't needed, exclude all inbound network access to LGTM. If you wish to use automated code review then the external repository service must be able to make HTTP requests that match the regular expression:
/external-hooks.*. Two options for this are:
- Use split DNS so that the LGTM URL (for example,
https://lgtm.example.com) resolves to a different address internally and externally. The external IP should then be a proxy to the internal IP that only forwards paths prefixed with:
/external-hooks, and discards any other request.
- Use a load balancer or reverse-proxy in front of LGTM that filters by source IP, and only allows requests to paths prefixed with:
/external-hooksfrom the external internet, and everything from the internal network.
- Use split DNS so that the LGTM URL (for example,