22.1 Internal Developer Platforms and Security¶

For decades, security has been something done to developers rather than for them. Security teams created policies, deployed scanning tools, and generated reports—then handed findings to developers who experienced security as interruption, friction, and work that competed with feature delivery. This model scales poorly and creates adversarial dynamics. As organizations grew to hundreds or thousands of developers, security teams became bottlenecks, developers found workarounds, and everyone remained frustrated.

Platform engineering offers a different approach. Rather than imposing security through external mandates, platforms embed security into the infrastructure and workflows developers already use. When security is part of the platform—automatic, invisible, enabling—it scales with development activity rather than requiring proportional security effort. Developers get secure outcomes without needing security expertise; security teams achieve coverage without reviewing every deployment.

This section introduces platform engineering as a mechanism for supply chain security, exploring how platforms can make secure practices the path of least resistance.

The Rise of Platform Engineering¶

Platform engineering is the discipline of designing and building toolchains and workflows that enable self-service capabilities for software engineering organizations. Rather than each development team building and maintaining their own CI/CD pipelines, deployment infrastructure, and operational tooling, platform teams provide these capabilities as a shared service.

The rise of platform engineering reflects several industry trends:

• Cloud complexity: Modern applications involve containers, orchestration, service meshes, observability stacks, and numerous cloud services. Expecting every developer to master this complexity is unrealistic.

• Developer productivity focus: Organizations recognize that developer time spent on infrastructure is time not spent on product differentiation. Platforms reduce undifferentiated heavy lifting.

• Consistency at scale: As organizations grow, inconsistent practices across teams create operational, security, and compliance challenges. Platforms enable standardization.

• DevOps evolution: Platform engineering extends DevOps principles, recognizing that "you build it, you run it" works better when developers have well-designed tools rather than raw infrastructure.

The 2023 State of DevOps Report from Puppet found that 94% of respondents agreed that platform engineering is helping their organizations better realize the benefits of DevOps, with 68% reporting sharp increases in development velocity from dedicated platform teams. Gartner predicts that 80% of large software engineering organizations will establish platform teams by 2026, up from 45% in 2022.

Leading technology companies pioneered platform approaches:

• Spotify developed Backstage, an open source developer portal that has become a foundation for many internal developer platforms
• Netflix built sophisticated internal platforms enabling rapid deployment at massive scale. Their "Paved Road" approach to security has been widely influential
• Airbnb created internal platforms that abstract infrastructure complexity from product engineers
• Google operates internal platforms that make security and reliability defaults rather than afterthoughts

These organizations discovered that platforms are not just productivity tools—they are force multipliers for security, compliance, and operational excellence.

Platforms as a Mechanism for Supply Chain Security¶

Traditional supply chain security operates as a separate layer: security tools scan code, generate findings, and create work for developers to address. This model has several limitations:

• Reactive: Issues are discovered after the fact rather than prevented
• Friction-creating: Developers must stop feature work to address security findings
• Expertise-dependent: Developers must understand security issues to remediate them effectively
• Inconsistent: Coverage depends on which teams adopt which tools

Platform-embedded security inverts this model. Instead of security being a separate concern that intersects with development, security becomes part of the development infrastructure itself:

Traditional Model:
Development → Security Review → Findings → Developer Remediation

Platform Model:
Development (with security embedded) → Secure Output

Benefits of platform-embedded security:

When developers create a new service using the platform, they automatically get: - Dependency scanning in their CI/CD pipeline - SBOM generation with each build - Container images from approved, hardened bases - Deployment policies that enforce security requirements - Secrets management that prevents credential exposure

None of this requires security expertise from the developer; the platform provides it by default.

Abstracting Security into Platform Capabilities¶

Effective platforms abstract security complexity, exposing simple interfaces while handling sophisticated security requirements behind the scenes.

Security abstraction examples:

1. Dependency management abstraction:

Without platform:

# Developer must know about and configure scanning
npm install
npm audit
# Must understand findings, decide on fixes
# Must configure CI to run scans
# Must handle transitive dependency issues

With platform:

# Developer uses platform service creation
platform create service --template nodejs
# Platform automatically:
# - Configures approved package registry
# - Enables dependency scanning
# - Blocks known-vulnerable versions
# - Automates update PRs

1. Container image abstraction:

Without platform:

# Developer must choose and maintain base image
FROM node:18
# Must apply security hardening
# Must scan for vulnerabilities
# Must update when base image changes

With platform:

# Platform provides hardened, maintained base
FROM internal-registry/nodejs-base:18
# Platform team handles:
# - Base image security updates
# - Hardening configuration
# - Vulnerability scanning
# - Automatic rebuilds when CVEs are patched

1. Secrets management abstraction:

Without platform:

# Developer must understand secrets management
env:
  DB_PASSWORD: ${SOME_SECRET_MECHANISM}
# Must configure vault, manage access, rotate credentials

With platform:

# Platform handles secrets automatically
secrets:
  - name: database
    service: my-database
# Platform provides:
# - Automatic credential injection
# - Rotation handling
# - Audit logging
# - Access policy enforcement

Abstraction principles:

• Hide complexity, expose simplicity: Developers should interact with simple, clear interfaces
• Make security the default: Secure configurations should require no additional developer action
• Provide escape hatches: When legitimate needs require deviation, make it possible (but visible)
• Abstract implementation, not intent: Developers should understand what they're getting, not how it works internally

Golden Paths and Paved Roads¶

Golden paths (also called paved roads or happy paths) are the platform-supported, recommended ways to accomplish common tasks. They represent the easiest route from idea to production, with security, compliance, and operational requirements built in. A golden path is the supported, well-thought-through way to accomplish a task—not the only way, but the way that's been secured, maintained, and optimized to get developers to production fastest.

