Treating Security Like Product: A Platform Approach to Safer Architecture

If you’ve ever shipped infrastructure with security bolted on later, you already know the pain of retrofits, audit scrambles, PR friction, and firefighting after something slips through. There is a better way: Approach security in the same way as product and embed it from the start.

Here’s what treating security like product actually looks like in practice:

Here is a scenario that some of you may unfortunately be familiar with: Your security team notices sudden, rapid VM spin-ups and shutdowns in a live environment. You realize that somebody has accessed a leaked Git secret and is using it to deploy. You catch the incident in time, avoiding any major damage, but it teaches you some lessons about security, alerting, cost management, and governance.

Cloud breaches like this are configuration problems, not cloud problems. We’re talking about misconfigurations, exposed access, and secrets embedded in code. When infrastructure is defined as code, a single mistake replicates across environments, regions, and customers.

That’s the power of IaC. And also the risk.

Security and compliance should be foundational to any system. Rather than building features and later scrambling to layer on controls, they must be treated as first-class principles from the beginning—built into the architecture, not retrofitted after the fact.

That means:

• Policies embedded in pipelines
• Mandatory tagging enforcement
• Scans on every deployment
• Cost model defined before writing a single line of code
• Compliance evidence collected automatically

The result? Teams can move fast, with risk under control and DevOps and DevSecOps reinforcing each other rather than working against each other.

One detail you should take note of: Failing a PR isn’t enough.

If your PR check fails with a 300-line JSON blob, you’ve added friction, not safety.

A better approach is to fail the PR for open ports or for missing required tags, enforce access control in the pipeline, and use Open Policy Agent (OPA) and/or Sentinel. However, the most important thing is to make feedback actionable. In other words, “X failed because of Y. Here’s what to fix.” Security guardrails should feel like helpful constraints, not random interference.

Just because you have 100% automated deployment does not mean your deployment is 100% secure. Automation does deliver speed and repeatability, but real security requires intent.

One misconfigured Terraform template pushed through automation can scale risk just as efficiently as it scales infrastructure. That’s why you need to shift left, embedding guardrails in the product and pipeline itself.

Anyone who has been through an enterprise audit knows the cycle of build, release, scramble for evidence, survive the quarterly audit, and repeat the whole process again. You can eliminate the scramble by building evidence collection into the pipeline, so that every pipeline run generates artifacts that support compliance controls (PCI, HIPAA, ISO, etc.). Almost every control can be automated if you design it early, reducing audit stress and engineering distraction dramatically.

Security scanning is not just about adding tools. Integrate your scanning tools into PRs and connect their findings directly to a tracking system like Jira. Tickets can be auto-created for issues that cannot be fixed immediately, and dashboards should be shared across engineering and security. This emphasis on measurement and improvement is a key component of treating security like product — and it makes a difference. Moving from manual to automated dashboard reviews dramatically reduces remediation times.

Shift-left controls are not bullet-proof; things can still slip through. That’s why you need to layer in runtime scanning, environment-wide security visibility, pen testing, and security game days. For those security game days, teams intentionally break systems in ops recovery exercises, measure recovery times, and run security testing. Security is never “done”; it’s iterative.

One of the more practical connections you can make is the link between cost governance and security. Idle infrastructure is waste, but it’s also exposure. Particularly in large-scale multicloud environments, cost governance becomes part of your security posture.

That means you need to:

• Enforce tagging.
• Set budget alerts.
• Eliminate zombie infrastructure.
• Use policy as code to enforce cost guardrails.

Possibly the most impactful shift when you treat security like product is the transition from individual dashboards for the engineering, security, and compliance teams to one shared view with shared OKRs and shared accountability. This prompts a change in the perception of security findings as being “their problem” to being product priorities.

A profound mindset shift transforms security from a checklist into a team sport. The key enabler for this shift is blameless collaboration and regular forums for discussion. Although initial meetings may get messy, alignment will accelerate over time.

Where does AI fit into a security-as-product posture? Primarily, it is used to reduce the “noise” among the thousands of vulnerabilities that are reported and prioritize what needs to be fixed first. In large environments, the problem is not a lack of findings; it’s too many. AI helps you triage those findings, but you still need human input to make the decisions.

If you work with Terraform, OpenTofu, Helm, pipelines, and multi-environment deployments, you know that IaC gives you leverage, but that leverage cuts both ways. Here are some practical measures you can apply immediately:

• Fail PRs for misconfigurations, but make failures readable.
• Enforce tagging. This is non-negotiable.
• Integrate security tooling with your ticketing system.
• Start with report-only mode when needed.
• Automate evidence collection now, not before your next audit.
• Build shared dashboards between engineering and security.
• Treat cost governance as part of security.
• Measure remediation time, and improve it.

Remember, your leadership is not interested in the fact that you automated security; they want to know what the impact was. Nobody cares that you worked on something. They care about how it benefits the customer and the business.

Infrastructure as code provides a unique opportunity to treat security as product. When infrastructure is versioned, reviewed, tested, and deployed through pipelines, it is possible to enforce governance at scale, bake compliance into workflows, make guardrails consistent, and share visibility across teams.

However, you have to design for it. When security is bolted on, it creates friction; when it is built in, it creates velocity.

That shift from blocker to feature is a mindset change, but it is certainly one worth making.

Ruby Agarwal is a technology executive driving innovation and execution across cloud and AI, specializing in transformations. Mom, dog lover, global traveller, national park enthusiast, and artist, Ruby is Head of Avaya Cloud Platform & Infrastructure. She is a DevOps and DevSecOps leader who specializes in PCI/HIPAA/ISO27K/SOC2 compliance, CloudOps, FinOps, ProductOps, agility, and transformation.