Apiiro wins RSA Conference Innovation Sandbox Contest

Security startup Apiiro is hoping to change how software is secured by looking behind vulnerabilities and compliance issues and analyzing the risks that cause them.

The company, based in Tel Aviv, Israel, and founded in 2019, was named Most Innovative Startup at this year's RSA Conference Innovation Sandbox Contest. Apiiro's Code Risk Platform doesn't analyze software for vulnerabilities; instead, the automated product scans for risky material changes, such as an alteration to the input validation, that may lead to a security bug or data exposure.

Co-founder and CEO Idan Plotnik said the company's goal is to revamp the secure development lifecycle (SDL), which has become bogged down with too many manual processes and too much vulnerability hunting. He launched Apiiro after spending several years at Microsoft as a director and group manager for software engineering, where he saw firsthand how challenging the secure development lifecycle can be to implement with limited time and resources.

Following Apiiro's win at RSA Conference, we spoke with Plotnik about those challenges and how the Code Risk Platform can help organizations get ahead of the risks and vulnerabilities in their software.

Editor's note: The following has been edited for length and clarity.

How did Apiiro begin? Where did the idea for a company like this come from?

Idan Plotnik

Idan Plotnik: I was managing around 250 developers [at Microsoft]. And we felt the real pain at Microsoft throughout the security development lifecycle. It was a real challenge because the original SDL at Microsoft was designed for on-prem, monolithic applications for a waterfall development model you release every three, four, five or six months. And then you need to go through your risk assessment questionnaires, security model reviews, compliance reviews, threat models, penetration testing, vulnerability scanning and so on.

And then you have a poor guy that is 1 for 200 developers -- the ratio is 1 to 200 -- that needs to handle all these processes and needs to run across every developer and ask, 'Can you answer this one? Can you validate that you're using this one?' and then go through all the vulnerabilities from the pen test and from the vulnerability scanning and triage them and say, 'Hey, there's 70% false positive here,' and then prioritize all these others and make sure that developers are fixing it. And, sorry for the language, but that's a pain in the ass. It's insane. As a general manager at Microsoft, for every release for an on-prem product every five months, I had to add at least a month, or even two months, to go through this process.

The pain started when first my boss, who had to bring some dollars to Microsoft, told me, 'Hey, Idan, we're not on time, what's going on? The business needs to move faster and faster.' And when we moved to Agile [software development], and we started developing our product that was acquired from my last startup [Aorato, which Microsoft acquired in 2014] to a cloud-native architecture. And we started releasing on a weekly basis, and then everything was a mess. I found out that the developers were lying on these questionnaires. We were releasing with risks and vulnerabilities, and I was told, 'You cannot attend them. You need to promise the customer to get these features as soon as possible, because a $10 million deal is holding up.' And the salesperson is telling me that we need to close it now. And I was the person who had to sign off on it before releasing code to production. And this is basically how Apiiro was founded.

And you found out other organizations were experiencing the same pain?

Plotnik: I can't even say the name of the company, but I went to a big bank, which was our customer. And I worked with them even before Microsoft. And I told the CIO, 'Hey, how you are handling all these processes since you are regulated organization?' And she told me this is one of their biggest pain points -- we're talking about two and a half years ago. She told me they were investing a billion dollars in a digital transformation project, moving to an Agile model and automating processes. And she said, 'Let's work together as a design partner.' And this is how everything started. I talked with 300 customers over the last two years. And I learned that this is a huge problem not only for large enterprises, but also for a shop with 100 developers. They want to move fast, and they need security. And there they have one person for that.

One of our customers wanted to build an appsec [application security] program and they asked us what they should do first. The answer is get visibility. You want visibility that is risk-based, and that is automatically generated without any human intervention.

Connect Apiiro to your source control manager and ticketing system; let it analyze everything throughout your history, build knowledge profiles across all your developers, learn your applications and what the risk factors are and then prioritize the work. We automatically identify your crown jewels as high business impact, and we identify the PII [personally identifiable information], and we see your 700 APIs and 50 of them are exposed to the internet. Let's find out and scan only those 50 APIs. Let's build a security champion program so that with three clicks, you can find out who is the developer on the team that is actively dealing with Java and has knowledge in security because he's changing authentication logic or authorization logic or input validation. Let's train them so they will be our go-to guys when we need someone to help us remedy the risks throughout the development teams. And this is basically what we are doing; we are covering every step throughout the appsec program or the secure development lifecycle, from design to code to cloud, across all your manual processes, across all your tools.

