5 Use Cases of Kondukto CLI in CI/CD pipelines

Everyone talks about integrating security with DevOps pipelines these days. However, in the pipelines, there are a plethora of scenarios that make a one-size-fits-all solution almost impossible.

Given the different business criticality of applications and the variety of pipeline structures, security teams need flexible solutions which can adapt to several conditions.

That is why we worked on our CLI (as Konduktors we call it KDT) tool to address as many needs as possible while making a vendor-agnostic DevSecOps adoption possible.

Here are five use cases of the CLI to make life easier for the security teams.

1) Cloning applications from ALM tool in the pipeline

Most of the time, the development and DevOps teams do not have access to the security or vulnerability management tools. On the other hand, security teams are not given access to ALM tools either which leads to new applications being noticed by the security team only before the deployment stage.

To bridge this gap, the following command can be a lifesaver for security teams as the application will be created on Kondukto within the pipeline without having to log in to any other tools.

This way, the extra layer of creating applications first on the security tool can be skipped and scans can be started simultaneously in the pipeline without the security team being involved in the process.

Create a project with the given CI_PROJECT_ID and assign TRIBE as a team on Kondukto

kdt create project –repo-id $CI_PROJECT_ID -t “$CI_PROJECT_ROOT_NAMESPACE”

2) Importing scan results to Kondukto

Instead of running security scans on a sandbox environment, it makes more sense to use the existing DevOps pipelines where applications already get compiled.

For this purpose, the results of scans that already run on the pipeline can be imported to Kondukto without triggering a new scan which requires compilation effort and has a good chance of failing due to compilation issues.

This allows getting scan results to Kondukto in an automated fashion with no intervention to the current pipeline structure.

Import scan results to Kondukto

kdt scan — repo-id $CI_PROJECT_ID -b $CI_COMMIT_REF_NAME -t gosec -f results.json

3) Asynchronous scans

This option is quite useful for running security scans without blocking the pipeline. Scans get triggered within the pipeline and then keep running as a background job without blocking the pipeline. Even though this might lead to some critical vulnerabilities slipping into production, this is the best alternative to help with the onboarding process when we are rolling out the DevSecOps program to a large number of applications.

Instead of having security teams trigger scans manually on scanners which is a tedious activity, each scan gets triggered automatically in the relevant stage of the pipeline of each application, and results are streamed to dashboards with no human intervention.

Once security scans become an integral part of the pipelines and there is enough data about the types of vulnerabilities discovered in all applications, security teams can prioritize certain types of vulnerabilities and position them as blockers in the pipeline.

Start a scan with async parameter:

kdt scan —repo-id $CI_PROJECT_ID -b $CI_COMMIT_REF_NAME -t gosec — aysnc

Import a scan with async parameter:

kdt scan —repo-id $CI_PROJECT_ID -b $CI_COMMIT_REF_NAME -t gosec -f results.json — aysnc

4) Time out after a certain time

We all know some scans take a long time and for certain applications that frequently get shipped into production, it might be a good idea to set a maximum wait time for a scan to get completed. If the scan is still running at the end of the maximum wait time, it turns into a background job without blocking the pipeline.

This is particularly good practice if open source scanners are used to back commercial scanners. As open source scanners generally scan a more limited scope, they tend to take less time and are more likely to finish the scan within the time-out value. Low hanging vulnerabilities can be quickly checked by the open source scanners whereas commercial scanners search for a wider scope of vulnerabilities in extended timeframes.

Commercial scanners can also have configuration options to reduce the scan duration and with proper configuration, huge time savings can be achieved. However, the preferred way is to go with the asynchronous scans until having sufficient data to identify the improvement areas.

Start a scan with time-out (10 minutes) parameter:

kdt scan —repo-id $CI_PROJECT_ID -b $CI_COMMIT_REF_NAME -t gosec — timeout 10

Import a scan with time-out (10 minutes) parameter:

kdt scan —repo-id $CI_PROJECT_ID -b $CI_COMMIT_REF_NAME -t gosec -f results.json — timeout 10

5) Security threshold control

Before deploying applications to production, thresholds can be set to make sure applications do not advance in the pipeline unless they meet those thresholds. Rather than creating these thresholds separately on each scanner, they can be centrally configured on Kondukto for all scanner types.

For this purpose, threat modeling comes in handy as it allows informed decisions about the type of vulnerabilities that will be positioned as blockers in the applications. A vulnerability being reported as a medium severity by the scanner can be upgraded to high severity if it belongs to an application with high business criticality.

The threat modeling piece can be tied down to applications on Kondukto using labels to create clusters of applications with common properties.

Labels can later be associated with security thresholds to create granular rules where different thresholds can be set for applications with different labels.

This way, different pipelines can have different security thresholds to meet before the applications advance in the pipeline.

Break the build if the security threshold entered on Kondukto is not met

kdt status –project $CI_PROJECT_NAME

Break the build if there are any critical or high severity vulnerabilities

kdt status –project $CI_PROJECT_NAME –threshold-crit 1 –threshold-high 1

Break the build with the given exit code if there are any critical or high severity vulnerabilities

kdt status –project $CI_PROJECT_NAME –threshold-crit 1 –threshold-high 1 –exit-code=10