Table of Contents
| Info | ||
|---|---|---|
| ||
The presented manual is based on the example of the NMaaS project which allows the network operations and engineering community to contribute and construct a portfolio of network management applications that can be easily shared and installed to manage these growing sets of infrastructure. More about NMaaS project can be found here. |
1. Bamboo plan.
A dedicated Bamboo plan has been created to launch WS scans of NMaaS components at will.
...
No automated triggers (e.g. either scheduled or push-based) were configured. Plan The plan has to be run manually.
It is worth noting that the scanning process is run within dedicated Docker containers rather than on the Bamboo agents directly. This is a recommended approach.
1.1. Repositories.
Plan The plan uses the same source code repositories as the typical plans created for source code integration, Sonar updates or Docker image builds.
1.2. Variables.
On the plan configuration level, a set of variables are defined that can be later on referenced from various tasks executed during the overall WS scan setup and execution process.
In our case, those include : apiKey, productToken, productVersion as projectToken as well as projectToken and productVersion and projectVersion (for each software component to be scanned within this Bamboo plan, e.g. projectTokenPlatform and projectVersionPlatform for the Platform component).
Some of those parameters The first three are the identifiers of the GEANT organization and scanned product or project in the WS system. They are provided by the WS team administrators and must be kept secret and plan variables is a good place to store them. The other two indicate the version of the scanned product and project.
Some variables can be later on easily managed by for the Bamboo admin for given software project like the product and project versions that are most likely to be bumped from time to time.
1.3. Stages, jobs and tasks.
The NMaaS software is composed of 3 major software components the Platform, Portal and Janitor. Each of them is scanned separately in a dedicated Job under the Default Stage of the plan.
...
The following description will base on the Platform scanning job. The other two are configured in a similar matter.
1.3.1. Checking out the source code repository.
The job starts with the execution of a plain Source Code Checkout task in which only the source code repository needs to be provided as a parameter.
1.3.2. Building Docker image.
Next, a Docker task is executed in order to build the Docker container image on which the scanning process will be launched.
...
The desired content of the Dockerfile should be also provided.
The content of the Dockerfile will be slightly different for each software component - in this case, execute permissions had to be granted to gradlew file as well.
In all the cases, JRE and curl to should be available on in the container.
We are copying the software sources to a known directory on the container, in this case:/scan.
We are relying on that some WS-specific scan configuration files were already added to the sources as the run_ws.sh script.
1.3.3. Running the scan inside the Docker container.
The final task is again a Docker task but this time with the command Run a Docker container.
In the container environment variables sections, a list of environment variables are is being defined and assigned values from the previously created Plan variables.
The container is started with the execution of run_ws.sh script in /scan/ws directory.
2. Changes required in the software source code.
In the case of NMaaS, for each of the software components, a ws directory was created in the root directory with two files.
| Info |
|---|
The number of created directories depends on the number of components in a given project that needs to be scanned separately. |
Typical content of the run_ws.sh script in is provided below. Please note the main scanning script (jar) is run with a number of arguments that are obtained from environment variables that are being set based on the Bamboo plan variables mentioned earlier.
#!/bin/sh echo "Downloading WhiteSource Mend agent..." echo "Running WhiteSource Mend scan..." java -jar wss-unified-agent.jar -apiKey ${API_KEY} -projectVersion ${PROJECT_VERSION} -projectToken ${PROJECT_TOKEN} -productVersion ${PRODUCT_VERSION} -productToken ${PRODUCT_TOKEN} -c ws.config -d ../ |
|---|
The ws.config file contains the configuration of the scanning process specific to a particular software component. Below only a few first line lines are included. Please note that the variables are left blank and the ones provided from the command line are being used.
############################################################### # WhiteSource Mend Unified-Agent configuration file ############################################################### # GENERAL SCAN MODE: Files and Package Managers ############################################################### # Organization vitals ###################### # TO BE PROVIDED AS COMMAND PARAMETER #apiKey= #userKey is required if WhiteSource Mend administrator has enabled "Enforce user level access" option #userKey= #requesterEmail=user@provider.com #projectName= # TO BE PROVIDED AS COMMAND PARAMETER #projectVersion= # TO BE PROVIDED AS COMMAND PARAMETER #projectToken= #projectTag= key:value #productName= # TO BE PROVIDED AS COMMAND PARAMETER #productVersion= # TO BE PROVIDED AS COMMAND PARAMETER #productToken= … |
|---|
3. Running the Bamboo plan.
With all the above in place, the user can simply run the plan when desired.
...