6 places to continuously monitor for open source vulnerabilities
Open source tools have taken center stage in the DevOps toolchain. As organizations become increasingly dependent on open source tools, the risks that affect these tools is transferred to these organizations. To mitigate this risk, it is essential for organizations to practice continuous monitoring of open source tools. Let’s look at the various layers in an open source stack, and identify key points of concern that need monitoring.
Linux – Kernel, Sudo
Linux has found a place in every tech stack. Because of its widespread adoption, it is a prime target for hackers. Also, the sheer complexity and vastness of the project mean that vulnerabilities inevitably occur regularly. Whether it’s the Linux kernel or a vital part of the system like the Sudo function, every part of the Linux OS can result in vulnerabilities.
We operate in a world of polyglot development teams. This is great for the developer experience but can be a nightmare for enforcing security. Each programming language is developed and maintained by an open source community of developers. They each have different design philosophies, update frequencies, and vulnerabilities unique to each of them. If your organization is small and all developers write code in a single language, your job is easier, but in large organizations, SecOps teams have their work cut out for them when it comes to monitoring vulnerabilities in programming languages.
UI frameworks – jQuery, Angular, Bootstrap
Plugins are core to the jQuery experience, and they are often a point of vulnerability. Other threats include cross-site scripting (XSS), and content security policy (CSP) bypass. The takeaway is clear – UI frameworks need continuous monitoring.
Container tools – Kubernetes, Docker, container images
The container revolution has swept the world of development. Progress in container tooling has been rapid over the past few years. However, rapid growth also comes with security gaps that need to be plugged. In the container stack, there are many layers such as the container engine, container registry, and container orchestrator. They are all potential sources of vulnerabilities.
The risks affecting Docker include the mishandling of secrets that leaves sensitive data open to unauthorized viewers and denial of service issues caused by over-consumption of resources like CPU and memory. Kubernetes is even more central to the container experience than Docker, and its vulnerabilities need to be monitored that much more closely. Issues include leaking of memory and unauthorized access to custom resources.
Apart from this, container images can be downloaded from the public internet and used as part of an organization’s tech stack. There need to be automatic checks in place to scan container images before download using a container registry. Ops teams may choose to have a set of vetted commonly used container images that developers can download freely.
Databases – Redis, MongoDB, PostgreSQL
No matter which point of entry they use, data is the treasure that hackers are after. Open source databases are growing in usage. This includes databases like Redis, Mongo, PostgreSQL, and Cassandra. As these databases become custodians of a company’s vital information, extra measures need to be taken to secure them.
Issues affecting databases include buffer overflows, SQL injection, and misuse of OpenSSL configuration files. The last thing any organization wants is to be featured in the ‘Technology news’ column for exposing the precious data of its users. Adequately securing databases can do wonders to avoid a data breach.
Git – GitHub, GitLab
Git has become vital as the starting point of the CI/CD pipeline. This has sparked the practice of GitOps where the entire development pipeline is initiated and run from Git repositories. Two of the most popular Git platforms are GitHub and GitLab. The majority of developers use these platforms to store code and collaborate with team members.
Particular attention should be paid to avoid hard-coding sensitive information and leaving them viewable in a repository. Only known developers should be allowed to commit code, which can be enforced by the signing of commits. While these platforms are used to share code publicly, exercise caution so you don’t accidentally expose proprietary code to the outside world.
If one thing jumps out of this long list of open source tools and their vulnerabilities it’s that they need continuous monitoring. There are innumerous ways things can go wrong with these tools and their users. However, monitoring these tools manually isn’t the solution. It takes purpose-build security monitoring tools that scan the users, data, and integrations of these tools to identify vulnerabilities. This could be a combination of open source security tools like Whitesource, a container runtime security tool like Twistlock, and incident management tools like Pagerduty. Organizations that rely on open source tools as their lifeline need to do whatever it takes to secure these tools.