RSA recently published “20 Predictions for 2020”. These are spot on and interesting. While these predictions cover the complete security landscape, I would like to draw attention to one specific prediction here, “#5 – Security shifts left”.
The basic idea with “security shifts left” is to ensure that DevOps teams perform required steps during CI/CD process to bake in security aspects/requirements in the solution during development itself. Currently security is quite often an afterthought i.e. post development. Let me give some examples here:
- Code analysis – This is often a gate that is present at the “pre-release” phase rather than in the CI/CD pipeline. Thus implying that issues are discovered too late in the game and resulting in potentially vulnerable code getting shipped with promise to quickly deliver a patch subsequently.
- Vulnerability analysis – Engineering organization often do not look at the Bill Of Materials (BOM) for their solution. “Materials” here refer to any third-party libraries or packages that are used to build the solution. These third-party packages typically come with their own vulnerability baggage. Thus resulting in vulnerability creep in the final software solution via the third-party dependency.
- License restrictions – Engineers leverage open source libraries extensively during development. This helps accelerate the development process and allows engineers to focus on developing their business logic. However, open source libraries come with varying types of license restrictions. Identifying that a library with a restrictive license is used too close to the release date, can throw the release plan off track.
It is best to plugin these gaps by allowing “security to shift left” and move these assessments/checks earlier in the cycle. CI/CD is the right place to plugin the right tools to ensure continuous assessment (via DevSecOps methodology). These tools need to be developer-friendly and de-centralized to allow engineers to use these locally on their development boxes directly. The traditional model of submitting requests to a central AppSec team simply does not work well nor scale.
ThreatWatch (TW) provides a SKU for DevOps with the following capabilities:
- Ability for engineers to locally assess their source code repository for vulnerability creep from third-party dependencies. TW has support for numerous technology stacks (like NodeJS, Yarn, Python, Ruby, etc.) and can produce a simple report which provides mitigation details.
- Ability for engineers to check if the open source libraries being used in their source code repository do not introduce any license related issues.
- Ability for engineers to discover any hard-coded secrets in their code. For example things like hard-coded passwords, OAuth tokens, cloud credentials/tokens, encryption keys and more.
TW provides ability to track above items across multiple version of the software (released or in development)
All of these capabilities can be made directly available to engineers. This is a complete shift left from security perspective. Also, TW tools can be incorporated in your CI/CD workflow to ensure that regular assessments and compliance checks happen all along. Thus ensuring no surprises towards the tail end of the release.
To know more about how ThreatWatch can help your teams build more secure software, please write to us at info@threatwatch.io