Recently the industry has seen a trend where organizations are moving rapidly to integrate vulnerability detection tools as part of their CI / CD environments. That’s a step in the right direction only if the risks that emanate out of those integrations are carefully considered and mitigated. Unfortunately we don’t see much evidence of due diligence and as a result have seen how these integrations can actually increase the risk to the organization.
Let’s take an example of Jenkins which supports a plugin model allowing a number of these tools, including vulnerability scanners to gain access to source code. In 2018, Jenkins published 17 security advisories and just in the first quarter of 2019 7 security advisories have been published disclosing security vulnerabilities in numerous integration scripts and plugins. Most recently we saw how large number of plugins were storing credentials in clear in these environments.
What does this all mean and whats the road ahead ?
Bad actors are very good and quick to spot changing trends and security posture, after all they are constantly knocking on doors to find out which of those doors have been left open for them to infiltrate into networks. This is one area where ThreatWatch believes will be on the radar of malicious entities going forward. Very often API keys, encryption keys and other secrets are left embedded in the code which means compromising a CI / CD environment can result not just in code execution, which itself is highly undesirable and likely to result in a compromise but also leaking secrets that can be leveraged for other attacks.
Does that mean we abandon CI / CD based integrations ? Not quite and it wont be prudent to do so either since the objective is catch security vulnerabilities before they are exposed via deployment. There are ways to do these integrations securely and here are a few ground rules to consider,
- As far as possible don’t run untrusted binaries in your environment but rely on human readable scripts that you can verify, code review and then deploy. Understand as to what the script is attempting to do, is that really needed and ask questions to vendors.
- Don’t give direct access to your source code, CI/CD environment to third party plugins, instead use those that can work on your build outputs / end deliverables. Smart solutions will be able to provide you the hooks to be invoked once your build is complete and will not require you to share credentials. Requiring you to share credentials is also an indication that the tools that you are using are not only very intrusive but not smart enough.
- Focus on continuous vulnerability detection of your build outputs and not on continuous builds. This is very important and often overlooked aspect. Vulnerabilities are getting disclosed constantly and your build outputs are getting exposed to newer vulnerabilities at the same pace. So whats needed is a mechanism to do passive and continuous detection of those vulnerabilities without requiring you to keep running builds for detection.
This is where passive build integrations like twigs can come into play, which can integrate with any build environment, works on your build outputs and dependencies without requiring access to your repository and most importantly provides continuous detection capability across various versions of your build outputs, without ever running a scan.
twigs supports tracking of code repositories ( GitHub ), all operating system images, cloud subscriptions or data center hosts and containers. Write to you us at, info@threatwatch.io for more information.