Securing customers CI/CD pipelines using Conviso CLI

I am quite sure everyone in the DevSecOps movement is used to CI/CD pipelines and the importance of adding security controls in the early stages of the development lifecycle.

You can also listen to this article:

This approach is not new and a lot of companies are going in the shift-left direction in order to keep their applications more secure.

As security experts, we know that this is not the only thing that needs to be done in order to stay secure, but for sure, it helps to start gaining maturity.

There are plenty of CI/CD tools in the market and we have support for the most popular ones:

• AWS Codebuild
• Azure Pipelines
• Bitbucket Pipelines
• CircleCI
• Codefresh
• Github Actions
• Gitlab
• Jenkins

At Conviso, we offer different types of functionalities to be executed during a deploy:

• Continuous Code Review
• Security Scans
• Security Gate

Continuous Code Review

This functionality enables to review the source code of every new version that is being added to the application.

For most scenarios, this should be added when merging to the staging environment (prior to production), where the changes being made to the application are mature enough in a business acceptance perspective.

In a nutshell, the CLI retrieves the information of the previous version vs. the current version, some metrics like lines added, lines modified and lines removed, information of the developer who made those changes, and also the technologies being used in the application for a better Asset inventory categorization within the platform.

Finally, the result is assessed in Conviso Platform, using a lean UI where security analysts can perform the code review to identify security vulnerabilities and then easily create them in the platform for later assessment and mitigation.

The whole idea is not to block the development cycle of the team while performing continuous code reviews.

The security team needs to have an SLA for each application in order to review the code in a timely manner. In some cases is a trade-off that needs to be discussed internally in order to not slow down the development team deliveries.

Depending on the development approach of the engineering team, the CLI has support to the following ones:

1. Using Tags, ordered by time
2. Using Tags, ordered by versioning style (semantic version)
3. Without using Tags, ordered by Git tree

Let us have a look at the following example using the CLI for the approach number 1:

conviso deploy create with tag-tracker sort-by time 

For the purpose of this article, we are going to share an example using Github Actions:

name: CI
on:
 push:
   branches: [ master ]
 pull_request:
   branches: [ master ]

jobs:
 conviso-cr:
   runs-on: ubuntu-latest
   container:
     image: convisoappsec/flowcli
     ...
   steps:
    - uses: actions/checkout@v2

    - name: codereview
      #Please use only one of the following approaches in the same job

      #Using Tags, ordered by time
      run: conviso deploy create with tag-tracker sort-by time

And that’s it. It will create the new code version in the platform with the diff between the previous and current versions for later assessment by the security team.

In addition to this, when also configuring Security Scans in the CI/CD, Conviso Platform uses the information of those results as findings to help the reviewer with more context and information. This helps to easily identify possible vulnerabilities that were the results of automatic scans in the new version of the application.

Conviso offers the continuous code review service performed by the Managed Services (MSS) team. We have an elite group of security analysts to help you with that in case there is no expert in your company.

Security Scans

Another important functionality is the security scans that customers can add and execute when deploying a new version of their application. It is also recommended to configure these scans when the version of the application is mature enough, basically, prior production environment.

Besides the open source AST module that Conviso provides, users can also integrate with their own scanners to make the whole experience fit their needs and tooling stack.

Using the CLI is it possible to easily execute SAST, SCA and IaC scans. Something useful that we recommend is to also add the continuous code review functionality as well, so the security analyst can use the results from the scans of that specific version, compared to the old one, to enrich the code review process.

Here is an example of a SAST being configured in the CI/CD workflow in Github Actions:

name: CI
on:
 push:
   branches: [ master ]
 pull_request:
   branches: [ master ]

jobs:
 conviso-sast:
   runs-on: ubuntu-latest
   container:
     image: convisoappsec/flowcli
     ...
   steps:
   - uses: actions/checkout@v2

   - name: Run SAST
     run: conviso sast run

In case of any results, there will be automatically sent to Conviso Platform for assessment.

Quite simple right? You can have more information of Github Actions here, and also for other CI/CD tools.

Something important and useful is that you can automatically convert specific findings to vulnerabilities without manual interaction. This is possible to configure a policy in Conviso Platform stating that findings with a specific severity will be considered as vulnerabilities.

Security Gate

Finally, the Security Gate functionality enables the user to block a build, using custom rules defined by the user, in case there are open vulnerabilities in the application. It will not consider the results from the latest scans, as it may be a false positive. We use this approach to ensure that the block will occur only in case of real vulnerabilities.

This is an example of a possible rule set configuration file:

rules:
- from: any
  severity:
    critical:
      maximum: 0
    high:
      maximum: 5
    medium:
      maximum: 0
    low:
      maximum: 0

To wrap it up, the following CLI command will verify open vulnerabilities vs the rules defined in the configuration file.

conviso vulnerability assert-security-rules --rules-file conviso-security-gate-rules.yml

A success response will look like:

Starting vulnerabilities security rules assertion
✅ Vulnerabilities security rules assertion finished

And a failed response will have the following details :

Starting vulnerabilities security rules assertion
💬 Vulnerabilities summary
[
    {
        "from": "any",
        "severity": {
            "high": {
                "quantity": 7
            }
        }
    }
]
Error: Vulnerabilities quantity offending security rules

This approach is not mandatory but it can be used as a way of not letting vulnerabilities go to production environment. Again, this is a trade-off that needs to be discussed internally. How the rules are going to be defined? What risks are accepted? These are some of the questions that need to be addressed.

Nice then! You are all set up to start securing your CI/CD pipeline.
Reach us out if you want to talk with a sales representative about everything you read in this article.