The era of the cloud-native application is well and truly upon us: IDC researchers have predicted that by 2023, more that 500 million apps will be developed using cloud-native approaches!
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.”
The analysis happens in runtime, and the collected information is sent to the company’s SaaS platform, which correlates it, provides contextual risk assessment for each found vulnerability, and prioritizes them by taking into consideration how they happen at runtime and what opportunities they provide for attackers.
“A good example of how contextual risk assessment provides a better prioritization in a real life scenario is the recent Log4Shell vulnerability,” Vider explained.
A solution that distributes application security ownership
A good and effective application security testing tool should perform automated and comprehensive analysis and should be helpful to all practitioners responsible for application security in the organization: the developers, the AppSec and the DevOps teams.
Though Oxeye’s dashboard can be accessed by developers, it’s primarily a tool for AppSec and the DevOps teams to examine and assess Oxeye’s findings.
The dashboard maps the tested applications, the vulnerable flows, the discovered vulnerabilities, and additional information about them. It explains how this type of vulnerability arises and how this can be prevented, it tells the user whether the vulnerable component is accessible from the internet and whether there are additional risk factors. It also pinpoints the file where the vulnerability is located, shows the stacktrace to point to the exact line(s) in the code where the vulnerability occurs, and creates the code that can be used to reproduce it.
Ultimately, though, developers are the ones who ultimately solve the discovered problems. To make the process as easy as possible for them, Oxeye works as an integral part of the CI/CD pipeline: the developers test the code they write, Oxeye automatically detects vulnerabilities at runtime, warns them about them (e.g., via Slack) and delivers all they need to fix them directly to their issue tracking software (e.g., Jira).
“I talk to many developers – some of them at Oxeye – and when I ask them about what information they need to fix vulnerabilities, the answer is always the same: ‘I need to understand where the vulnerability is in the application – the exact line of code – and how to reproduce it.’ So, we worked on giving them exactly what they need to quickly and effectively correct code weaknesses, in a way that’s seamlessly integrated with their tools and their approach to fixing bugs,” Vider noted.
Oxeye is a dev-centric tool that makes it possible to shift security left and put part of the ownership of application security on the developers, but without burdening them and impacting their ability to release code at a fast pace.
Making it easy to do the right thing is how steady progress can be made. Oxeye allows AppSec teams to find vulnerabilities long before they make it to production, and clear remediation guidance is what allows developers to prioritize security for cloud-native applications.
“Developers know how to write code, but they are not necessarily knowledgeable when it comes to security. Application security experts know security, but not necessarily how to write code. Oxeye’s advanced testing technology streamlines cloud-native security processes, thereby assisting once-isolated teams in their collaboration effort and proving them with a common space where they can communicate in a common language about security issues that need to be fixed,” Vider concluded.