How a Developer-First Approach Helps Ensure Effective Cloud Security | Idan Didi and Bipin Gajbhiye

Interested in sponsoring an episode like this with your target buyer?

→ Reserve your sponsorship here. ($2,575)

In this episode of Audience 1st, Dani Woolf, Idan Didi and Bipin Gajbhiye discuss an important topic that's relevant to all developers out there: how to work better with security without sacrificing speed. 

Security is an integral part of any software development process, but all too often, developers view it as a hindrance that slows down their work. 

We’ll be exploring some practical strategies security practitioners can apply to get developers to embrace security to more effectively secure the organization without compromising their work.

We'll also be taking a closer look at the concept of "shift left" and how it can help developers catch security issues early on in the software development lifecycle (SDLC).

Developers are using the cloud so it’s important to empower them with more security expertise and knowledge.

That’s why using developer-friendly tools is critical in order to have your organization protected. 

We need to remember that at the end of the day, we are not in the business of eliminating risks; our goal is to do whatever we can to minimize the risk. 

Brutally honest insights from Idan Didi, Head of Sales - Developer First Security of Check Point, Co-founder & COO of Spectral and Bipin Gajbhiye, Security Partner of Stripe. 

Guests at a Glance

💡 Names: Idan Didi and Bipin Gajbhiye

💡 What they do: Idan is currently the Head of Sales - Developer First Security at Check Point and Bipin is currently the Security Partner at Stripe.

💡 Noteworthy info: Idan Didi is also the Co-founder & COO of Spectral (acquired by Check Point), a developer-first cloud security company, focusing on code safety and trust, fast code scanning and providing a simple developer experience. Bipin Gajbhiye is also advisor for Callity, a curated cybersecurity vendor sourcing platform for CISOs

💡 Where to find them: Idan Didi and Bipin Gajbhiye

Episode Insights:

Passion for startups and deep listening drove Idan and his team to successfully create a tool that would prevent critical security mistakes while being loved by developers.

Idan Didi is passionate about startups and building things from scratch. 

His motivation to work in the cybersecurity industry comes from his love for startups, and the excitement that comes with creating something new. 

“I started because I love startups and the reason is that it's exciting to build something from scratch. It is exciting to help people get something they never got before.”

Idan noticed a huge gap three years ago: 

Developers were creating amazing things, but a single mistake could cause significant cloud security problems. 

So, he and his team set out to build a tool that would prevent critical security mistakes while being loved by developers.

As they started meeting with companies during their growth phase, they received amazing feedback. Idan and his team provided values that no one else had, and it was thrilling to figure out what customers needed and deliver it to them. 

Things progressed quickly, and within a couple of months, they landed huge logos and raised a significant amount of money. 

However, Idan had to learn quickly how to sell their product and talk to customers effectively. Within a year, they had landed major clients from some of the largest enterprises.

Idan's passion for building startups led him to create a tool that would prevent critical security mistakes while being loved by developers. 

His team's unique values and quick learning allowed them to gain significant momentum and land major clients in a short amount of time.

Idan says, “we gave value that nobody had. And it was super exciting to figure out what people need and then deliver it.” 

Bipin cites his love for the excitement and challenges of application security as motivation for working in cybersecurity

Bipin is a seasoned security professional with over 12 years of experience in Application Security. 

He currently works at Stripe as a security engineer and security partner in the security partnership team. 

Throughout his entire professional career, he has been focused on AppSec, starting with consulting and then moving into product companies. He has worked for industry giants like Oracle and Salesforce before landing at Stripe.

According to Bipin, security is an exciting field that is full of challenges and rewards. The more he learned about security, the more he was drawn to it. 

As a security engineer at Stripe, he faces new and exciting challenges every day. The dynamic nature of the industry keeps him engaged and motivated.

Bipin's enthusiasm for the ever-changing nature of the security industry is a common theme among professionals in the field we hear on Audience 1st Podcast.

“I think security is very much fun. The more I learned about it, the more I got carried into it. Being a security engineer here every week is not the same, it brings different challenges every day. So, yeah, I love what I do and I like that excitement,” states Bipin.

Security experts are passionate about the challenges of the job, the need to break things to build them back up, and the thrill of solving complex problems.

Navigating economic market changes, balancing product development with less resources, and more aggressive growth goals are among some of the challenges Idan and his team face.

According to Idan, he and his team are still in startup mode, even though they are now part of Check Point. 

The team is still building things organically, but the current economic macro changes have impacted the market in the past few months. 

Everyone is trying to save money by consolidating everything into one tool. As a result, their approach to product development has shifted.

