Security Shifts Down with Pankaj Gupta | Platform Engineering 2.0 Ep 5
Security Belongs in the Platform
Shift-down security moves essential protections into the platform itself. In Episode 5 of Platform Engineering 2.0, Alan Shimel and Broadcom’s Pankaj Gupta explore that approach. The discussion focuses on the fourth pillar of the framework: making security a built-in capability rather than another developer burden.
Gupta presents this evolution as a complement to shift-left practices, not a replacement. Early testing still helps teams find problems during development. However, production environments introduce changing configurations, runtime risks and threats that pre-deployment checks may miss.
Make Secure Defaults Part of Delivery
The conversation turns to controls that platform teams can implement and govern centrally. Gupta highlights least privilege, mutual TLS, microsegmentation and automated secrets rotation. These protections should support secure deployment without requiring every developer to configure them independently.
Security as code and continuous compliance extend that foundation. Rather than treating compliance as an occasional review, Gupta argues for controls that remain active throughout delivery and operation. Runtime protection continues the work after applications reach production.
This approach also addresses cognitive load. Developers can focus on building applications while the platform supplies consistent guardrails. Security teams still define requirements, but those requirements become part of the system developers use.
AI Expands What Platforms Must Protect
AI introduces additional concerns, including prompt injection, model poisoning and inference data leaks. Gupta explains why platform responsibilities now extend beyond applications to models, data and inference. The platform becomes a boundary for trust across those resources.
He identifies model registry governance and strong data isolation as practical starting points. AI and MCP gateways can also support prompt controls and inference auditing. The objective is to make protections platform-managed and ready for audit by default.
The episode closes by examining an important tension: secure foundations must remain dependable while threats keep changing. Gupta emphasizes that immutability does not mean standing still. Defenses need ongoing improvement, and security remains a shared responsibility across the organization.
For platform teams, shift-down security offers a way to connect developer productivity with stronger governance. The challenge is to keep those protections current as platforms and AI workloads evolve.
Transcript
Hi, everyone. 0. It is a whole series we're doing, and my co-host on the series is my friend Pankaj Gupta of Broadcom VMware.
First of all, Pankaj, welcome back. It's great to have you here. Thank you.
As I mentioned, this is a continuing series. You're actually catching episode five, which means, you don't have to be a math major for this, but there are four prior episodes if this is five, and you can catch them on Techstrong TV or the Techstrong TV YouTube channel or the Techstrong TV app, OTT app on iOS or Android or Amazon Fire Stick, Roku, or Apple TV, whatever screen you like to watch your videos on. 0 foundation, if you will, and its security shifts down.
But before we get to that, I'm going to ask my friend Pankaj to give us a 30-second recap, in case you haven't seen the prior episodes. Pankaj, would you mind? Absolutely, Alan.
We talked about previously that platform engineering evolution is near universal. The maturity varies across the organization. 0 has really increased the developer productivity, significantly reduced the cognitive load.
But the major market force is driven by AI and agentic AI, which also requiring a stronger FinOps, stronger sovereignty and compliance, and expanding the personas from just developer to four more new personas for that. 0. It is not a reset.
It is not a rip and replace. It is evolution in the AI and agentic era. We talked about five pillars of platform engineering.
Yeah. 0 provided. Absolutely.
com in 2014, and I've got to tell you, by 2015, much of DevOps, including SecOps, was about shift left. Right? We tried to shift everything left.
And I think that was one of the reasons for platform engineering, is we shifted too much left, and we shifted too far left. Right? Shift left became lingo for let the developer do it.
We mentioned it in the last episode. And so I know as a security person in the security industry, 25 plus years, a lot of my friends in security said, "No, we can't just shift left. We almost have to shift everywhere," if you will.
But now we're talking about shift down. I'm not sure everyone out here understands what we mean by shift down. What does it mean?
I think shift left has been very highly successful to identify the security vulnerabilities in the development cycle. But reality is that it has increased the cognitive load on developer, but the bigger issue is that most of the vulnerabilities are still found post-production because the scanning tools cannot find many times the runtime issues for that. The bad actors are becoming more and more intelligent, especially empowered by now the new frontier models for that.
The deployment model continuously evol-- Deployment scenarios or deployment configurations evolve all the time for that, and it takes much longer to even find and fix the vulnerabilities. 0, where whatever left is, that is caught by the shift down the security. Principle of the concept is very simple.
What it means is very strong security by default. Examples like least privileges, the mutual TLS in between the services there, the micro-segmentation with less than 20% organizations have deployed for that, the secrets rotation for that. Those are the basic principles which have to be implemented and governed into the platform itself.
You also need security to be easy to deploy, so you have to deploy security as a code for that. In the world where the compliance was done every six months in a year, it has to be continuous compliance, and agents are also asking that, which we're going to talk a little bit later into that. And the security shift down doesn't stop there.
It also continue to shift on right also during the runtime there. So when you combine this together, this security has to be invisible. It has to be immutable also.
So this is just one part, but there is another big area of threat surface is evolving or already evolved because of AI. Many of my friends in the security community feel almost shell-shocked. Right?
Because over the last two to three months, first we had this whole Mythos thing, and that absolutely moved the cheese in what we do in security, especially a shift left kind of security, pre-deployment. All of a sudden, the emphasis used to be on finding bugs, finding vulnerabilities. Researchers, they fuzz, they scan, dynamic scanning, static scanning, CSA scanning for open source.
And then at the snap of a finger, finding vulnerabilities was no longer the issue. Any Mythos, and not just Mythos itself, even the new OpenWeight models and the OpenAI, all of them now have advanced, Gemini, all of them have advanced security capabilities. They can find more vulnerabilities than we ever were able to find by just persons doing it.
Then we saw what just happened last week. Right? OpenAI, or maybe, I don't know when people will be watching it, happened just a few weeks ago.
OpenAI was experimenting with two of their most advanced models, and it broke containment. And you can't really blame the agents because they were trying to do what they were told to do. But to do it, they had to break containment, get out on the internet, and go where they thought they might be able to find the answers to the problems, which was HuggingFace, where there are a lot more models.
And they broke in, they took it, made a zero day of broke into HuggingFace. Many of my friends in the industry were apoplectic about this, right? Because if this could happen there, don't think the bad guys aren't going to do it.
Absolutely, Alan. And AI is widening the security gap. This is a whole new attack surface which platform engineering or even IT haven't think about.
Imagine that shadow IT is prompt, the prompt injection, the absolutely huge new attack surface with no SAST or DAST tools can find out. The model poisoning for that, the inference data leaks for that. When you combine all these together, it's a brand new and a huge attack surface or vulnerability surface for AI.
0. The governance is going to be very, very critical. The good news is there are some very simple things can be done pretty quickly for that.
One is the model registry governance, which is very, very simple to do, to be honest with you. Many of platforms like VCF and other do that. Data isolation.
This is a great time for platform engineering to look at that. How do they make a very strong data isolation for that? And when you start deploying the MCP gateways, the AI gateways, that will give you capabilities for prompt security, that will also give you the inference audit capabilities.
0 just got released this week, to address some of those issues for that. So when you look at for security for AI, each layer has to be platform managed. It has to be developer invisible.
It has to be audit ready by default that. And now the platform engineering task is not just securing the application. Their task actually evolves as a platform just becomes the trust boundary.
And it protects not just the data. It now protects model, it protects inference with original platform engineering was not even designed for it. Well, but it wasn't a thing then either.
Yes. Yeah. Crazy.
It's crazy. Look, here's my question to you, though. I don't disagree with anything you said.
Is it even possible? What does it really mean to make the platform that secure? Is it possible?
At some point, there's a diminishing return for the amount of effort you put into this too. It's because at the end of the day, it's about risk, risk management. What is it mean?
I think this is the very interesting question you ask, Alan, is that bad actors become intelligent day by day more and more. As vendors and enterprises have tools like the frontier models, same tools are available for bad actors also. So you have to be on toes continuously evolving.
I'm sure you remember that DDoS attacks have more than 25 years old, and they still exist. Yeah. And they're bigger than ever.
And they're getting smarter for that. Yeah. It's DDoS as ransomware.
So security is not a static. It has to continuously evolve. It is the fight in good and bad, which is perpetual.
Unfortunately, I think it's a cat and mouse game and we're the cat. The mouse is always one step ahead of us, but we try. We try.
But that brings me to my last question on this particular segment. We could build security in from the beginning, right? But the platform keeps moving.
How do we make sure security stays current with the state of the platform while remaining immutable? That's an excellent question. Excellent question there.
Immutability is not a static. Bad actors will find new ways. I think the more requirement for confidential computing, more requirement for conclaves, more requirement for sandboxing.
Of course, there will be instances when the sandboxes become sand castle, what we saw just in the recent HuggingFace environment. So you have to implement more and more security into that. It's not a snapshot in the time.
And it is also a cultural shift in an organization for that. Security is not just the SecOps team's responsibility. It is the company-wide responsibility, including the user for that.
I will wrap up with this statement that defense mechanism has to be successful every time. Bad actors have to be successful only once. That's an excellent point, my friend, and it's really the security professional's dilemma, right?
It only takes one. Only takes one. Anyway, that's a great place to end episode five.
Pankaj, thank you. I'll say it again. Please go watch the previous episodes on Tectron TV or the YouTube channel or the OTT.
com. org. Until next time, though, on behalf of Pankaj Gupta, I'm Alan Shimel.
Thanks for joining us.