Why secure-by-design, trusted containers, and proactive vulnerability management are becoming essential for modern enterprises.
Bob, as Chief Product and Technology Officer at ActiveState, how has your three-decade journey across cybersecurity leadership roles shaped your current priorities around product strategy and secure software development?
Over the past three decades, I’ve seen security evolve from a reactive discipline into a core pillar of product strategy. But many organizations are still catching up to that shift.
What’s become clear is that developers are being asked to do too much. At ActiveState, we’ve worked with teams like Druva, where engineers were spending significant time tracking vulnerabilities and maintaining third-party components instead of building new features.
My priority now is embedding security directly into the software development lifecycle. That means building products where secure-by-design isn’t a feature, but the foundation. It also means aligning product, engineering, and security teams around a shared responsibility model. The organizations that succeed are the ones that treat developer experience and security as complementary, not competing priorities.
Container adoption is now standard across enterprises. How has this ubiquity changed the risk profile for organizations, and why are security incidents increasingly viewed as inevitable rather than exceptional?
Containers have made it incredibly easy to scale applications, but they’ve also made it easy to scale risk. We’ve seen organizations deploy a single base image across dozens of services, only to discover later that one vulnerable component propagated everywhere.
That’s part of why 82%of organizations report container-related breaches and 78% fail audits due to unmanaged CVEs. In highly regulated environments, the stakes are even higher. For example, one AI-driven cybersecurity company we worked with couldn’t enter the federal market until they could meet FedRAMP and NIST 800-171 requirements. It required them to completely rethink how their container images were built and secured.
Security incidents feel inevitable because most organizations are still operating without full control over what’s inside their containers. When you don’t have that visibility or consistency, risk compounds quickly.
Your recent research highlights persistent challenges in container vulnerability remediation. What underlying issues are preventing teams from closing known vulnerabilities despite improved detection tools?
Ongoing container vulnerability remediation issues are driven by a critical visibility gap – 91%of teams lack detailed insight into container components, leaving them unable to remediate risks they can’t identify. Even with improved scanning capabilities, the sheer volume of short-lived containers creates a rapidly changing and expansive attack surface that cannot be effectively managed through standard detection tools.
Manual dependency curation and outdated base images remain common. Why do these practices continue to exist, and how do they undermine scalability in modern container environments?
These practices stick around because they’re familiar—but they break down quickly at scale. We’ve seen organizations try to manually manage dependencies across dozens of services, only to find that every update introduces new compatibility issues and delays releases.
In the case of Druva that I mentioned earlier, their engineers were effectively splitting time between innovation and maintaining third-party components, which created a real productivity bottleneck. Outdated base images create a similar problem. They accumulate vulnerabilities over time and require constant manual intervention to maintain. That undermines the very promise of DevOps – speed and scalability – because teams are stuck maintaining the past instead of building the future.
Visibility gaps are frequently cited by both security and engineering teams. What information do organizations lack most when managing container risk, and how does that blind spot affect response times?
Visibility problems compound container security challenges. While 95% of DevSecOps respondents say container workloads account for half or more of their production footprint, 91% identify limited visibility into container components as their biggest security blind spot. This lack of visibility prevents quick remediation, causing teams to react to alerts rather than fix root causes. Additionally, using tools to automate secure, traceable container builds can significantly reduce response times.
As enterprises plan for 2026, what concrete actions should security and engineering leaders prioritize to reduce exposure in containerized environments?
The biggest shift is controlling what enters your environment in the first place. For example, in FedRAMP-driven environments, we’ve seen organizations dramatically reduce risk by adopting pre-built, hardened container images with zero known vulnerabilities. That alone can eliminate entire categories of exposure.
I would recommend several initial steps:
- Use minimal, trusted base images to improve your container image security – Images are one of the weakest points for container security. You can help mitigate the risk by minimizing the image itself. When using base images, ensure they are from a trusted source. Being extra thorough, especially when reusing images across multiple containers, can help you avoid bad actors getting in.
- Perform container security monitoring and scan container images early and often – When you do use images, ensure you’re scanning container images early and frequently. So you know that whenever you’re using images within your applications, they’re safe.
- Secure the entire CI/CD pipeline with container security best practices – Focusing on your CI/CD pipeline is essential because it forms the important connection between your code and production. If your CI/CD pipeline is tampered with, it could mean vulnerabilities are in your code before they are even made live. A few ways to secure your CI/CD pipeline are.
- Regularly audit and monitor container activity – Container security – and cybersecurity in general – is not a set-it-and-forget-it type of practice. Continuously auditing and monitoring container activity will help you identify vulnerabilities and suspicious activity, and take action.
Vulnerability management is often reactive by default. What practical shifts allow organizations to move remediation upstream and prevent issues before they reach production?
More than a reactive IT task, vulnerability remediation has become a strategic capability that DevSecOps teams must master. Automating vulnerability remediation is critical to manage the scale and speed of modern software development and the ever-increasing volume of vulnerabilities.
For instance, automated policy-based fixes for low-risk vulnerabilities can reduce manual intervention, freeing teams to focus on higher-risk issues. Integrating security checks directly into CI/CD ensures vulnerabilities are addressed before code reaches production, effectively shifting security left.
Open source remains foundational to modern development, yet it also introduces supply chain risk. How does trusted open source change the equation for security posture and resilience?
When organizations rely on scattered, unsecured sources for open-source software, they expose themselves to risk every time a developer pulls a package from the web. The trustworthiness of maintainers is often unclear, release cycles can be irregular, and threat actors frequently weaponize known weaknesses into zero-day exploits.
This environment not only weakens a company’s overall security posture, it also creates a significant operational burden. Developers must continuously monitor CVEs across components, dependencies, and shared libraries, then patch, upgrade, migrate, or replace vulnerable elements.
Open source changes this by removing this burden from developers and giving them the freedom to build securely.
Compliance obligations around open-source usage are growing more complex. What challenges are organizations facing today, and how should teams balance speed, governance, and accountability?
OSS governance can be tricky. For most organizations, identifying all the OSS deployed for use internally, externally, and for software development purposes can be more than difficult – it’s nearly impossible. Add to that trying to verify if it meets your security, compliance, and IT requirements.
Unknowingly or not, developers would prefer to think of OSS as “my solution; someone else’s problem.” Unfortunately, that’s rarely the way things work out. Issues inevitably find their way back onto developers’ plate to solve, fix, update, or implement. This creates a development bottleneck that’s difficult to break out of, limiting the ability of organizations to scale their use of OSS.
Looking ahead, how do you see the relationship between product leadership, developer experience, and security evolving as software supply chains become more distributed and interdependent?
These three areas are converging. Product leaders can no longer think about features, developer experience, and security in isolation. They’re deeply interconnected.
As software supply chains grow more complex, the organizations that win will be the ones that make security invisible but effective, and embedded seamlessly into developer workflows without adding friction. That requires strong product leadership to prioritize usability alongside protection.
Ultimately, the future is about alignment: giving developers the tools to move fast, while ensuring security is built into every layer of the process. When those elements work together, you don’t have to choose between speed and safety—you get both.
A quote or advice from the author:
“You can have the best tooling in the world, but if developers see security as someone else’s job, none of it sticks. The organizations I’ve seen get this right didn’t mandate security through policy alone. They created environments where engineers felt ownership over the security of what they ship. That starts with how leaders talk about it, how it’s measured, and whether security is treated as a shared win or a blame game when something goes wrong.”
Bob Shaker
Chief Product and Technology Officer, ActiveState
Bob joins ActiveState with over 30 years in cyber security and has held positions in security consulting, Chief Information Security Officer for the world’s largest institutional investment firm, Chief Technology Officer for Symantec SBP, VP of Product and Services for Malwarebytes and most recently VP of Product for Trellix.
During this time, he has been able to deliver safety and security to millions, develop new products and services that meet customer needs and deliver high margins and immediate revenue and develop some of the best talent in the industry. Working with these incredible teams Bob has realized the launch of 11 new services, 3 products, 2 new divisions and 1 patent. Bob always puts people first. Mentoring, acting with integrity and putting others first are his core values and have led to colleagues that have gone on to be wildly successful and lifelong friends.