Tirsdag – 10 · HeartBox, Byscenen
Security Architect - mnemonic AS
Kristoffer has worked as a security architect for several years. The last seven years he has focused mainly on cloud security and application security. From his many engagements he has worked with companies helping them secure their cloud infrastructure and their applications.
Human error is not increasing because people are worse.
It is increasing because we deploy things we no longer understand.
The calendar reads 2026 and many organisations are cloud-first, with strict Infrastructure-as-Code policies and a “you build it, you run it” mindset. Standardised landing zones, reusable templates, and pre-built modules allow teams to move fast and scale consistently. Whether these templates come from internal teams, hyperscalers, the community, or major cloud enablers, this approach often works very well. In many cases, things run exactly as intended.
The challenge appears when layers of abstraction accumulate. As systems grow more complex, flawed designs and security-relevant assumptions become harder to spot and harder to reason about. Teams deploy Infrastructure-as-Code they do not fully understand. A configuration that appears safe in a test environment may become insecure once it is promoted to production and exposed to real traffic and real threat actors.
To reduce this risk, organisations introduce policies, guardrails, and verified modules. These controls are necessary, but they have limits. When complex distributed systems are assembled from many interacting modules across cloud services, platforms, and runtimes, guardrails alone are not enough. If we do not understand the resulting infrastructure we are deploying, securing it becomes largely guesswork.
Infrastructure as Code is a powerful abstraction, but it does not remove responsibility. The architecture and the infrastructure are still real, even when hidden behind templates, Kubernetes, containers, or managed services. Working code is not the same as safe infrastructure.
This talk argues that templates and IaC are not a replacement for understanding and skilling. Just because a module works, or can be made to work, does not mean it should be deployed. In an environment where speed is rewarded and abstraction is the norm, rebuilding technical understanding must be treated as a core security control, not an optional nice-to-have.
Programmet er oppdatert.