Exercising caution

6 places to continuously monitor for open source vulnerabilities

Twain Taylor
open source
© Shutterstock / Cq photo juy

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.

Programming languages – JavaScript, Python, Go

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.

Bugs in a programming language can range from incorrect input validation to exploitable denial-of-service to parsing validation issues. The popular programming languages like JavaScript, Python, and Go frequently have issues, although, their security teams are always on the ball, pushing out security patches as soon as vulnerabilities are found. The onus is still on the SecOps team and developers to follow secure coding practices and stay abreast of the latest issues affecting the programming languages they use.

UI frameworks – jQuery, Angular, Bootstrap

Operating a level above programming languages, Javascript frameworks like jQuery, Angular, Vue, and Bootstrap have their own share of vulnerabilities that need monitoring. These frameworks promise ease of use, but also add a layer of complexity and increase the attack surface of the stack.

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.

SEE ALSO: Sourcetrail, an interactive source code explorer, becomes open source

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.

SEE ALSO: Unleash chaos engineering: Kubethanos kills half your Kubernetes pods

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.

open source

Twain Taylor

Twain (@twaintaylor) is a Fixate IO Contributor and began his career at Google, where, among other things, he was involved in technical support for the AdWords team. His work involved reviewing stack traces, and resolving issues affecting both customers and the Support team, and handling escalations. Later, he built branded social media applications, and automation scripts to help startups better manage their marketing operations. Today, as a technology journalist he helps IT magazines, and startups change the way teams build and ship applications.

Inline Feedbacks
View all comments