Adding Security to Continuous Delivery

Isn’t it great when things just work well together? That’s the feeling you get with our continuous delivery and software security tools. HCL Launch, together with AppScan on Cloud (ASoC), gives us the ability to automate control of our application security within our overall DevOps lifecycle, including automation, reporting, and release management.

HCL Launch can process the output of the ASoC plugin and treat the build accordingly. If your build was deployed successfully to a lower level environment but failed the Dynamic ASoC scan with high severity issues, HCL Launch will automatically rollback to the last deployed version and mark the build with a status indicating there are problems. If ASoC identifies lesser severity issues in your build, HCL Launch with slap a “deployment warning” onto it but leave it installe don the target machines. And if ASoC spots no major issues, HCL Launch will give that version an app status that signifies it’s passed all AppScan scans. In other words, HCL Launch creates environment gates that can prevent deployments to Prod or other high-level environments if it doesn’t pass AppScan approval.

Ready to make security in software deployment easier? Keep reading to learn how to set up a pipeline with HCL Launch running the deployment and kicking off the ASoC security scans.

HCL Launch Configuration

HCL Launch has a free installable plugin for AppScan on Cloud. This plug-in includes steps to do each of the following on the AppScan server:

• Create ASoC Presence
• Delete ASoC Presence
• Start ASoC Presence
• Start Android Mobile Analyzer ASoC Scan
• Start Dynamic Analyzer ASoC Scan
• Start Static Analyzer ASoC Scan
• Start iOS Analyzer ASoC Scan
• Stop ASoC Presence

In this scenario, I will set up a workflow to simultaneously kick off static and dynamic scans with ASoC. The following instructions and screenshots will explain how to configure the HCL Launch processes.

Each HCL Launch plugin step must be configured with the ASoC Application ID, Key ID, and Key Secret.

The static analyzer step also requires an IRX file, which points to either the IRX file to be uploaded for scanning, or the directory that contains the files or other locations to scan. The field accepts scan configuration files, eclipse workspaces, as well as .jar, .war, and .ear file types. In addition to the Application ID, Key ID, and Key Secret, the dynamic analyzer step requires the URL  for the location to scan. If the page requires a login, the application login credentials must also be provided.

Notice that each step contains a field for ‘Fail condition threshold’, with the letters H, M, L, I. These indicate how many High, Medium, Low, and Information level security threats the step will accept before failing. For example, in the following case, if the scan results in more than 5 medium level warnings, the step will fail.

Also take note of the gray circles within the HCL Launch process editor after each of the ASoC steps. This is important for allowing the process to move on, even if the steps fail, in order to handle the failure case. If necessary, conditional logic can also be added to fail the overall process using the HCL Launch process editor.

Once our steps are configured, it is time to run the deployment of our application and our security scans. The HCL Launch application process for doing so will look something similar this; first deploying the application to the target, and then running the scans.

I have circled the steps showing the two scans that are running simultaneously.  If we jump over to the ASoC server, we can see these scans are running there as well.

Check back soon for another blog post where I’ll show you how to integrate AppScan on Cloud with our value stream management platform, HCL Accelerate.