For a customer like that large bank, which may have already invested some money in pen testers and vulnerability management and added headcount for software security, is your platform going to help those people or is it designed to replace them?

Plotnik: The platform will prove to you, in a quantitative manner, how much you can do with them, while automating some of the process, so those [people] can do much more focused on the risks that really matter. We're not telling you to replace your pen testers, and we're not telling you to replace appsec engineers. But we are telling you to stop asking serious questions in your manual risk assessment questionnaire and eliminate them. They are based on self-attestation. Focus those people on the risks that really matter. We're doing more with the people that you have.

Automation has been a goal for a lot of security vendors for a long time. What were the challenges to automate this kind of process?

Plotnik: You mentioned that there are tons of vendors out there, and they're trying to find more vulnerabilities in the code. And we said from day one, we are not going to detect vulnerabilities in the code. We are taking a totally different, new approach. We said that everywhere, in every misconfiguration, everything starts from a risk chain, so let's identify risky material and changes.

So, for example, let's say you have developed a money transfer API, and someone else developed the API that exposes the list of ATMs, which is unauthenticated and everyone can see this data. In both APIs, you have SQL injection. Why do I care about the API that someone else developed? First, let's automatically identify that you developed the money-transferring API and change the logic of the API, which can potentially create a vulnerability, but if I show this to a person with the security knowledge early in the development process, he or she can identify vulnerability in one minute, and the static code analysis tool will never identify it because you remediated early in the development process. And this is what we are seeing when we are using the essence of risky material changes to contextually trigger a process. And it's different for every process.

For a security code review, I can trigger it based on a logic change of an API. But for a pen tester, I can't trigger based on a logic change. I need to configure it only for an internet-facing API that is sensitive, that exposes PII, for example. And compliance review is something that's triggered by totally different risky material. Vulnerability remediations also have different material changes. One of our customers was able to reduce their vulnerabilities by 79% with just one rule: show only vulnerabilities on internet-facing APIs that are sensitive. Why do I care that I have a SQL injection on an internal API between microservices, that it's behind my firewall, behind my cloud's firewall and behind my API gateway? If I have one person [for code review], I can't remediate all the vulnerabilities.

You mentioned APIs. What are some of the other risks you commonly see in customers' environments?

Plotnik: We are going to release research soon. I can't discuss all the details now, but we scanned 50 of the largest open source products out there and we found very interesting stuff. But I can tell you that it includes secrets in the code and logic change without proper without proper code review. The people that were doing the reviews for don't have the knowledge to review such sensitive changes. And we see a lot of APIs that are exposing sensitive information without proper authorization.

You mentioned time to market earlier, in terms of challenges for application security teams. What are some other contributors to risky materials ending up in software?

Plotnik: I will try to generalize the answer because it can be complex for small developer shops to medium shops and large enterprises. But there are three main reasons. One is that you have too many tools that lack risk visibility across on-premise and cloud applications, across the business impact and across the knowledge of developers. There are so many tools -- it's a cacophony and you have to handle the output of all these tools. The second thing is that you have a lot of manual processes -- the risk assessment questionnaires, the security code reviews, the compliance reviews and so on. And the third problem is the rationale that people can handle this or help developers remediate these.

Given all of the challenges you described earlier for enterprise application security, was it a challenge when you first started talking with customers and getting them on board with this idea? Did they understand it?

Plotnik: I must say, it was hard in beginning. And it depends on, again, the organization size and maturity of their security programs, but CISOs are always chasing the next SolarWinds or the next vulnerability. But when organizations move to Agile and cloud-native development, then the magic happens. I'd say about a year ago, a lot of CISOs started paying more attention to this when their code was being deployed in the cloud, and the velocity increased exponentially. And when the velocity of the development grows exponentially, then the pain for the CISOs suddenly starts and it becomes a priority. And everyone, every CISO understands that secure development lifecycle is a real challenge.