While some applications are still being built on a monolithic (all-in-one) architecture – i.e., all components in a single code base, on a single server, connected to the internet – an increasing number of them is now based on the microservices architecture, with each application microservice a self-contained functionality, “housed” in a container managed by an orchestrator like Kubernetes, deployed on the cloud (public or private), and communicating with other application microservices over the network in runtime.
But with applications no longer self-contained, security vulnerabilities are no longer present just in the code; vulnerabilities can “start” on one microservice, go through multiple components, and “finish” on a different microservice.
“We are no longer dealing with just vulnerabilities, but also with vulnerable flows between microservices. On top of that, as cloud-native applications are built on multiple infrastructure layers – the container, the cluster, and the cloud – they way these layers are configured affects what a hacker can do with these vulnerabilities,” notes Ron Vider, one of the co-founders and the CTO of Oxeye.
Modern architectures require modern AppSec testing solutions
This dramatic change in how applications are structured has made traditional approaches to application security ineffectual and has created security blind spots for AppSec and DevOps teams.
“Old-school” software composition analysis (SCA) and static, dynamic, and interactive application security testing (SAST, DAST, IAST) tools are run independently, are not synchronized with one another, and are unable to cross-reference and use enriched data from other code layers in the environment. The incomplete and inaccurate results they provide when testing cloud-native apps have made it obvious that a new approach and new, better tools are needed.
Oxeye is one such tool. It essentially combines all AST methodologies with a new generation of security control assessment capabilities and, as a result, excels in finding and correctly prioritizing vulnerabilities in cloud-native applications that need to be addressed. It helps clear the noise of false positives/negatives delivered by legacy solutions, and allows developers and AppSec teams to focus on high-risk, critical vulnerabilities.
Getting started with Oxeye is fantastically easy: you need to deploy a single component (Oxeye Observer) into your staging or testing environment, and you do it by using a single YAML file containing its definitions.
“The Oxeye Observer immediately starts running within the cluster and starts it automatic discovery process,” Vider told Help Net Security.
“First it analyzes the infrastructure to understand how the application is configured, and it does that by communicating with the with the Docker API, the containerd API, the Kubernetes API and the cloud provider API, and fetching the relevant configuration. Then, it detects potential vulnerabilities in the code (the application’s code and the third-party components). Next, it analyzes the communication between the different components and traces their flow. Finally, it validates the found vulnerabilities by sending payloads to the application and analyzing its behavior, to understand whether it’s exploitable or not.”
