What inspired you to start an IoT security company and how would you describe BugProve and its mission?

The situation we have all experienced as security engineers… But jokes aside, seeing for many years the endless fight when it comes to IoT security, it always felt like something was missing. Regulations were either missing, or fragmented, and the overall quality of the code on these devices was not at the standard you would expect. It was very difficult for manufacturers to navigate when supply chains were optimizing for unit cost only and there was no comprehensive guidance or regulation.

Legislation is now catching up, but there is so much work to be done it almost feels hopeless on human power alone. We felt there must be a smarter way to do this, so we started to work on a product that can automate some steps of the process. Long story short, we created a platform that can do that, one that is tailored for IoT and can actually go through the code and highlight potential issues at a much better accuracy than any other tool we know of. We wanted to make it available for the security community, so the free plan was launched on the 15th of February, and we are excited to get feedback!

Congratulations on the public launch! Can you highlight some real-world examples of how the tool will affect IoT networks and devices?

BugProve builds on tens of thousands of work hours we spent on IoT security research. We got quite good at pinpointing high and critical severity issues while manually auditing IP cameras, routers, TVs, smart meters, however, we often felt that the usual timeframe that vendors allocated for device penetration tests was not enough for really going deep into the analysis. We had to familiarize ourselves with the target device, collect different security relevant artifacts from its firmware, assess the severity of its open source software components and so on. We created BugProve to eliminate these tasks from manual analysis, so whoever is in charge of security testing can focus on the important parts.

The tool does all the things you’d expect from a firmware analysis tool, and more. BugProve tries to bridge the gap between embedded systems engineers, only dabbling in cybersecurity and hard-core IoT pentesters who live and breathe hacking on these devices, offering a unified solution. This is very ambitious, but we feel like there are already a couple of cybersecurity products out there that have acquired the trust of the developer and the security community alike, and we are trying to learn from them.

BugProve enters the software development lifecycle after QA testing and before deployment during the security testing phase. The security testing phase is often required to include a manual penetration testing of the solution and might involve checking compliance against a set of cybersecurity requirements based on the domain. The manufacturer of the product either executes this internally using a product security team or other internal security resources, or more often, an external 3rd party pentesting company is hired for carrying out a security evaluation. In either case, BugProve can be used to analyze the product firmware and drastically reduce the time spent on tasks that were historically very time-demanding and monotonous. However, it does not stop there, it also carries out code analysis that could enable manufacturers to get ahead of certain types of critical and exploitable (so called 0-day) vulnerabilities identified right away, or alternatively, it directs the attention of security analysts to vulnerable software components via its actionable alerts.

I’m obviously super biased here, but using BugProve, I myself could speed up my vulnerability research work by a lot - knowing the internals of the algorithm definitely helps, but we’re hoping that our recent public launch will prove that other independent security researchers and bug bounty hunters can utilize our free plan with success as well.

To highlight some of our real-world findings, we’ve already discovered a total of 30+ high severity vulnerabilities using the tool in publicly available firmware of different IoT vendors. This includes CVE-2022-24942, a high severity remote code execution issue in Silicon Labs’s main software SDK, which was fixed with a security advisory last September, and there are ongoing disclosure processes being coordinated with Honeywell, Broadcom, Netgear, and different IP camera vendors that we are not at liberty to discuss further.

Expert Question from Zoltan Padanyi: "Exciting project, seems like a unique IoT specific solution from hands-on professionals. Could you highlight the key differentiators and innovative features of your product compared to other SAST, DAST, IAST, and SCA products in the market?"

Great question, thank you! The difficult thing about IoT is that the technology stack and software ecosystem out there are super heterogeneous, complex and a lot less mature than in application development. The only common denominator is that most projects are built using C or C++ due to requirements on performance and the resource-constrained nature of these devices.

