Content Hub | Corinium Intelligence

Built-In, Not Bolted On: Rethinking Security as a Platform

Written by Maddie Abe | May 15, 2025 3:04:12 AM

Corinium’s Maddie Abe engaged with Rahul Trikha, Director of Technology Platforms & Developer Experience at Domain, to discuss the intersection of platform engineering and cyber security. 

In my earlier article on platform engineering, I explored whether platform engineering is replacing DevOps, and why internal platforms are becoming central to how teams scale and deliver software effectively. That line of thinking naturally leads to another question. If platform engineering has reshaped how we build and ship code, could security benefit from a similar shift?

In this interview, Rahul Trikha shares his view on platform-based security. We explore what changes when security moves beyond checklists, how internal platforms can solve persistent challenges and what it takes to embed security into cloud-native environments.

From Checklists to Capabilities 

Traditional security has often been defined by rules, reviews and signoffs. But that model doesn’t scale in fast-moving environments. A platform-based approach reframes security as a product, something teams can use, not something they have to justify.

“To me, platform-based security means building security as a product—an internal service that development teams can consume, not just comply with,” says Trikha.

“It’s embedded into their workflows, from commit to deploy, rather than bolted on at the end.”

This shift also changes how controls are delivered. Rather than asking teams to interpret policies or request approvals, security becomes available through pre-approved patterns, paved paths, and automation that nudges developers toward secure defaults.

Despite growing interest in platform-based security, adoption is uneven. The barriers aren’t just technical but they’re cultural and structural.

“Security teams are often incentivised by risk aversion, while engineering teams are focused on speed and outcomes. Without shared goals or shared platforms, friction is inevitable”

In other words, when security and engineering are pulling in different directions, even well-intentioned efforts end up clashing. In many organisations, security still operates in a parallel stream, rather than as a partner to engineering. Until teams share roadmaps, APIs and telemetry, security will remain reactive by design.

Shifting Left, Scaling Forward

The solution isn’t to remove controls but to rethink how they’re delivered. Internal security platforms can make the secure path the most efficient one, removing the need for constant reviews or intervention.

“Internal security platforms can act as guardrails, not gates,” Trikha explains.

“We’re embedding security scanning into CI pipelines, providing APIs for token rotation, and building shared services like audit logging and access provisioning—all as part of the developer experience layer.”

By making controls programmable and reusable, platform-based security brings repeatability and speed to what used to be one-off tasks.

A common tension is how to meet audit and regulatory obligations without slowing teams down. The key, according to Trikha lies in designing for both observability and autonomy.

“You design with defaults and declaratives. Use secure templates, versioned configurations, and policies that map directly to compliance requirements”, he says.

When the platform is designed well, it satisfies auditors with evidence of control, while letting engineers move fast without security becoming a bottleneck.

Culture Change Through Platform Thinking

The shift to platform-based security isn’t just about tools—it also drives new ways of working. When security is accessible, collaborative and embedded, teams engage earlier and take more ownership.

When Trikha was asked about what happens when security moves from a ‘checkbox’ approach to a platform-first approach, he pointed three key changes:

  1. From adversarial to collaborative – Security becomes a partner, not a blocker. Teams start inviting security early, not avoiding them.
  2. From reactive to proactive – Issues are caught at pull request or test phase, not in production.
  3. From knowledge silos to capability sharing – With platform abstractions, you don’t need every team to be a security expert. The platform handles the complexity.

The result is a cultural shift. Engineers stop treating security as someone else’s job, and start seeing it as part of their own delivery responsibility.

The Future is Composable and Context-Aware

With the increasing complexity of cloud environments and microservices, the old ways of securing infrastructure seem outpaced. Looking ahead, the goal isn’t just to improve today’s practices—but to reimagine security as something ambient and automatic, built into the very fabric of cloud-native development.

“Imagine every service automatically inherits least-privilege access, has signed artefacts, encrypted traffic, and runtime protection—without developers having to configure any of it manually,” says Trikha. “That’s the direction we’re heading.”

It’s a future where security isn’t a final step, but a default behaviour of the platform itself. And as he points out, it’s up to platform and security leaders to make that future real.

 

Don’t miss the opportunity to hear more from Rahul Trikha at Cloud Security Melbourne 2025 on 23 July at Crown Promenade. Alongside this event, we are hosting CISO Melbourne - Home (22-23 July) OT Security Melbourne - Home (22 July) and AppSec & DevSecOps Melbourne - Home (23 July).

If you would like to share your experience and insights at our events, feel free to reach out to Maddie Abe (Content Director).