Cybellum was founded because there’s an industry blindspot around vulnerability detection. Software vulnerabilities aren’t detected soon enough, assessed for risk well enough, and fixed quickly enough to deal with the rising tide of new threat actors – all of whom are looking for weaknesses to exploit.

The entire conversation around vulnerabilities, and their impact, is dictated these days by marketing departments rather than by engineering. Creating a brand that can withstand publicized breaches is oftentimes considered as important as making products actually safer, if not more so. Part of the reason for this kind of thinking is the the perceived inevitability of an attack, no matter the investment in security.


This leads to a vast perception difference between in-the-wild vulnerabilities that make headlines, and vulnerabilities that are discovered during development. Caught by the QA department, the perceived value of a vulnerability to the developer is close to non-existent – just another day in the office.

As soon as the product ships, everything changes – each vulnerability is publicized, and priced, very differently. Vendors are willing to pay tens, or even hundreds of thousands of dollars, for these bugs.

Yet from a purely engineering standpoint, there’s very little difference between a vulnerability that’s out there in a shipped product, and one that’s caught prior to release. Both are bugs with impact on product security. Specifically, vulnerabilities are errors in either programming, logic, judgement or configuration that make the program more vulnerable. All of them are preventable, and most of them are discoverable after they’ve been implemented.

Vulnerabilities that weren’t caught during development aren’t necessarily more difficult or expensive to discover than the ones that were discovered and fixed – it’s the sheer number of bugs in commercial software that makes hunting for each one of them prohibitively time-consuming without automating and scaling the process.

At Cybellum, we’ve identified three points which a next-gen product for vulnerability detection should improve on:


VULNERABILITY DETECTION IN COMPILED CODE

Searching for vulnerabilities in compiled code is far from easy, and today still a mostly-manual process. A good input generator (fuzzer) will be able to find some conditions that cause the program to crash, but understanding what happened will still require a specialist.


VULNERABILITY DETECTION IN COMPILED CODE

Searching for vulnerabilities in compiled code is far from easy, and today still a mostly-manual process. A good input generator (fuzzer) will be able to find some conditions that cause the program to crash, but understanding what happened will still require a specialist.

RISK ASSESSMENT CAPABILITIES

Startups, in their attempt to be lean, usually write very bad code, which upon integration into a bigger system elevates its risk. Even larger organizations sometimes mess up. Yet oftentimes, integrating 3rd party code into a product is done without thorough review and risk assessment.

SPEED AND INDEPENDENCE

Developers, and DevOps teams, don’t want to complicate their processes. Any new solution for vulnerability detection and risk assessment can’t be a bottleneck. It should be able to perform both in the cloud and on-premise, and provide accurate results quickly.

SPEED AND INDEPENDENCE

Developers, and DevOps teams, don’t want to complicate their processes. Any new solution for vulnerability detection and risk assessment can’t be a bottleneck. It should be able to perform both in the cloud and on-premise, and provide accurate results quickly.

It took us a while to reach the point of being confident about our ability to address these three points well enough, but these days, when we’re reporting 5 vulnerabilities every week to vendors on whose products we test during development (Microsoft, Adobe, Apple), we feel ready to tackle the issue head-on. In the coming weeks, we’ll explain more about the technology we’ve implemented.

Want to see how Cybellum can find vulnerabilities in your product and assess the risk of 3rd party products you’re considering integrating? Talk to us.