Although super expensive for enterprise use cases, we believe that there are good SAST tools for C/C++ that could be used for IoT projects, however these are completely agnostic to the IoT use case and usually configured to check compliance against certain secure coding rulesets. Our experience is that even seasoned C/C++ professionals have a hard time understanding these, and they especially have a hard time prioritizing between the classes of findings in terms of practical security risks. Another problem is that on large codebases, SAST algorithms either blow up in waiting times or result in a huge number of false positives. This results in alert fatigue, that is, the engineer or Product Security analyst tasked with fixing the vulnerabilities is going to feel hopeless looking at the 1337 issues displayed on the dashboard. Triaging results becomes especially grim after one verifies that a large percentage of the findings are not actual vulnerabilities.

BugProve does not require source code, instead, we take the fully built device firmware and take it apart. BugProve performs an educated guess on what parts of the firmware are third-party open source libraries, and which of them are proprietary, and it also pays special attention to networking code that might contain issues that have a higher probability of enabling Remote Code Execution vectors. For binaries that look proprietary, either owned by the engineering team of the manufacturer, or one of the corporations on the supply chain, such as the chipset vendor, BugProve creates a risk assessment. Using this information, we can run our code analysis engine PRIS on executables and libraries automatically, or guide the user in the direction of components that we find suspicious in terms of code quality. PRIS itself is a semi-dynamic security analysis engine that builds on cutting-edge ideas from academic research in program analysis, and its main objective is to identify those vulnerabilities that have the highest potential of becoming practically exploitable security weaknesses. That is, it eliminates a lot of false positives associated with SAST tools, it implicitly includes a contextual understanding of the whole device firmware thereby addressing the use case agnostic nature of conventional tools, and it really does focus on the important vulnerability classes that top security researchers report the most for IoT codebases.

It is easy to see that BugProve, as explained above, is also an excellent SCA tool for firmware binaries as it assembles SBOMs automatically and cross-references known vulnerabilities (CVEs) for outdated components. Competing SCA solutions that work on binary code have formidable pricing and are not at all tailored for IoT use cases specifically. Some leading SCA solutions in the application security domain only handle technologies and programming languages where there is an established package management solution, neglecting C and C++ as used in a generic IoT project.

Finally, DAST tools are predominantly web technology focused. A lot of embedded devices feature web interfaces where some techniques could theoretically be applicable, and we actually have ongoing research in this direction. However, completely dynamic testing approaches require a running firmware without access to the actual hardware, which is pretty difficult to do in the embedded Linux case, and almost impossible for devices powered by some kind of RTOS or bare metal code.

Tell us about the team behind the product and the technology you're using. Any hiring plans in the near future?

Attila Szasz was the first one to work on the core of the product. I joined a bit later, and then Balint Janvari too. He was followed by some of his former colleagues, so we were very lucky to get started with a team that was already used to working together. We have recently hired our first commercial team members. We now have about a year to validate our product-market fit, business model and pricing. As soon as we get a better sense of the current market, we plan to expand our developer team, because we have so many product update ideas, our roadmap is full for the next 2 years at the moment.

What are the biggest technical and legal challenges that BugProve faces and how does the team plan to overcome them?

I think the biggest challenge is that a day only has 24 hours. We have so many ideas, it is difficult to prioritize and ship as much as we want to. The most difficult element is the security specific product development. It is the core IP and very niche, you cannot find the necessary expertise easily. (After all, we are solving for the lack of experts on the market).

What do you expect in the IoT security space for the near future?

A lot of turbulence and last-minute action. Several huge regulations will come into effect in about a year or so, and most companies are not yet prepared. I believe they underestimate how much time it will take to get compliant. We expect it will be similar to what PSD2 did in the banking sector. It could rearrange the market, but I don’t think it will stop or even slow down the growth of IoT solutions.

How will the €750K funding received last year be utilized to further the growth and advancement of BugProve? Can you share your company's roadmap for the future?

We have a plan, but I must say, we expect that we will need to adapt it based on the information we will receive as we get more and more interaction with our potential customers.

Most of the funding will go into product development, for sure. We have a small sales/marketing budget, and the goal is to reach a niche of industry experts, so we will attend specific events, and build on social media and communities.