6 Factors that any DevSecOps team should consider in CI/CD pipeline

As the saying goes, "A chain is only as strong as its weakest link", so is the security of any application.

Unlike the effort spent on business features, those spent on security testing, fixes and updates do not provide any additional benefits to business or users. However, a security breach can hamper your business drastically.

An agile team trained in DevSecOps should include the effort for security testing activities in the backlog estimation. A well planned CI/CD pipeline to automate most part of the testing can help teams optimize the security testing effort. Let us look at the factors that DevSecOps teams should consider for faster CI/CD cycle:

1) Code-scanner:

Any effective CI pipeline should contain code analysis as part of the build process. This is typically done by integrating with code analysis tools like Sonar, Fortify, and so on.

2) Extended unit testing:

'Definition of Done' is considered as one of the key elements in the backlog description. This should include additional test cases for any story or feature. For example, 3W technique (what, when, who) can be followed. In this technique, for any given backlog or feature, what are the allowed inputs, when will the feature be available and who is allowed to use this feature can be mentioned. Based on this technique, unit test automation cases need to be added. Typically, this is achieved by test case automation using Junit, Cucumber, and so on.

3) Web-scanner:

Teams should keep the dynamic security testing scripts (usually, tools like WebInspect, ZAP are used for this) for all the key use cases. The dynamic security testing scripts should be part of the deployment pipeline and should be triggered after the build process.

4) Third party scanner:

In the agile development space, while responding to business changes quickly, developers tend to include several ready-to-use components for various coding aspects like web frameworks, logging, parsing json, or xml data, importing or exporting data, and so on. An efficient CI pipeline should include a step for checking the list of such third party components for vulnerabilities. There are quite a few tools available, which can connect to latest vulnerability databases and generate vulnerability report.

5) Platform/Infrastructure scanner:

As part of the deployment pipeline, teams should definitely include a step for scanning the security aspects of platforms and infrastructure. This step depends on your application's architecture.

For example, a server host and network scan that will look at all the software installed, ports listening, and so on.

6) Threat/Vulnerability assessment:

All the above steps will give way to several issues or reports. After all, security scanning tools are just machines. Teams should always remember that most tools used for security scanning are Rule or Inference engines.

Though the tools will help in listing out the issues, most of these assign the severity for the issue based on a common rule-set. A low severity instance from a tool may actually be one that is capable of bringing down your entire system, while on the contrary, a critical severity instance reported by the tool may not even be applicable for your architecture.

At the end of the day, the threats listed by the tools are to be analyzed by the teams and fixes are to be prioritized accordingly. It is highly recommended that this analysis is done as a manual activity and performed more frequently in the early stages of application development. Let that chain grow stronger and sturdier!