“Everybody is trying to save money by getting everything in one tool. So, if before as a startup we wanted to be best at one thing, now we’re trying to be good at many things. And the balance between the two is super challenging. It's not easy, you can't be the best in everything. And obviously the goals are getting much bigger,” says Idan.

They used to focus on being the best at one thing, but now they are trying to be good at many things, which is a challenging balance to strike. It's impossible to be the best in everything, and the goals are becoming bigger.

Idan notes that getting the next customers and developing new products is becoming increasingly challenging in today's market. 

Every month presents new hurdles that they must overcome. It's a huge challenge for him to figure out how to get to the next type of products and gain more customers.

The constant challenge of staying ahead of security breaches that could have customer, material, or financial impact is Bipin’s challenge.

Stripe, being a financial organization, places a great deal of importance on information and application security. 

According to Bipin, who works as a security engineer at Stripe, security breaches are a constant concern for him. Specifically, he worries about breaches that could have a customer, material, or financial impact.

“Whenever there’s a new security breach coming, anything which I'm responsible for or in terms of security that could have a customer impact or that could have material impact or financial impact - that's what keeps me up at night,” claims Bipin.

Bipin is responsible for a significant amount of security at Stripe, and he faces new challenges every week. 

The never-ending game of staying ahead of potential breaches is a significant source of stress for him.

As an application security engineer, how does Bipin choose what to prioritize first to stay ahead of potential breaches?

Bipin prioritizes his work based on the severity of potential threats. 

Bipin is more involved in the early stages of security, such as pre-production and design and architecture reviews. 

However, every few days, something new comes up in the industry, making it challenging to keep up with the constantly evolving landscape.

“Even if you just talk about the shift left part of things, every couple of days there is something new coming out. One day something, next day something else. It's hard to keep up with everything's going on.”

Bipin notes that his ultimate goal is to minimize risk, not eliminate it entirely. As such, he does what he can to minimize risk based on the potential impact and severity of the situation. 

When deciding what to prioritize, he asks himself if it really impacts his operations and what the severity of the situation is. 

Overall, Bipin and his team must balance the constant influx of new security challenges while prioritizing based on potential risks and impacts.

What is Developer-First Security? 

Developer First Security is a recent shift in security practices that focuses on empowering developers to own the security of their code and find vulnerabilities early on. 

In the past, security tools were designed primarily for security personnel and the tools were often slow and not user-friendly for developers. 

However, the increasing use of cloud infrastructure and infrastructure-as-code means that developers have more power and responsibility and they need tools that are friendly to them.

Idan notes, “5 or 10 years ago if you’d look at security tools, they were trying to solve security concerns and who would be the customer? The security guy and you need to keep him happy. You need to give a tool that basically alerts when something happens and give the ability to fix it. But there is a shift in the world. Developers are starting to use the cloud. They have AWS, they have Microsoft. They use infrastructure as a code, and they're starting to get a lot of power. And with that power comes the responsibility and the responsibility is not to risk the organization.  The available tools weren’t basically “developer first” meaning they weren't developer user friendly. It was actually very annoying for developers to use those tools since they were super slow.”

Spectral is a great example of a company that focuses on making security tools friendly and accessible to developers.

Why “first”?

The goal is to shift security from being reactive to being proactive, where developers take ownership of security issues and vulnerabilities. 

According to Bipin, “developers are not waiting for security engineers to get an approval, they can push code to production and take care of security by themself and own it. Of course they are not fully responsible for the security, but the developers should feel empowered to make decisions and there should be tools in place, automation where it catches issues as they’re writing code.”

The traditional approach involved security engineers reviewing and approving code, but the Developer-First Security approach involves empowering developers to make decisions and giving them the tools and automation to catch issues as they write code.

The idea is to shift security to the left, meaning that security concerns are addressed as soon as code is pushed, rather than waiting until later stages of development. 

This approach requires a shift in mindset and an emphasis on empowering developers with more security knowledge and expertise.

At Spectral, they strike a balance between developer ownership of security and the involvement of security engineers.

Developers get alerts and can fix issues quickly, while alerts are also sent to the dashboard for security engineers to review. 

“The way we looked at it in Spectral we said, okay, the developer owns security, has the ability to get an alert and fix an issue in a very quick way as part of its workforces but in the same time, an alert is sent to the dashboard for the security engineer. It was fixed. It wasn't fixed, it was clicked, whatever it is. And this way there is a balance between the ownership,” said Idan. 

This way, there is a balance between ownership and collaboration between the two teams.

3 Prescriptive Ways Security Practitioners Can Help Developers Become Champions in Shift Left Security

One of the challenges of implementing security initiatives is the potential knowledge gap among developers. 

To address this, security practitioners can take several steps to help developers become champions of shift-left security:

• Provide developers with security guidelines