Golden path design principles:

1. Make the right thing the easy thing: Secure, compliant approaches should require less effort than insecure alternatives. If developers must work harder to be secure, many will take shortcuts.

2. Start with templates: Provide service templates that include security requirements by default. A new service created from template should be secure without additional effort.

3. Automate security checks: Build scanning, policy enforcement, and compliance validation into the path. Developers shouldn't need to remember to run security tools.

4. Provide fast feedback: When issues arise, surface them quickly and clearly. Long feedback loops reduce developer productivity and lead to accumulated security debt.

5. Support progressive complexity: Simple services should be simple to create; complex requirements should be achievable without leaving the platform.

Golden path example for service creation:

Developer Action                 Platform Response
─────────────────────────────────────────────────────────────
1. "Create new service"      →   Prompt for service type,
                                 owner, dependencies

2. Select "API Service"      →   Generate repository from
                                 secure template with:
                                 - Approved base image
                                 - CI/CD pipeline
                                 - Dependency scanning
                                 - SBOM generation
                                 - Security policies

3. Write application code    →   Automatic scanning on
                                 each commit

4. "Deploy to staging"       →   Admission control verifies:
                                 - Image signed
                                 - No critical vulns
                                 - Policy compliance
                                 Deploy if passing

5. "Deploy to production"    →   Additional gates:
                                 - Security approval (if needed)
                                 - Change management
                                 Deploy if passing

Throughout this path, the developer focuses on application logic while the platform handles security requirements.

Off-path visibility:

Golden paths should be encouraged, not enforced through blocking. When developers need to deviate:

• Make deviation possible but visible
• Require explicit acknowledgment of deviation
• Track off-path usage for security team review
• Provide guidance on bringing off-path work back on-path

Organizations that block all deviation create shadow IT; those that make deviation visible and manageable maintain security awareness while preserving developer autonomy.

Reducing Cognitive Load on Developers¶

Cognitive load in software development refers to the mental effort required to accomplish tasks. Developers already manage enormous cognitive load—understanding business requirements, designing systems, writing code, debugging issues, operating services. Adding security expertise to this load often results in security being deprioritized or done poorly.

Platform engineering reduces security cognitive load through several mechanisms:

Eliminating decisions: When the platform makes security decisions (which base image, which scanning tool, which policy), developers don't need to research, evaluate, and choose.

Automating actions: When security checks run automatically, developers don't need to remember to run them or learn how they work.

Simplifying interfaces: When complex security requirements are exposed through simple interfaces, developers can use them without deep understanding.

Providing guardrails: When platforms prevent insecure outcomes (blocking vulnerable images, rejecting secrets in code), developers can't accidentally make security mistakes.

Cognitive load reduction examples:

Developer experience research consistently shows that reducing cognitive load improves both productivity and quality. Developers who don't need to context-switch into security expert mode remain focused on their core work while achieving secure outcomes.

Security as Enablement, Not Obstruction¶

The framing of security matters. When security is positioned as enablement—helping developers ship securely and confidently—it receives very different reception than when positioned as control or obstruction.

Enablement framing:

Practical enablement strategies:

1. Fast by default: Security checks that take hours create frustration; checks that take seconds feel like part of the workflow

2. Clear guidance with findings: Don't just report problems; provide specific remediation steps

3. Self-service where possible: Let developers resolve issues without waiting for security team involvement

4. Celebrate success: When deployments pass security checks, acknowledge it; don't only surface failures

5. Measure developer experience: Track how security tooling affects deployment frequency and developer satisfaction

Industry examples:

Spotify Backstage demonstrates platform-embedded security through its plugin architecture. Organizations can add security scanning, compliance checking, and vulnerability management as plugins that integrate into the developer portal, making security information accessible alongside service documentation, deployment status, and operational data.

Humanitec and similar Internal Developer Platform (IDP) vendors build security capabilities into their platforms, enabling organizations to define security policies that are enforced automatically as developers deploy applications.

Netflix's internal platforms famously achieve "paved road" security by making secure patterns the easiest path. Their security architecture has influenced industry thinking about how platforms can embed security without creating friction. The goal is to make security invisible to developers—when security is just how the platform works, developers don't experience it as separate from development.

Recommendations¶

We recommend the following approaches to platform-embedded supply chain security:

1. Invest in platform engineering: If your organization doesn't have platform engineering function, consider establishing one. The security benefits extend beyond supply chain to operational excellence broadly.

2. Design security into platforms from the start: Adding security to existing platforms is harder than building it in. When designing platform capabilities, include security requirements as first-class concerns.

3. Create golden paths for common scenarios: Identify the most common service types and development patterns in your organization; create platform-supported paths that include security by default.

4. Abstract security complexity: Hide the complexity of security tooling behind simple interfaces. Developers should achieve secure outcomes without needing to understand implementation details.

5. Reduce decisions and actions: Every security decision developers must make and action they must take is an opportunity for error or omission. Automate and default wherever possible.

6. Frame security as enablement: Position security capabilities as helping developers ship safely and confidently. Measure and communicate how platforms accelerate secure delivery.

7. Maintain escape hatches with visibility: Allow deviation from golden paths when legitimate needs arise, but make deviation visible and trackable.

8. Iterate based on developer feedback: Platform engineering is product development for internal customers. Gather feedback from developers and improve platform capabilities based on their experience.

Platforms transform supply chain security from a tax on development to an embedded capability of the development infrastructure. When security is invisible, automatic, and enabling, developers achieve secure outcomes without security becoming an obstacle to delivery.