Assess the tenancy, not the Terraform

When we start an Oracle Cloud security review, the first thing offered is usually the repository: the Terraform, the pipeline, the module structure. It is offered in good faith, and it is genuinely useful context. It is not the tenancy.

Intent versus reality

Infrastructure-as-code describes what someone meant to build at the time it was last applied. Tenancies diverge from that description for ordinary reasons. A console change made during an incident. A compartment created by a project team with its own budget. An identity domain added when a SaaS integration needed it. A security list opened "temporarily". None of these are failures of the people involved. They are what happens to any estate that is in use.

A review that reads the code will confirm the design. A review that reads the tenancy will find the drift. Only one of those is a security assessment.

Code states intent. Drift is where the findings live.

How we capture the current state

We still start from the intended design, because it is the fastest way to a good picture. Before the first working session we build a draft of the current-state diagram from whatever documentation and code exists: compartment tree, network topology, identity domains, integration endpoints. Every area of that diagram carries a red dashed box marked VERIFY.

Then we verify, area by area, against the live tenancy: console, CLI, audit log, and the read-only compliance script your administrator runs. Each red box either clears or becomes a correction. Corrections are drift. Drift becomes numbered findings.

This does two things a blank-page assessment does not. It makes verification a checklist rather than an exploration, which is faster and more complete. And it turns the diagram into a progress tracker: the count of remaining red boxes is the honest answer to "how far through the review are we?"

What drift looks like in practice

The categories repeat across estates of very different sizes.

• Identity. An administrator role granted directly to a user instead of through a group. A federation set up on the default domain when the design called for a separate one, or the reverse. Service accounts created for a migration and never removed.
• Network. Security lists that permit more than the network security groups on the same subnet, so the effective rule is the wider one. A public subnet that the design shows as private. A bastion that was meant to be the only path and is not.
• Integrations. Connections in Oracle Integration Cloud on Basic authentication because the OAuth client was "coming later". A shared OAuth client reused across several integrations, which works until two of them refresh a token at the same moment.
• Posture tooling. Cloud Guard enabled in one region and not another. Detector recipes cloned and never updated.

Each of these is invisible in the repository and obvious in the tenancy.

Why this is not a criticism of the team

Drift is a property of estates, not of engineers. Estates that are in use accumulate it. The purpose of assessing the live tenancy is not to find someone at fault; it is to make the document match the world, so that the next change is made against an accurate picture. We write findings in that register, with evidence, and we write the remediation in the build document so that when the repository is next updated, intent and reality are the same thing again.

The one exception

There is one place we do read the code closely: the pipeline that applies it. Who can run it, from where, with what credentials, and whether a change to the identity module can be merged without a second reviewer. That is a control, and controls are assessed wherever they live.