Developers are aware of risks, but they don't always have the time to check if they are using the right open source or to check for potential security vulnerabilities.

Security practitioners can provide developers with security guidelines and standards to follow during development. 

“Their KPI is to develop fast so they don't always have the time to check if they’re using the right open source so they just write code. 

We need to provide developers an easy way to tell them, “Okay, guys listen, you chose the wrong open source; instead of this one, please use this one” or “Please note that there is a secret or a password that you just exposed to the organization before you continue,” says Idan.

These guidelines can include requirements for secure coding practices, authentication, access control, and data protection.

But, simply identifying a security issue without providing guidance on how to fix it is not enough.

• Provide a “playbook” on how to fix identified issues

Security practitioners should provide developers with clear guidance and actionable steps on how to address any identified issues. 

Bipin says, “if we just told the developer there is a problem, that's not enough because now he needs to go and investigate how to fix it. This way you are wasting the developer's time, they get annoyed, lose attention and will not be using the tool. 

We really need to tell them how to fix it. So, we need to either give them a playbook or a ‘couple of clicks here and this is how you fix the issue.’ 

That’s when the security teams come in place where they provide the right guidance, the right call to action for fixing issues and not just give general guidance. At the right point in time, guidance is very important.”

• Provide developers with the right [automated] tools. 

By providing developers with the right automated tools, they can quickly identify any security risks or potential issues without disrupting their workflow. 

These tools can help identify potential security issues early in the development process, enabling developers to address them before they become more difficult and costly to fix.

What’s more, they can provide a quick and easy way for developers to fix any identified issues without annoying or overwhelming them too.

“We want to give developers this ‘aha’ moment that there is something they need to do a little bit differently but without annoying them,” says Idan.

“Earlier I was talking about a lot of old generation tools,” said Idan, “and one of the things they had was a lot of false positives. The developer was really annoyed by getting many things that they needed to check. 

And because they had so many things to check, at the end of the day, they didn't have time to actually develop and they were turning off the tools. And they said, ‘okay, I know that there is some risk, but I don't have the time to actually start investigating everything.’ 

So, the tool that the organization should choose is a tool that at least 95% of the things that are the alerting things are things that actually the developer can choose. And by the way, this actually changes between one organization to another. Because some organizations can say we work with a very large bank, for example, and they said, "we want to make sure that no PCI and PI information is in the code.”

These recommendations will not only help organizations address potential security risks but also empower developers to take ownership of security issues and become advocates for security within their organizations.

What are the measures of success for developers focusing on developer-first security?

• Increased security program maturity

One way to measure the effectiveness of a developer-first security program is by looking at historical data and view how the program has matured. 

This can include data from sources such as bug bounty programs or third-party pen testing.

By analyzing this data, organizations can determine if there is an increase or decrease in vulnerabilities submitted by researchers, which can provide insight into the effectiveness of their security program.

• Improved code quality

Developers can focus on writing high-quality, secure code that is less susceptible to vulnerabilities. Post-production code scanning can also help identify issues that need to be addressed. 

By building a library or framework around these issues and providing developers with a clear route for addressing them, organizations can continue to refine their security program over time.

• Reduced time-to-deploy

By integrating security into the development process, developers can help reduce the time it takes to deploy new features and functionality. Measuring the time it takes to deploy new software releases can provide insight into the success of their security efforts.

Organizations must be prepared to constantly tweak their approach and make changes to their security program as needed. 

“It's an ongoing process over a few months or years to figure out whether this is working and you're always constantly tweaking things. There's no perfect security. Sometimes you have to go back, change a few things, change your approach,” says Bipin.

By regularly analyzing data and making adjustments, organizations can continue to improve their security posture and minimize the risk of security breaches.

How does Bipin choose security tools?

Choosing where to focus in terms of security is a complex process that involves considering multiple factors:

• Current trends in the industry, such as where the biggest threats are coming from, and how the landscape is changing.

When it comes to choosing vendors and data discovery tools, organizations need to consider:

• What existing tools they have
• What they are capable of doing
• Whether there are any new tools available that can do a better job more efficiently.
• Whether DevSecOps tools are developer-friendly and integrate smoothly with the rest of the toolchain.

Ultimately, choosing where to focus in terms of security requires a holistic approach that takes into account all the different factors and trends that are relevant to the organization. 

By carefully considering all of these factors, organizations can make informed decisions about where to invest their time and resources to improve their security posture.

What are some market anomalies to take advantage of?

• Velocity of code release increases the risk of security breaches

With the ever-increasing speed of code deployment, it's becoming easier for things to slip through the cracks.

“The velocity of pushing code is so much faster now there's release going on with every major company, every week, every day sometimes where some things can go unnoticed. That's something somebody can easily find out,” highlights Bipin.

