Key Priorities for CloudBees CISO

By Prakash Sethuraman, Chief Information Security Officer, CloudBees

Six months in at CloudBees and I remain excited about the future of software development. We are at a point in time when developers can literally release new applications quicker than ever before, and they can deploy new features and functionality to existing applications on a daily or even hourly basis with a DevOps ecosystem. It’s mind-boggling to think how far software development has progressed from the days of monolithic applications and waterfall development practices.  

As the shift to DevOps has taken hold over the last decade, CloudBees has set the standard for excellence in software delivery. The company is experiencing massive growth as DevOps and agile development are becoming mainstream. You may think I’m a bit biased when I say that after joining CloudBees in June as the new Chief Information Security Officer, or CISO as the role is often called.  

Actually, I can talk about the excellence of CloudBees from a customer perspective because I was a customer. Before I joined CloudBees, I was the global head of cloud security at HSBC, one of the largest banks in Europe. We used CloudBees for continuous software delivery, so I’m very familiar with CloudBees, and I can personally attest to that standard of excellence. CloudBees was a critical piece of our software delivery ecosystem, and it enabled our developers to build and deploy new applications and features for our customers. As my HSBC title implied, I was focused on cloud security, but I was also responsible for container security as we implemented both technologies across the organization.

It’s through the lens of security and DevOps that I’ll focus my attention at CloudBees. I’ll develop security strategies to ensure that our products follow best practices and adhere to rigorous compliance standards. I’ll have the unique perspective of customer and internal company leader. With that background, here’s where I plan to focus my energy and efforts.  

If you’re not familiar with this term, you absolutely should learn about it and understand it. It’s essentially all of the component parts of your software and the chain of processes you follow to create your software. It’s all the raw materials used in your application, including the code you create, as well as open source software, proprietary third-party applications and tools, binaries, builds, packaging scripts, and all of the dependencies necessary to run your software. It’s also the underlying infrastructure and even the automated build pipeline itself. All of these components and processes are points of vulnerability across your software supply chain that can diminish the overall security of your software—and that’s what creates risk for your company and your customers. I’ll develop strategies to help ensure CloudBees products contribute to a secure software supply chain.

One concept on which I’m particularly focused is traceability. If we think in terms of supply chains for food or drugs, we can easily understand traceability. When there’s E. coli contamination in lettuce, very quickly, we are told which product lots are affected, in which states and stores the contaminated products were sold, and from which farms the lettuce was grown. It’s the seemingly instant traceability that gives us peace of mind as consumers that weak links in our food supply chain can be identified. The same is true with pharmaceuticals when a manufacturer identifies a product tampering incident or a so-called “bad batch” of a particular drug. Although these things don’t happen often, we realize how important traceability is to keep our food and drug supply chains safe. I want to apply this same concept of traceability to the software supply chain—so we can easily and quickly identify vulnerabilities that pose security risks.

These concepts are a bit more nuanced, but equally as important, if not more so. I just described the importance of traceability to identify vulnerabilities in the software supply chain. But, then what? We must develop a protocol to track vulnerabilities at a very granular level. Of course, there are already products and processes that can help us identify design flaws and code vulnerabilities. However, the vulnerability results from these products are often overwhelming to most people, and we can’t just trust a few commercial products that could be compromised as well. Instead, we need a detailed understanding of the component parts and processes that make up the software supply chain so we can pinpoint flaws and resolve vulnerabilities at their origin, whether from open or closed source software, whether by accident or with malicious intent, and with a resolution that prevents anyone from exploiting the vulnerability in the future.

I’m ready to help the talented team of people at CloudBees tackle these pressing cybersecurity issues. I hope you’ll join me on this exciting journey.  Be on the lookout for additional blogs from me that delve deeper into these and other important software security topics. 

CloudBees recently surveyed 500 C-suite executives globally about the state of their organization’s software supply chain. Read the results here.