Klarrio's Security-by-Design Bet: Why Compliance Comes Last

Building secure software is a bit like wiring a house. You can do it properly while the walls are still open, with the electrician walking the plans alongside the architect, or you can wait until the family has moved in and start ripping plasterboard off to chase a fault. Both approaches end with working lights. Only one of them lets you sleep at night, and only one of them comes in on budget. Klarrio's new white paper is basically a long argument that the industry keeps choosing the second option, then acting surprised when the wiring catches fire.

What Happened

Klarrio has put out a white paper on security by design in cloud-native software development, and the central claim is sharper than the usual vendor fare. As Techzine Global reported, the company argues regulatory compliance should be the result of strong security practices, never the primary reason for them. Tick-box compliance, they say, creates a false sense of safety while the real risks sit quietly in the corner.

The backdrop is grim. Global annual cybercrime costs are projected to exceed $1.2 trillion by the end of 2025. AI-powered attack tools are lowering the barrier to entry for malicious actors, and the kit you used to need a team for, deepfakes for phishing, automated hacking tools, is now widely available to anyone with a browser and bad intentions.

Into that mess walks a wave of European regulation. The NIS2 Directive and the EU's Cyber Resilience Act both require organisations to take proactive security measures, and Klarrio reckons most companies are drowning in the pile. The white paper pitches a different model: risk-based security, where priorities are set by the threats most relevant to a given organisation's actual activities, not by whichever framework column happens to be empty.

To back the philosophy, Klarrio describes its Security Framework operating with three roles, blue, red and purple teams, and a Security Champions program it launched in early 2025 to structurally embed security into the development culture. The headline economic argument is the one that should make every CFO sit up: building security in adds roughly ten percent to development cost, while bolting it on afterwards can cost ten to fifteen times as much.

Technical Anatomy

Strip the white paper of its marketing layer and what you have is a quiet broadside against the supply chain. Klarrio notes that modern platforms consist of seventy to ninety percent open-source components, everything from Kubernetes to the wider CNCF ecosystem. That is not a rounding error. That is the building.

The transparency-and-speed pitch for open source is real and well rehearsed, but the flip side is an attack surface that grows every time someone runs npm install or pulls a fresh Helm chart. Anyone who has spent a Sunday morning chasing a transitive dependency CVE knows the pattern: the vulnerability isn't in the code you wrote, it's in the code you trusted three layers down. Klarrio's response is selection criteria applied before a component is eligible for the platform at all, which is the boring bit of supply chain security that nobody photographs for a keynote slide.

The three-team setup is where the engineering culture piece lives. The blue team designs and implements defensive measures. The red team actively identifies vulnerabilities, the in-house adversary. The purple team's job is the part where it all falls over in most organisations: facilitating knowledge exchange between blue and red so findings actually become fixes, not Jira tickets that age into archaeology.

Layer the Security Champions program on top and you have an attempt to push security ownership out of a central team and into the product squads. That matters because the developers writing the Terraform and the controller manifests are the only ones who can make security decisions at the velocity cloud-native demands. A central team gating every merge is the architectural pattern that gave us six-month release cycles, and nobody is going back.

The risk-based piece is the most honest part of the framework. NIS2 and the Cyber Resilience Act are written in the language of obligation, but threats don't read directives. A payments platform and a content site face wildly different adversaries, and pretending otherwise is how you end up with hardened login flows and a wide-open admin API.

Who Gets Burned

The teams most exposed by Klarrio's argument are the ones who have spent the last eighteen months building compliance programmes around NIS2 and the Cyber Resilience Act as if they were the goal rather than the floor. Regulated industries, fintech, iGaming, payments, critical infrastructure adjacent SaaS, are particularly prone to this. When the auditor's checklist becomes the engineering roadmap, you optimise for the audit and lose the plot on the threat model.

Open-source-heavy platforms feel the squeeze hardest. If your stack is seventy to ninety percent borrowed code, your security posture is essentially a bet on other people's release discipline. Most engineering orgs I've seen treat dependency selection as a developer-time convenience decision: does it have a nice API, is the docs site readable, does it have stars on GitHub. The Klarrio model demands you treat it as a risk decision, which means somebody senior has to say no to a popular library because the maintainer cadence is sketchy. That is a hard conversation, and most teams don't have anyone willing to have it.

The next ninety days will sort the serious from the performative. CTOs who have been quietly hoping NIS2 was a paperwork exercise will discover their boards have read the same press their auditors have. Anyone running a B2B platform into EU customers is going to start seeing security-by-design language in procurement questionnaires, and "we are NIS2 compliant" will stop being an acceptable answer when the follow-up is "show me your threat model".

The other group caught short: organisations that planned to retrofit. The ten-percent-up-front versus ten-to-fifteen-times-after maths is not subtle. If you have a platform in production now that was built without a serious threat modelling phase, the bill is already accruing. You just haven't opened the envelope.

Playbook for Engineering Teams

Start with an honest dependency audit. Not a Snyk report, an actual conversation about which of your seventy-to-ninety-percent open-source components have a real maintainer, a real security disclosure process, and a real release cadence. Klarrio's selection criteria approach is the right pattern: gate components at intake, not at incident.

Stand up a purple-team function even if you can't afford a separate red team. The role that actually moves the needle is the translator, the person whose job is making sure pen-test findings become engineering work. Without that role, red team output becomes a PDF nobody reads.

Pick a Security Champions model and resource it properly. One engineer per squad, with allocated time, not a volunteer rota that collapses under sprint pressure. The point is to make security a property of how the team writes code, not a gate it passes through.

Rebuild the compliance narrative inside-out. Map your NIS2 and Cyber Resilience Act obligations onto your actual threat model, not the other way around. If the threat model produces controls the regulation also wants, you get compliance for free. If you start from the regulation, you get a binder.

And do the maths in front of your board. Ten percent during development versus ten to fifteen times after is the single most useful number in the white paper. Put it on a slide.

Key Takeaways

• Klarrio's core argument: compliance is a side effect of good security, not the destination. Tick-box NIS2 and Cyber Resilience Act programmes create a false sense of safety.
• The economics are stark: security built into the design costs about ten percent more during development, while retrofitting can cost ten to fifteen times as much.
• Modern platforms are seventy to ninety percent open-source, from Kubernetes through the CNCF ecosystem. That is your real attack surface, and most teams don't gate it.
• The blue/red/purple team model only works if the purple function genuinely closes the loop between finding vulnerabilities and shipping fixes.
• The Security Champions program, launched by Klarrio in early 2025, is the cultural pattern worth copying: push ownership into product squads instead of bottlenecking on a central team.

Back to the half-wired house. The industry has spent a decade pretending you can move in first and let the electrician work around the furniture. Klarrio's white paper is a reminder that the cost of that choice is not theoretical, it's a multiplier, and the regulators are about to start reading meters.