Platform engineers have a leverage problem. There are more product teams than platform engineers. Every security control that requires per-team configuration multiplies the platform team’s workload by the number of teams. Every security gap that a product team creates becomes a platform team escalation when an audit or incident surfaces it.
The solution that scales: security as a default behavior of the platform rather than a responsibility of each product team. When the internal developer platform produces secure outputs by default, product teams are secure without requiring security knowledge or additional effort.
This is not a new concept in platform engineering. Golden paths, paved roads, and opinionated defaults are standard platform patterns. The application to security is: make the golden path the secure path.
The Product Team Security Failure Pattern
Product teams fail at security not because they do not care but because:
Security is not in their job description: Product engineers are measured on feature delivery, reliability, and performance. Security findings generate tickets that compete with feature work. When sprint planning forces trade-offs, security tickets lose to feature tickets.
Security tooling adds friction: A security scanner that blocks deployments with no remediation guidance teaches product teams that security is an obstacle. They route around it — through exception processes, security team escalations, or direct pressure on whoever controls the gate policy.
Security knowledge is not uniformly distributed: A product team that happens to have a security-aware engineer handles container vulnerabilities differently from a team with no security background. The variance in security outcomes across teams is driven by individual knowledge, not by team-level investment.
The platform team’s job is to eliminate these failure modes. Friction reduction, knowledge transfer, and default enforcement are platform engineering problems, not product team problems.
Security Embedded in the Platform: Three Layers
Layer 1: Hardened base image catalog
Product teams pull from platform/node:20, platform/python:3.12, platform/java:21. These images are maintained by the platform team with security as a baseline requirement. Unused packages have been removed. Common CVEs are below threshold.
When a new CVE affects the Node.js runtime, the platform team updates platform/node:20. Product teams that rebuild on the updated base get the fix without any intervention.
Secure container software embedded in the platform image maintenance workflow ensures that the catalog is continuously current with hardened, verified base images.
Layer 2: Automated security in CI/CD templates
Product teams use the platform’s CI/CD templates, which include container scanning, hardening, and SBOM generation as standard steps. The team does not configure these steps; they are included automatically.
# Platform-provided GitHub Actions template
# Product team workflow.yml references this template
jobs:
build:
uses: platform/workflows/.github/workflows/container-build.yml@v3
with:
image_name: ${{ inputs.service_name }}
# Template internally runs: build, harden, scan, push, attest
# Product team sees: passed/failed with specific actionable findings
Layer 3: Admission control enforcement
The Kubernetes admission control policies maintained by the platform team prevent non-compliant images from running in production. Product teams cannot deploy unscanned images to production not because they are not trusted, but because the platform architecture prevents it.
This is security enforcement without enforcement overhead: no security team review of each deployment, no manual approval process. The infrastructure enforces the policy automatically.
Container Security software as a Platform Service
For platform teams that want to offer hardening as a service without requiring product teams to modify their build pipelines, the registry-level hardening service model works:
- Product team builds image and pushes to internal registry
- Registry webhook triggers platform hardening service
- Platform hardening service creates a hardened variant
- Platform admission control requires the hardened variant for production
The product team’s build process is unchanged. The platform handles security between the registry push and production deployment. Product teams benefit from the security without any workflow modification.
The platform team operates the hardening service, maintains the configuration, and handles the operational overhead. Product teams consume the security output through normal deployment workflows.
Frequently Asked Questions
What does “security as a service” mean for DevSecOps platform teams?
Security as a service means the platform team delivers security outcomes as a default behavior of the developer platform, rather than requiring product teams to configure or maintain security controls themselves. Product teams pull from hardened base image catalogs, use CI/CD templates that automatically include scanning and hardening steps, and deploy to Kubernetes clusters with admission control policies that enforce security requirements — all without any security-specific knowledge or workflow changes on their part.
How should DevSecOps platform teams deliver security to product engineers?
The most scalable approach operates at three layers: a hardened base image catalog that product teams pull from instead of upstream images, CI/CD templates that include scanning, hardening, and SBOM generation as automatic steps, and Kubernetes admission control that prevents non-compliant images from reaching production. Each layer removes a class of security failure without requiring product team intervention. When a CVE affects a base image, the platform team patches it once and all downstream services inherit the fix on their next rebuild.
Why do product teams fail at DevSecOps security requirements?
Product teams fail at security requirements not because of indifference but because of structural incentives and knowledge gaps. Security findings compete with feature tickets in sprint planning and consistently lose. Security tooling that blocks deployments without clear remediation guidance trains teams to see security as an obstacle and find workarounds. Security knowledge is unevenly distributed — teams with security-aware engineers handle CVEs differently from those without. Platform teams solve this by making the secure path the default path, eliminating the knowledge and motivation requirements.
What is the registry-level hardening service model for DevSecOps platform teams?
In the registry-level model, product teams build and push images normally, triggering a platform webhook that automatically creates a hardened variant. Platform admission control then requires the hardened variant for production deployment. The product team’s build process is completely unchanged — they push an image and the platform handles security between the registry and production. This model eliminates all product team workflow friction while giving the platform team full control over security configuration and operational overhead.
Developer Experience Design for Platform Security
The most common failure in platform security: controls that add friction get bypassed. The bypass path is always found, whether through exception processes, direct platform team pressure, or informal workarounds.
Friction reduction principles for platform security controls:
Clear, actionable failure messages: When the security gate blocks a deployment, the error message tells the product engineer exactly what to do. Not “security scan failed” but “High CVE in express 4.17.1 (in your package.json). Update to express 4.19.2 to resolve. Estimated time: 15 minutes.”
Automated remediation for the common case: If 80% of CVE findings can be resolved by automated hardening, the pipeline should apply hardening automatically and only surface the remaining 20% to the developer. Developers who see one finding per deployment address it. Developers who see 30 findings per deployment address none.
Fast feedback, not delayed gates: A pipeline that catches security issues in the pre-commit hook prevents them from becoming blocking issues at the deployment gate. The same finding caught 5 minutes after the code change is written costs 5 minutes. The same finding caught 3 days later during deployment review costs 30 minutes.
The platform team that designs security controls with developer experience as a primary requirement builds a security posture that product teams maintain willingly. The platform team that designs security controls without considering developer experience builds one that product teams route around.