Application Security Automation Part 3

Automated Static Code Analysis

Görkem Çetin
4 min readJan 10, 2022
Photo by Arif Riyanto on Unsplash

Recap of Part 1 & 2

  • Defined how the system will flow
  • Installed components on 4 different virtual machines
  • 1 Sensor, 1 SSC (DB on same machine), 1 Controller, 1 Client

Configuration

Let’s configure the components installed before. This system is for testing so I will do only basic configuration. If you create something similar on a production environment please do it in a more secure way (I will post about this topic later).

I will do the following configurations:

  • Configure Controller
  • Configure SSC
  • Configure Sensor(s)
  • Configure (Jenkins) Client

1-Controller

All configuration of controller is decided on config.properties file so I will edit that file. As I mentioned before, I will do only essential stuff.

Location of config file
You need to set SSC’s fields (url and ip) and controller’s own URL. Shared secrets are default for now(SSC, Worker, Client).

After the file is saved, restart the controller service and it is ready.

2-SSC

We need to configure SSC for using Scan Central.

Administration > Configuration > ScanCentral SAST, non-edited version will look like this

Tick the check box, write the URL of controller and the shared SSC secret which we left its default value “changeme”. It doesn’t matter if you use clear text shared secret or hashed shared secret, you need to write clear text version of secret at the text box on SSC.

Save and restart the SSC.

After restart, you should see Scan Central menu on the interface.
You should see your controller’s information on this menu after they started communicating.

3-Sensor(s)

You need to configure SCA so it will work as a worker service for Scan Central. I will configure it as a Windows Service. Following folder has the script for this purpose.

Script’s location
Run the command line as administrator because script will create a new Windows Service

You should provide some parameters to create sensor service, installed SCA version, URL of controller and shared secret for workers which is “CHANGEME123!” by default. After running the script, your worker service is ready. Copy pasteable version below.

setupworkerservice.bat <sca version> <controller url> <shared secret>setupworkerservice.bat 21.1 http://172.16.148.10:8080/scancentral-ctrl CHANGEME123!
Sensor Service
You should see your sensor’s information from SSC’s Scan Central interface.

4-Client

You need to configure SCA so it can communicate as a client with Scan Central Controller. Communication is established with secrets so you need to provide client secret in client.properties file. Client secret is “CHANGEME321!” by default.

client.properties file’s location

Client is ready, you can trigger the scan from client manually or trigger the client scan from Jenkins. I will show both of these methods at next part of the series.

Common mistakes and answers for confusing points

  • A SCA can work as a sensor or as a client. To assign client role edit only client.properties file. Do not edit worker.properties file.
  • Communication between components may take few minutes, please be patient before starting looking for problems.
  • Microfocus’ documentation and parameter naming can be confusing at some point. Worker and sensor mean same thing, scan node SCA for Scan Central.
  • Config files include “tokens” such as worker_auth_token and client_auth_token at controller’s config.properties. Actually they are “secrets” for establishing communication. In this series I call all communication parameters as secrets for the sake of simplicity. I will create and use tokens which is different than secrets while triggering scans in the next part.

Organization of series
1- Introduction

2- Installation

3- Configuration (This post)

4- Scanning

5- Reviewing the findings

More…

--

--

Görkem Çetin

CSSLP, Security+ / I try to share my knowledge and experience about cyber security.