
Security Best Practices + Klocwork
Security best practices are essential to follow when installing any web-based application. Here, we outline the steps for setting up Klocwork, a static analysis and SAST tool, for secure operations. This process is generally on-premises and behind a firewall. There should be additional precautions taken in the case of exposing anything on the internet.
Read along or jump ahead to the section that interests you the most:
- Security Best Practices with Klocwork Overview
- STEP 1: SSL/TSL
- STEP 2: Open Ports and Routes
- STEP 3: Authentication
➡️ use Klocwork for software security
Security Best Practices with Klocwork Overview
Klocwork portals receive analysis results to prepare big-picture reports on compliance, trends, and issue details. You can log in to view the reports, triage issues, and configure analysis settings. In addition, Klocwork portals are deployed on-premises or here in the cloud. They can run on bare metal, within VMs, or in containers.

Klocwork’s server-side components can reside on the same VM or the license service can run on a separate VM. Three ports must be open:
- License service common (27000)
- License service Klocwork daemon (33133)
- Klocwork portal (443).
The license service common port and the Klocwork portal port are used when configuring client tools.
Security Best Practices: SSL/TSL
There are two basic techniques for encrypting the communication between the Klocwork portal and Klocwork client tools or browsers:
- Use a reverse proxy
- Configure the Klocwork portal for SSL/TSL
Using a reverse proxy is often the choice of IT departments because they are familiar with their installation and configurations and they work well. A reverse proxy is required if you wish to deploy the Klocwork portal on port 443 on a Linux host.
Configuring Klocwork itself to run as an SSL/TSL (https) service can be done in three simple steps:
- Request a signed SSL/TSL certificate from your corporate signing authority for the host running a Klocwork portal. While waiting you can use an unsigned certificate generated by kwauthconfig.
- Run kwauthconfig to configure the portal for https connections.
- Notify your users to use https and update their IDE’s Klocwork plugin configuration with “use secure connection” and the new port number.
Requesting a Signed SSL/TSL Certificate
Here’s an example of openssl commands to generate the key pair and the certificate signing request file (.csr). Only the portal.csr file is sent to the signing authority.
openssl genrsa -out portal.key 2048
openssl req -new -key portal.key -out portal.csr
Country Name (2 letter code) []: US
State or Province Name (full name) []: Minnesota
Locality Name (eg, city) []: Minneapolis
Organization Name (eg, company) []: mycompany Inc.
Organizational Unit Name (eg, section) []: Defense
Common Name (eg, your server's hostname) []: klocwork.mycompany.com
Email Address []: [email protected]
The format of the certificate file you receive back may vary. It will likely contain the host’s certificate, any intermediate certificates, and the root certificate of the signing authority. If it only contains the host certificate, you will need to download the intermediate and root certificates manually. What is required is that the private key is combined with all these certificates to form the keystore.
Here’s an example of the openssl commands when a p7b file is received.
openssl pkcs7 -print_certs -in myhost.p7b -out myhost.cer -inform der
openssl pkcs12 -export -in myhost.cer -inkey portal.key -out
myhost_keystore.pfx -name tomcat
Enter Export Password: changeit
Verifying - Enter Export Password: changeit
openssl pkcs12 -nokeys -info -in myhost_keystore.pfx
The password and name are the default values used by the Klocwork portal, but you can use other names. However, you would then need to manually edit the tomcat server configuration information in the projects_root/tomcat/conf/server.template file. The last command outputs the contents of the keystore for verification.
The output file, myhost_keystore.pfx, is a pkcs12 keystore and must be copied to projects_root/tomcat/conf/.keystore for the Klocwork portal to find it.
SSL/TSL Connection Used to the LDAP Server
When an SSL/TSL connection is used to the LDAP server (i.e. ldaps://…), which is recommended, the server’s cerificates must ke saved in the portal’s trust store (<Klocwork server install>/_jvm/lib/security/cacerts). The Klocwork installation includes the <Klocwork install>/_jvm/bin/keytool utility for this task. For example:
keytool -import -alias ldaproot -file rootca.cer -keystore cacerts
keytool -import -alias ldapInter -file inter.cer -keystore cacerts
keytool -import -alias ldap -file ldap.cer -keystore cacerts
Run kwauthconfig
While it is possible to manually edit the projects_root/config/admin.conf and projects_root/tomcat/conf/server.template files, the easier choice is usually to use the gui tool kwauthconfig.
If your Klocwork portal service is hosted on a Linux OS, without a desktop, you will need to use an X11 server. kwauthconfig is included with the Klocwork server install package.
kwauthconfig is also used to configure the portal for authentication and email notifications. The following example just focuses on the SSL/TSL configuration.
It’s very important that you:
- Stop the Klocwork portal services before changing the configuration.
- Copy your keystore (e.g. myhost_keystore.pfx) to projects_root/tomcat/conf/.keystore before starting kwauthconfig if the keystore is available. If there is no .keystore file then kwauthconfig will create an unsigned certificate.
Kwauthconfig will open with the last projects_root configuration data or prompt for a projects_root directory.

There are two Advanced Settings that require manual editing of the configuration file projects_root/config/admin.conf. They can be added anywhere.
Property Name | Value | Description |
init.admin.name | Username to receive Project Root Admin role | To identify which user in the external database should be the initial Project Root Admin. |
ldap.user.vis.name.attr | User attribute for displaying name (e.g. sAMAccountName) | To specify an alternate user attribute to use for a user’s display name. |
Security Best Practices with Klocwork Review
Security best practices for Klocwork are as simple as:
- Configure SSL/TSL
- Open specific ports and routes
- Enable authentication
After applying those configuration steps, you will have:
- Controlled access points
- Encrypted all Klocwork data and user credentials when they are passed between the portal and client tools
- Controlled who can access data on the portal
If you would like to see for yourself how Klocwork SAST helps you to ensure software security, sign up for a free trial now.