Aviva Zacks of Safety Detectives got a chance to sit down with Nuno Loureiro, CEO and Co-Founder of Probely, to ask him all about his motivations to start his company.
Safety Detectives: What motivated you to start Probely?
Nuno Loureiro: In my past professional life, I led an APSEC team at a telco operator for about six years, and we struggled with scaling application security. I created that team at the telco operator in 2010 together with Tiago (today Probely’s CTO), and I led the team until 2016 when we left to create Probely.
The problem we had was that there were only two people in the APSEC team in the beginning. On the other side of the table, there were over a hundred developers and over a hundred web applications being actively maintained. Some of the teams started following agile development methodologies, which resulted in frequent releases of new versions of the applications. Because of that, we struggled in performing security testing because it was hard for only two people to test all the changes produced by 20, 30, or 40 dev teams. If there are frequent releases of the apps, we have to test them frequently before each release. And even though we used automated tools to help us with that task, it was still two people operating the tools to test the security of over a hundred web applications.
Back then, in 2011 or 2012, the only way that we saw to scale this was if we could shift some of the automated security testings directly to developer teams.
Today, people talk a lot about shift security left, which is shifting the security testing to an earlier stage of development—shifting those tests directly to the developers. But back then, there was no fancy name for that.
The problem was that most of the tools that were in the market back then were built to be used by security professionals, not developers, so developers struggled a bit using those tools. A lot of the tools required fine-tuning in terms of configuration to make sure that the entire application, the tests, or the coverage of the tests were good. Those tools didn’t really provide good explanations about what the vulnerabilities were or how to fix them.
The idea to create Probely was born from that experience. My application security team and I decided to create Probely so that it would be easier to offload some of the security testings directly to development teams. We built Probely with that in mind.
SD: What does Probely do exactly?
NL: Today, we have two products: a standard edition and an enterprise edition. The core of the product, of both versions, is the same. The engine to find the vulnerabilities is the same. It’s just that one product is targeted at companies that have a small number of targets—a small number of websites, web applications, or APIs. And the enterprise edition is targeted at companies that have many websites, applications, or APIs and require a complementary set of features.
The way Probely works is that you have a web application, and you provide the URL of that web application. Probely scans the web application, and along the way, while it’s scanning, as it finds vulnerabilities and security issues on those sites, it reports them. It provides full details about what’s vulnerable, the impact of that vulnerability, and proof that the vulnerability is real. It also provides instructions on how to fix the problem, the issue, or the vulnerability.
For some technologies, we even provide tailored instructions on how to fix those issues. Imagine, for instance, that your application is made in PHP, so you get a snippet of code in PHP on how to fix that particular vulnerability.
Probely works pretty much like a hacker. The client doesn’t need to provide any code. Instead, Probely will just go to the website or the web application and test the application like a hacker would and try to find vulnerabilities.
SD: What keeps your company ahead of the competition?
NL: There are many competitors in this space, but I think what differentiates us from our competitors is in the details. From the beginning, we wanted security teams to be able to shift security testing to developers, so we’ve made the product from scratch to target that use case.
Just to give you an example, we follow an API-first development approach. So, for every new feature of Probely, we first add it to the API, and then we add it to the interface. This is a good thing for dev teams. If they want to integrate Probely into their existing tools and workflows, they can use our API, and they know for sure that whatever they are looking for in terms of functionality is going to be available on the API.
Our competitors first created their product, and then, to target developers, they built an API on top of their product with the functionality that they think is important to provide. And sometimes, what they think is important is not what the client thinks is important. But, with Probely, they know they have everything on the API.
Another example is that we were users of tools like Probely in the past for many years, and we know that these tools usually report a lot of false positives. So one of the things that we did to avoid false positives was to safely exploit the vulnerability to gather evidence that the vulnerability is real.
Another thing is that we provide tailored instructions on how to fix the vulnerabilities based on the technology that is being used on the site.
And we could go on and on. These are just a few examples.
SD: What do you think changed in cybersecurity since the start of this pandemic?
NL: We definitely saw a spike in attacks since the pandemic started. Many companies had to loosen up some security controls since employees started to work from home from one day to the other. Thus, the notion of the security perimeter had loosened up as well, if not faded away. This created new opportunities for different areas of security, such as network security, identity management, and access controls.
In terms of application security, we saw an increase in attacks, especially at the beginning of the pandemic. One possible explanation is many people were at home, either working or doing nothing (less control of your activities and/or more free time), which created the ideal environment to start hacking.