Oxeye Brings Multilayer Approach to Software Security Testing
In cloud native environments, the usual alphabet soup of application security testing tools just don’t cut it anymore, according to Dean Agron, cofounder of Israeli-based Oxeye, which is forging a different path.
He’s referring to SAST (static application security testing), DAST (dynamic application security testing), IAST (interactive application security testing) and SCA (software composition analysis).
“The application security testing landscape, today it’s very fragmented,” he said. “You can’t have just one solution. You need a static one with a dynamic one. You may need an interactive one … So you need a full suite of products.”
Oxeye is bringing those capabilities together in one tool, as well as answering developers’ most-asked question: “In exactly which line of code do I find the vulnerability?”
The 15-person startup, launched in early 2021, unveiled its Cloud Native Application Security Testing (CNAST) platform in November, and announced general availability recently at KubeCon EU in Valencia, Spain.
Because modern applications are distributed, they have many components built by multiple teams in different times deployed in different times. Today’s solutions were not designed for distributed environments, which results in lack of visibility and too much noise, he explained in an interview at KubeCon EU.
“Lack of visibility means that today apps engineers and managers are expected to govern the risk of applications, but they do not have a real full picture of the building blocks. On top of that, when you use static scanners on highly distributed applications, the result is that you see many vulnerabilities that may exist in theory, but they don’t really exist in real life, because the code is not executed, or it’s not accessible from the internet, or the security measures are implemented in a different path of the application. With that lack of visibility, that noise of vulnerabilities eventually creates a lot of frustration,” said Agron, the company’s CEO.
Oxeye is deployed as a container as a daemon set with one Kubectl command into your testing or staging environment. You don’t have to change anything in your code, in third-party packages or in the infrastructure configuration. This container, called the Oxeye Observer, collects data from the customer’s environment.
CTO and co-founder Ron Vider explained the multi-step process that follows:
The first step is to understand the way the application is built from infrastructure perspective: the container, the cluster and the cloud.
The second step is to detect and locate potential security issues in the custom code written by the developers and third-party packages.
“The observer will explain each one of the different microservices in the environment, then using a static approach based on the files on the file system, it detects security issues,” he explained.
The third step, because modern applications usually are built on microservices architectures, is to provide flow tracing and understand the way the microservices communicate with each other. It uses the Cloud Native Computing Foundation project Open Telemetry for this.
“An example flow can start in the external API that is exposed to the internet and then it goes through different third-party components like message queues like Kafka, Rabbit MQ, SQS, s3 buckets or even direct connections using HTTP or gRPC,” Vider said.
In step four, based on the first three steps, it sends active payloads to the environment to analyze the behavior of the application at runtime, automatically creating and executing security tests to validate vulnerabilities prior to reporting.
“It sends all this data to our SaaS platform that is responsible to stitch it all together and prioritize the vulnerabilities based on the real risk by exposing the entire application with the context between the microservices and between the infrastructure layer,” he said.
The final step is to give the results to the end user, which if it’s a developer, it could be a message on Slack, an issue on GitHub or a Jira ticket. It points to the exact line of code where the vulnerability lies. Alternatively, there’s a dedicated dashboard for web application security teams where they can gain visibility into which vulnerabilities exist in their cloud native applications.
Because Oxeye analyzes the application, it provides full dependency tree of which packages and services are running, when they were developed, by whom, and under what license — a full dynamic software bill of materials (SBOM).
Visibility at Runtime
When asked about that cliched phrase “shift left” and whether runtime was the time to be concerned about vulnerabilities, Agron took a “shift everywhere” stance — that security should be a focus at every stage.
“On the one hand, there should be a code of policies on secure coding, or for developers to deploy or commit to the code repository. On the other hand, when looking for vulnerabilities, doing that in a distributed environment, without understanding the context of the relations between the components, you get lost because you’ll have too many vulnerabilities,” he said.
“So our position is quite radical. I’m not saying to go right to production, but the moment you have a pre-production environment, staging environment, the runtime environment, this is where you can focus on the exploitable vulnerabilities because you’re able to find them and point them out. And that’s where we are.”
They point to rivals Snyk, Checkmarx and Synopsis as their closest competitors, though they peg them as “mostly static,” while some up-and-comers like StackHawk are more focused on dynamic testing.
“Our disruptive approach is that we work in multiple phases, where we start with the static, but then on top of that, we add additional layers. We add the application flow tracing; we add the infrastructure analysis, which are cloud native layers; and eventually, we offer the dynamic piece, and that gives a much [more] comprehensive analysis than just static or just dynamic, and that this is what we see is our core advantage,” Agron said.
Releasing Open Source Tools
Agron and Vider launched the Tel Aviv-based company in early 2021. Agron comes from stints as security analyst and software engineer at KayHut, Imperva and Check Point Software. Vider previously was a security researcher for Orca Security and the Israeli Intelligence Corps.
Oxeye emerged from stealth in November and announced a $5.3 million seed round led by MoreVC, a seed-stage venture capital fund in Israel.
In January, the company released Ox4Shell, an open source tool released in the wake of Log4J exploits that exposes hidden payloads being used to confuse security protection tools and security teams. It’s designed to help security teams more clearly understand what threat actors are trying to achieve and what they can do to thwart them.
It’s said to be the first of several such tools the company will be releasing this year.