There’s not much Clint Gibler, Head of Security Research at Semgrep, doesn’t know about global cloud security trends. A well-respected industry thought leader, Gibler is also the co-founder of the tl;dr sec newsletter, which curates and summarizes the latest security tools and research each week.  

Gibler recently joined CloudSec 360 to share actionable insights on building a market-leading, scalable security program. During the session, Gibler discussed how security culture is changing and new ways to manage risk. Here are some of Gibler’s key takeaways about customer-centric security and how to put it into practice. 

Software development is sprinting, now security must too 

The pace of innovation has accelerated exponentially in the last decade, thanks to the adoption of developments such as cloud containerization and infrastructure as code. Containerization enables new apps to be built in isolation as fully packaged products, which can then be shipped quickly, securely and with minimum friction – while infrastructure as code eliminates the need to manually manage IT. 

The result is that DevOps teams can now drop daily – rather than quarterly – software updates, enabling firms to respond to user feedback, fix bugs, and innovate faster than ever.  

This acceleration in software shipping times creates big challenges for security teams, however, who must develop new strategies to execute at speed or risk being seen as a blocker of innovation. 

Gibler says that to keep pace, security teams must undergo a mindset change, working closely with engineers and developers, treating them as customers and treating security as a customer-focused product.  

What does customer-centric security look like?  

Gibler stressed that security teams should add value for everyone within an organization. They need to collaborate with developers and engineers, rather than expecting them to endure separate user interfaces for security tools, workarounds and barriers. A proactive approach in which security teams add value for multiple stakeholders is the way ahead.  

“Many security teams now realize that building (tooling, libraries, automation) adds a lot more value than finding bugs and breaking things,” he says. “It’s the difference between helping stakeholders do the right thing, rather than acting as a gatekeeper and preventing people from doing what they need to do.” 

Four initial steps towards a customer-centric security function 

So, how do you shift your team’s focus from bug hunting to becoming a customer-focused springboard for innovation? Gibler suggests that all security teams should consider the following four steps on their transformation journey:   

1. Create self-service resources with security baked in

   Security teams need to shift their focus from finding bugs and vulnerabilities downstream to introducing security-by-design at the development front line. This involves creating the tools and resources that dev teams need to accomplish their goals with security baked in. Try to befriend the Platform Engineering team, or whichever team creates software for the rest of your organization - this can be a great way to get security controls built in to standard tools and libraries across your company.

2. Embed staff across teams 

   Consider initiating a rolling program of job swaps between security, DevOps and engineering to grow a customer-centric security function. Security team members can be embedded in DevOps or engineering for six months: Gibler shares, “They should be taking tickets, building out features, shipping code for production and doing exactly what developers are doing” in order to break down silos and build empathy. This also works in the other direction, with an engineer doing a stint on a security team. 

3. Ensure security is easily understood and consumed

   Systems and processes should be designed to encourage secure behavior. Wherever possible, it should also be “as easy as clicking a button or reconfiguring a line of code,” says Gibler. “If developers aren’t behaving as the security team wants, it’s not because ‘they don’t get it’. It’s because the value proposition hasn’t been made clear enough, or they have to take too many additional steps.” 

4. Build shared capabilities 

   Consider how security initiatives and tools can deliver value across the organization. For example, building an asset inventory is valuable for security teams in knowing what to protect, but it can also help finance understand your cloud bill and engineering knows which teams own what services. Similarly, security teams can use code scanning to find vulnerabilities or opting out of secure defaults, and engineering teams can use it to enforce coding standards or do code refactoring at scale. 

View the full CloudSec 360 session, featuring Clint Gibler, now for more actionable insights on building a scalable security program so that you can ship software quickly and securely with minimum friction.