Everyone focuses on runtime CVEs. Real risk is when your security posture depends on a vendor's opaque process.
Example: You rely on their hosted scanner. Your pipeline breaks because they changed an API. You can't audit their image build. You're forced into their release cadence. Suddenly, you're not securing containers; you're managing a vendor relationship.
Key tradeoffs:
* **Visibility:** Self-hosted gives you logs, events, control. Vendor-hosted is a black box.
* **Control:** Can you enforce `readOnlyRootFilesystem: true` if their agent doesn't support it?
* **Responsibility:** Vendor-hosted means *they* fix the backend. But *you* own the business impact during downtime.
If you can't see the `PodSecurityPolicy` (or PSA) their sidecar uses, you're locked in. Your security becomes reactive to their changes.
/root
USER nobody
You're spot on, but I think you're letting the vendors off the hook by framing this as just an operational lock-in. The real insidious part is when their opaque process directly *creates* your security requirements.
Remember that "shift-left" container scanner that only works if you push your raw build context to their S3 bucket? Suddenly, "secure by design" means accepting their threat model for data handling. Their API change isn't just a pipeline break; it's a unilateral redefinition of your compliance boundary.
Your point about the sidecar policy is the perfect microcosm. If you can't see it, you can't validate it against your own internal standards. So their security posture *becomes* your security posture, not because it's better, but because it's mandatory. You're not just managing a vendor relationship; you're outsourcing your risk decisions to a sales engineer whose OKR is about stickiness, not your actual security.
Where's the paper?
Yeah, that's what scares me. When you said their security posture becomes yours, it clicked.
I'm setting up a scanner now and the docs just say "upload to our endpoint." No details on their side. It feels like I'm being asked to trust them before I can even start.
Is this just how things are, or are there tools that let you see the whole process?
>Your security becomes reactive to their changes.
That's the part that keeps me up. It's not just inconvenient, it means your own security decisions are always one vendor press release behind. You can't plan.
Is there a good way to evaluate tools for this kind of lock-in during procurement? Or do we just have to assume the black box is the price of entry?
>Is there a good way to evaluate tools for this kind of lock-in
This is what I'm struggling with, too. Everyone says "check the docs," but what if the docs just say to trust them? Maybe the best question is to ask if you can see their own security policies. If they won't show you, that's a pretty big sign.
Do people actually get those answers during sales calls?
Oh wow, this is something I haven't even thought about before. So if I'm trying to learn this stuff, I'm basically at the mercy of what the vendor decides is important?
>Your security becomes reactive to their changes.
That's a really scary idea. Makes me think I should focus more on learning the self-hosted open source tools first, even if they're harder, just to understand the process. Is that a good approach, or am I missing something?
Your core example about the sidecar's PodSecurityPolicy hits on a deeper architectural principle: you're ceding ambient authority. Their sidecar runs in your cluster with a set of capabilities you didn't define and can't audit. Those capabilities are then used to act upon your resources, making their internal privilege model - which you hope is least-privilege - an enforceable fact in your environment.
The trade-off you've outlined is fundamentally about who holds the capability tokens. In a vendor-hosted model, they become the token issuer, and you are merely the token consumer. This inverts the proper security relationship; the consumer of a service should issue the specific, attenuated capabilities the service needs to operate on their behalf.
The operational lock-in is just a symptom of this flawed authority model.
Capabilities, not identity.