In the cloud-native era, security founders often find themselves serving two audiences: security buyers and engineering users. To help founders navigate the dynamic between these roles, we got the inside perspective from security leaders.

‍

Securing cloud-native infrastructure and applications requires closer ties than ever between security and engineering. Security teams are responsible for setting policies and defining priorities that protect the company’s infrastructure, products, and devices. Engineering teams — as the owners of the infrastructure and products — are on the front lines of putting those policies into practice to ship and maintain secure software. 

‍

Collaboration is essential in two key areas. First, security relies on engineering teams to find and fix security issues before code is deployed to production. This is referred to as “shift left” security and usually involves integrating security tooling into the software development process. Second, security relies on engineering to remediate misconfigurations and vulnerabilities in infrastructure and applications. Security teams often consume and prioritize the alerts, but deploying the fixes requires involvement from the engineering teams that own the affected infrastructure.

‍

For security founders, identifying the right buyer and user personas for your product is critical to achieving product-market fit. As companies adjust their processes, priorities, and even org structures to rise to the challenge of securing cloud infrastructure and applications, understanding the roles played by both security and engineering is key. 

‍

An Unusual Question No. 2 for CISOs

‍

To provide some perspective on how the collaboration between these teams is evolving, we posed the following question to security leaders at HubSpot, Samsara, and Momentive: How are you working with engineering leaders in your organization to drive better security outcomes?

‍

Brent Williams

CISO, Momentive

‍

On building trust between security and engineering…

Security and engineering often experience a tense relationship, as traditionally security has been seen as slowing things down or preventing engineering from moving forward. What I’ve found works well is to build a strong relationship before making requests. The relationship should be built on a shared context, where each team is able to present their point of view on the situation. This foundation helps drive future conversations when discussing the when and how of addressing security requests.

‍

Engineering teams have a lot in front of them, especially in startups where people are playing multiple roles, so I find that explaining the “why” behind what we are trying to achieve helps create a shared context. This also opens the door for discussion of how we will approach the problem and get things done together, as opposed to a “throw it over the fence” approach. This also goes a long way in building a trusting relationship.

‍

On where strong collaboration with engineering can improve security outcomes…

Early in the process. I find that focusing on the foundation (e.g., libraries, infrastructure) and addressing issues early in the build process minimizes the issues (e.g., vulnerabilities) in production. This also reduces the load on downstream tools and requests. For example, issues addressed at build time reduce the number of findings (and, ultimately, money) produced from a bug bounty program. And we all know that bug bounty programs, especially earlier in their maturity, can be very time-consuming for security and engineering.

‍

On engineering’s involvement in selecting security products…

In our organization, Trust & Security sits outside of Engineering. So it would be easy for us to purchase whatever tool fits our needs. However, that isn’t the most collaborative approach and tends to build resentment, especially when the security tool is difficult to implement or causes production issues. 

‍

The way we approach security tool procurement is to define our requirements and then share them with our engineering peers to seek feedback. Once we have this feedback, we look for the right solution to PoV (proof of value). In many cases, engineers are the consumers of the data coming out of security tools, so it’s important they have representation in the PoV. Their involvement early in the process often leads to more confidence in the results and findings, and makes for an easier conversation about driving to a resolution. 

‍

Alyssa Robinson 

Deputy CISO, HubSpot

‍

On organizing for alignment…

At HubSpot, we are in the unusual position of having security be a part of the Product organization. This has many advantages: it allows us to truly understand the tools and workflows used by Engineering, so that we can develop security solutions that are low friction for developers. It also creates a common experience and vocabulary between the teams, eliminating many of the barriers I've seen in the past to Security and Engineering working together. 

‍

On building security systems for developers…

HubSpot has invested a ton into creating a fully featured platform that makes it easy to create new features for our customers, but having that custom platform often means that commercial off-the-shelf security tools can't just be configured in our environment without some custom integration. Ultimately, as a SaaS company, our security program is highly focused on protecting our customers' data, and this very close relationship between Security and Engineering ensures we're well-placed to do that. 

‍

As part of our privacy program we conduct a yearly Data Asset Inventory to ensure we have an inventory of services that process personal data. This used to be a very manual, survey-driven process for our team leads, but our team was instead able to build a system that pulls from multiple sources in our infrastructure to give developers good default answers and reduce the effort and time associated with the process. Additionally, we are currently building a system that helps ensure least privilege in our infrastructure by tracking and automatically removing unused permissions. 

‍

Dave Bossio 

CISO, Samsara

‍

On aligning to grow the business securely…

At Samsara, security is a priority for the company, and our board and executives see it as a differentiator for our company overall. I meet with Engineering leadership frequently to talk about shared goals and objectives, blocking issues, what’s working, and what’s not. We have open and honest conversations about what we’re trying to accomplish. There will always be a productive friction because security investments need to be balanced against the product roadmap, customer requests, and other compliance requirements, but there’s a shared understanding that having the right security posture is an important part of how we serve our customers. As CISO, I need to be flexible in how I define and prioritize risk so we can appropriately balance security uplift against the engineering team’s ability to drive innovation. At the end of the day we’re trying to achieve the same goal: to grow our business securely.

‍

We’re much more likely to get alignment and interest from the engineering team when we can connect new security initiatives to business objectives. Simply telling the engineering team to deploy some random tool isn’t compelling for them. If we can say, this tool will help us get ISO Certification or FedRAMP certification so we can sell more products, then we have a shared mission we can rally around. 

‍

On introducing new security programs to engineering…

Security needs to understand the culture of the engineering team and how they do work. The more Security can understand the development process and seamlessly integrate new programs with engineering tools and workflows, the better. Every new program from Security is a mindset shift and a new training effort that you have to put into place. We’ve been most successful by understanding the engineering team’s process and not trying to do too much too quickly. There’s a lot of great tooling in the security space but none of it is completely turnkey when you start integrating it into the engineering process. It’s better to get one tool running robustly and well integrated, then expand on that, rather than pushing a bunch of new tools at once.

‍

On engineering’s involvement in selecting security products…

If we’re rolling out a new program that will impact their team, Engineering leadership needs to understand the value of what we’re doing and why we’re doing it. When it comes down to evaluating and selecting tools, we need to involve the operators on the engineering team who are going to use the tools and receive the output. They need to have input into the requirements. New tools need to fit with the existing tooling we are using for development, including CI/CD tooling as well as process tools like JIRA and Slack. Security ultimately owns purchasing decisions, but it doesn’t work if Security just dumps new tools on Engineering – partnership is critical here. 

‍

It’s incredibly important for the CISO and the Security team to have an appreciation for the development process. Having some background in software development is something I look for in my team members. You can be great at security, but if you don't understand how the products are built or have an appreciation for a day in the life of an engineer, you're not going to be as successful as you could be. It’s also a two-way street. I expect that, over time, our developers gain an appreciation for security and the challenges of being a security professional. 

‍

This is the second edition of An Unusual Question. Read the first edition: How startups should hire today, according to leaders of Square, Amplitude, Wealthfront, and more