Another Howest Tech & Meet, this time on Infrastructure as Code. Two speakers on the bill: Tim Van Roosbroeck (Business Consultant Software) and Dimitry Decan (Azure Cloud Engineer), both from Orbid.

Quick disclaimer up front: I'm about 3 years into security and just starting my first job as a security engineer. Most of what follows is me reasoning out loud, trying to connect what the speakers said to the security side I do know. Treat the security takes as logical guesses from a beginner, not battle scars.

About Orbid

Quick intro to the company before diving in:

• 200 employees
• 900 clients
• Offices in 5 locations
• 25+ years of experience in ICT, software, and HR

Orbid positions itself as a strategic partner for digital transformation, sitting at the intersection of software expertise and cloud engineering. Useful framing for the rest of the talk, because the five-level model they walked us through is essentially the path they guide their own clients along.

The 5 levels of Infrastructure as Code

The framing was a maturity ladder. Five rungs, each one moving you further away from "click around in a portal and hope you remember what you did".

Worth flagging early: not every team needs to climb all five rungs. If you're a small shop running a handful of VMs, half of this is overkill. The speakers said roughly the same thing at the end. The ladder is a map, not a target.

Level 1, Manual ClickOps

The starting point for most teams, and honestly where a lot of them quietly stay. The speakers put it at roughly 80% manual portal actions, 20% code. Fast to start, painful to reproduce, and basically impossible to audit once you have more than a handful of resources.

Tools they leaned on at this level were Azure Lighthouse (cross-tenant management) and Azure Resource Graph (custom queries to keep an overview across multiple customers). The point they hammered: once your resource count climbs, tagging is the most important factor for keeping the environment sane.

Trying to reason about this from a security angle: if you have 1 to 10 VMs and a small team that knows what each one is for, the "untracked resources" problem probably isn't a real problem. You can hold the whole picture in your head. But scale it up, hundreds of resources, multiple teams, people leaving and joining, and it seems obvious you'll end up with machines nobody remembers spinning up, running services nobody is patching. That feels like the kind of thing attackers would love. I haven't lived through it, but the logic is hard to argue with.

Level 2, Scripting

The first step away from clicking. PowerShell is still the default in the Azure world, and most of what lives here is task-oriented automation: spin this up, tear that down, rotate this key. Repeatable in theory, fragile in practice. Scripts age badly when nobody is paid to maintain them.

Level 3, Declarative IaC

The turning point. You stop describing the steps and start describing the desired state, then let the tool reconcile reality with that definition.

The recommended native tool here was Azure Bicep. The honest tradeoffs:

• Smaller ecosystem than Terraform
• Azure-only
• But: first-class Microsoft support, no extra licensing, and a much simpler syntax than ARM templates

What this level buys you is what the speakers spent the most time on. Configuration drift goes away, because the file is the truth. Costs stop sneaking up on you, because every resource lives in a reviewable definition. Auditability becomes free, because the git history is the audit log.

The audit point is the one that clicked for me. If every rule, VM, and firewall config is in a text file under version control, then after a breach you can actually look back and see what changed, when, and by whom. You don't have to ask three engineers what they remember doing six months ago. The forensics story basically writes itself, which feels like a huge upgrade even if I don't have direct experience to compare it to.

Level 4, Modular and reusable

The slogan here was "build once, deploy everywhere".

Orbid uses a baseline of about 20 resources as the standard subset they drop into client projects. On top of Azure Verified Modules (Microsoft-validated building blocks) they layer their own Orbid Verified Modules, basically opinionated wrappers that bake in their "best practice default" and cut down on inefficient deployments.

The interesting bit, for me, was the philosophy more than the tooling. At Level 3 you stop repeating yourself within a project. At Level 4 you stop repeating yourself across projects. If those default modules also happen to ship secure settings, every team that uses them inherits those settings without having to remember anything. That seems like a much better outcome than relying on a checklist nobody reads.

Level 5, Continuous and governed

The top of the ladder. IaC running through pipelines, with RBAC, policies, budget alerts, and strict naming conventions enforced by the platform itself. ClickOps gets reduced to a near-zero exception case.

The speakers mentioned that around 20% of companies are actually at Level 5, and were upfront that not every organisation needs to be. The goal is matching the level to the business, not chasing maturity for its own sake. Refreshingly grounded take, I was half expecting a "you must reach Level 5 or perish" sales pitch.

CI/CD, the engine that makes the upper levels work

You cannot really get past Level 3 without a serious pipeline behind you. The speakers split it the usual way:

• Continuous Integration, every change automatically validated and tested before it ever touches infrastructure.
• Continuous Deployment, the code is always in a state that can be released.

Practical wins they called out: faster deploys, fewer human errors, and crucially, easy rollbacks.

I think the pipeline is also where security would naturally fit in. If every change has to go through a pipeline before reaching production, then in theory that pipeline is the place to plug in checks. Catch a misconfig before it ships rather than after. Again, not something I've done, but the shape of it makes sense.

Takeaways

• The maturity ladder framing is genuinely useful. "We are at Level 2 trying to get to Level 3" is a much more honest conversation than "we should do more IaC".
• For a small team with a handful of resources, a lot of this is probably overkill. The benefits seem to scale with how much infra you have and how many people are touching it.
• The two security wins that feel obvious to me even as a beginner: knowing what you actually have (tagging, declared resources), and being able to reconstruct what changed (git history as audit log). Both feel like they would make incident response massively less of a guessing game.
• Reaching Level 5 is not the goal. Reaching the level your organisation actually needs is the goal.

Good session. Gave me a much clearer mental model of the cloud side of things, which is the side I've spent the least time on so far.