Stop Hard-Coding Security: Why Declarative, Inherited Security Needs a Platform (Not Just Policies)
- Joel Van Dyk
- Feb 12
- 5 min read
Updated: Mar 23
Most enterprise security environments still suffer from the same disease: security logic is scattered, duplicated, and inconsistently enforced across applications, platforms, and teams.
One app checks group membership one way. Another hard-codes roles in config files. A third implements its own token parsing, its own policy logic, and its own edge cases.
This is how you get drift. This is how you get gaps. And this is how you end up with “surprise” access paths no one can fully explain.
Modern cloud platforms—AWS, Azure, and GCP—solved this problem years ago with a different model:
Declarative security, inherited through a common framework, fed by a central source of identity and policy—and exposed through a standard platform layer.
If you want security that scales, that’s the model you should be using too.
The Root of the Problem: Imperative Security
In most legacy environments, security is imperative:
Developers write code that says how to check access.
Each service implements its own logic.
Authorization rules live inside applications.
Identity context is interpreted differently everywhere.
That means:
Policy is duplicated.
Behavior diverges over time.
Auditing becomes a forensic exercise.
Changes require code changes (and redeployments).
You never quite know if “the rule” is actually enforced everywhere.
Worse: your security posture becomes an emergent property of thousands of code paths instead of a deliberate, reviewable design.
Understanding Declarative Security
Declarative security flips this around.
Instead of embedding logic, you define:
Who can access what.
Under which conditions.
Enforced by a shared control plane.
Examples you already use:
AWS IAM policies.
Azure RBAC + Conditional Access.
GCP IAM.
Kubernetes RBAC / admission policies.
OPA / Cedar / Rego-style policy engines.
You don’t write code that says how to evaluate access.
You declare the policy:
“Service A can read Resource B if it has Role X and the environment is Prod.”
The platform enforces it. Consistently. Everywhere.
Inheritance: The Real Scaling Trick
The real power move is not just declarative policy—it’s inheritance.
In mature environments:
Identity comes from a central authority (IdP / IAM).
Authentication is standardized (OIDC, SAML, mTLS, workload identity).
Authorization is policy-driven and centrally governed.
Every app, API, and service inherits these controls by default.
This means:
Apps do not implement their own auth logic.
Services do not define their own role systems.
Teams do not invent their own permission models.
Security becomes a platform capability, not an application feature.
This is exactly how AWS, Azure, GCP, and most large enterprises work (I spent a large part of my career helping develop and then enforcing this at one firm):
Identity is centralized.
Policy is declarative.
Enforcement is uniform.
Services consume security; they don’t reinvent it.
Your internal platforms should work the same way.
The Missing Layer: An Enterprise Security API & Middleware Framework
Here’s where most enterprises stumble in practice.
You can have:
A great IdP.
Beautiful policies.
A solid authorization model.
…and still fail if every application team has to hand-roll integrations.
What you actually need is:
A general Enterprise Security API framework: a shared middleware layer that exposes authentication and authorization as simple, consumable platform services.
Think of it as “glue” to hold your Identity environment together:
A security control plane for applications.
A standard integration surface for:
- Authentication.
- Token validation.
- Identity context.
- Authorization decisions.
- Policy queries.
- Attribute and claim resolution.
Instead of every app doing this:
Parsing tokens differently.
Calling the IdP differently.
Interpreting claims differently.
Re-implementing authorization checks differently.
They do this:
“Call the security platform. Ask if this is allowed. Enforce the answer.”
That’s it.
Just like apps in AWS don’t implement IAM—they consume IAM.
Why This Matters (Especially in Real Enterprises)
In theory, this sounds obvious. In reality, there’s a brutal constraint:
Many security organizations do not have deep, scalable software engineering capacity.
So what happens?
Security publishes “standards”.
Teams implement them inconsistently.
Reference libraries drift.
Copy-paste becomes the integration strategy.
And five years later, you have 12 “standard” ways to do auth.
A proper Enterprise Security API layer:
Encodes best practices once.
Centralizes complexity.
Gives developers a boring, stable, well-documented interface.
Lets security teams improve enforcement without changing every app.
Dramatically reduces the skill barrier to “doing security correctly”.
It turns security from guidance into infrastructure.
What This Looks Like in Practice
A well-designed model has four layers (see the diagram):
Central Identity Source
Workforce + workload identities.
Standard claims, attributes, group/role semantics.
Central Policy Layer
Declarative authorization policies.
Context-aware, attribute-based, environment-aware.
Versioned, reviewed, testable.
Enterprise Security API / Middleware
Standard authN & authZ interfaces.
Token handling, context enrichment, policy evaluation.
SDKs, sidecars, gateways, or service mesh integration.
Opinionated, boring, reliable.
Applications as Policy Consumers
They receive identity context.
They ask: “Is this allowed?”
They do not own policy logic.
Security becomes inherited by default, not reimplemented by exception.
Why This Is So Much Better
You get:
✅ Consistency – One policy model, one enforcement path.
✅ Auditability – Policy is visible, reviewable, testable.
✅ Scalability – New services inherit controls automatically.
✅ Velocity – Change policy without redeploying everything.
✅ Risk Reduction – Far fewer bespoke security implementations.
✅ Real Zero Trust – Decisions based on identity + context, not network location.
Most importantly:
You move security from “best effort per team” to guaranteed by architecture.
The Strategic Shift
This isn’t a tooling change. It’s an operating model change:
From app-owned security → platform-owned security.
From imperative checks → declarative policy.
From duplicated logic → inherited controls.
From tribal knowledge → explicit, enforceable rules.
From “standards documents” → actual security infrastructure.
Cloud providers didn’t converge on this model by accident. They did it because it’s the only way security works at scale.
Bottom Line
If you want:
Fewer incidents.
Faster delivery.
Better audits.
Real consistency.
And security that doesn’t depend on every team “getting it right”.
Then:
Centralize identity. Declare policy. Expose it through a security platform. Enforce it everywhere. Let everything else inherit it.
That’s what modern enterprise security actually looks like.
The Future of Security in Organizations
As we look ahead, the landscape of cybersecurity continues to evolve. Organizations must adapt to new threats and challenges. The shift towards declarative security is not just a trend; it’s a necessity.
By embracing this model, organizations can ensure that their security measures are not only effective but also efficient. This approach allows for rapid scaling and adaptation to changing environments.
Embracing Change
Change can be daunting. However, it is essential for growth. Organizations that resist change may find themselves vulnerable to emerging threats.
It’s crucial to foster a culture of continuous improvement. Encourage teams to collaborate and share best practices. This will lead to a more robust security posture.
Conclusion: A Call to Action
In conclusion, the path to effective cybersecurity is clear. Organizations must centralize their identity management, declare their policies, and expose them through a unified security platform.
Let’s not wait for a breach to act. The time to invest in a solid security framework is now. By doing so, we can protect our assets and ensure a safer digital future.
Remember, security is not just a technical requirement; it’s a fundamental aspect of organizational success. Let’s make it a priority.
Comments