• Secret management is a critical but an unsolved problem

“Many of the companies that we talk to have teams that are trying to mitigate this and are trying to make sure that there are no secrets. Before I got into this area, I thought that this was crazy. Why would somebody put a secret in the code? Like why would you even go there? It's supposed to be obvious that it's not supposed to happen, but still, it happens every day honestly, in every company we meet,” said Idan.

This is where companies like Spectral come in. Three years ago, they identified secrets as a major pain point in the industry, as key tokens and passwords were often left unprotected. 

While there were existing tools for infrastructure and open-source vulnerabilities, there was a lack of focus on secret protection. Spectral has since made it their mission to protect secrets throughout the SDLC.

• Open source code reuse poses a challenge in identifying and fixing vulnerabilities

Using open-source code has become a common practice in software development because it saves time and effort. However, there are potential risks associated with this approach. 

Many developers are using pre-existing code libraries, but it can be difficult to identify which functions or lines of code are being used. 

This can make it challenging to pinpoint and fix potential vulnerabilities in the code. 

It's crucial to have a system in place to track open-source code usage and make sure that libraries are regularly updated and secure.

“When we started, we were a new company and didn't have any customers yet. We used to go into companies and tell them that we can find their secrets and stuff. Usually they would say that there’s no budget or it's not the right time or they don’t want to deal with a startup. 

So we offered a deal to one public company: “Listen guys, we scan your public code, only your public code. If we find something interesting, we get you as a customer” and they agreed. 

It took us less than 24 hours, and we came back to them with a report showing everything they had. That was the first logo we got in the company. And as a startup, this is an amazing moment,” said Idan.

What is Spectral?

Spectral is an engine that scans any type of code to identify potential security breaches, regardless of the coding language or where the code is located. 

Spectral's focus is on identifying everything that can cause a security breach. The engine initially started with scanning for secrets, passwords, and other sensitive information. 

The second layer added was infrastructure as code, where the configuration of Kubernetes, Terraform, and log systems are scanned for best practices. More recently, Spectral added a layer to scan for open-source vulnerabilities. 

As part of Check Point, Spectral is now available on the Check Point dashboard, integrating with whatever tool developers use and giving alerts through Slack and PagerDuty. 

Spectral aims to be developer-friendly, allowing developers to keep their preferred experience when developing code while providing security teams with visibility and the ability to allocate issues to specific teams without having to micromanage the process.

“On one end we give the developer the ability to keep the experience that they have when they are developing code in whatever tools they're using, they are getting their love there. They know what to solve, they know how to solve it. But you, as the owner of security, you get visibility, which you probably didn't have before,” said Idan. 

How does Spectral make scanning more efficient and reduce cases of false positives?

• Build very strong research team

Spectral boasts a very strong research team that reverse engineers the type of software that developers build and use to build detectors based on those mistakes. 

“Here in Israel, a lot of people in the industry have a military background so we basically can reverse engineer the type of software that developers can build and then we build a detection based on that,” noted Idan

• Combine machine learning models with the research

“On top of that, we have machine learning models based on scanning public code and we combined the machine learning with the research to get very, very low false positive results.”

• Spot different use cases

To accommodate this, Spectral allows users to run the tool in multiple ways depending on their needs.

“The second thing we understood when we started helping large customers is that one of the ways to reduce those false-positives is to be able to spot different use cases. 

“Because when we talk about false positives, one person can look at something and say, this is a terrible false positive. And another person can say, ‘this is something I'm interested to know.’״

For example, security personnel, developers, and auditors can all run Spectral with different commands, which helps reduce false positives and ensures that the alerts are relevant to the user's specific needs.

What is the difference between Spectral's scanning approach and that of other binary code scanning tools, particularly in terms of focusing on secret reduction and infrastructure code rather than multiple types of SaaS issues?

Spectral customers download a binary file to their local machine or cloud and run the scan locally.

“We provide our customers with our scanner and they run it locally. All the data remains on their premise. And that was something we thought was very important and that also helped us not be responsible for our customers’ code. We just give them a fast and efficient tool,” said Idan. 

Spectral does not check for all the types of SaaS issues because it could lead to many false positives and could be a bit slow.

Instead, they focus on other areas that are more concerning, such as secret reduction and infrastructure of the code. Spectral is a static code scanner that scans all the code residing on your machines or cloud. 

Last takeaways

We hope that this episode got people to understand that being developer-first and using a tool that is developer-friendly is critical to have the organization protected. This will enable you to get people inside the organization using the tool, protecting the organization and making sure that everything is done in the right way.

Interested in sponsoring an episode like this with your target buyer?

→ Reserve your sponsorship here. ($2,575)