Those who build in security only after the fact pay up to fifteen times the original cost. That’s why a strict ‘Security by Design’ approach and close interaction between blue and red teaming are crucial. A keen eye for the risks of open-source components is also required. Such choices need not be an obstacle to innovation but are simply the only rational options. We discussed this with Klarrio, a platform engineering firm with complete teams dedicated to translating Security by Design into practice.
Security is a cost that companies all too often prefer to postpone, until postponement is suddenly no longer an option. Klarrio, which builds foundational data platforms based on open-source technology, sees this pattern recurring regularly in the market. And the bill for that postponement is substantial every time. Those who incorporate security directly into the design of a new system via the principles of Security by Design pay roughly ten percent extra on initial product development. Those who skip that step and have to retrofit systems with security measures later on pay ten to fifteen times as much. Although this isn’t exact science, R&D Director Werner Vermeylen emphasizes that the order of magnitude is undoubtedly correct. Broad industry studies even show that recovery costs following an incident or involving complex modifications can be up to a hundred times higher in more extreme cases.
However, the damage to organizations doesn’t stop there. In addition to enormous direct remediation costs, heavy fines loom for non-compliance with regulations such as the GDPR and the new NIS2 directive. On top of the financial blow comes the reputational damage that inevitably drives customers away. At the same time, internal development teams are slowly but surely becoming exhausted because they are constantly busy patching unexpected vulnerabilities instead of building innovative new functionalities. Information Security Officer Roel Van Nyen calls this phenomenon ‘security fatigue’. It’s a critical condition in which the agility and innovative capacity of an entire organization grind to a complete halt. To prevent such a doomsday scenario, Klarrio has developed a robust framework that weaves security into the DNA of every development phase.
Build blue, think ded
The foundations of Klarrio’s successful approach rest on the dynamic between three abstract roles: the blue team, the red team, and the purple team. These roles ensure that platform security is approached and challenged from every possible angle. The proactive work begins with the blue team, as soon as a platform or a new feature is first placed on the drawing board. Staff Security Architect Joris Gorinsek explains that you can only secure something truly if you have a deep understanding of exactly what you are building. That process invariably starts with threat modeling. In this process, the team puts itself in the shoes of a hacker: what are the most interesting targets, and where are the weak points to intervene? Based on this analysis, the defense mechanisms are defined and immediately incorporated into the basic design. As a result, security is not an afterthought but is inextricably present from the very first sketch.
Yet, a designer or programmer doesn’t naturally think like a malicious hacker. A developer logically focuses on how the system is supposed to work under ideal conditions. An attacker, on the other hand, deliberately searches for all deviating paths and unexpected openings in the code. To safeguard this critical mindset internally, Klarrio actively deploys a red team. These experts are explicitly instructed to think and act like hackers, yet they simultaneously possess in-depth internal knowledge of the platform’s architecture. This white-box approach enables them to search for vulnerabilities much more proactively and efficiently than an external party operating without that specific background knowledge.
Within this framework, purple can also be mentioned as a third color; however, the purple team isn’t a separate, physical department on the office floor, but the direct result of the interplay between red and blue. Attackers and defenders work continuously hand in hand to forge a more secure end product. According to Vermeylen, this way of working is an absolute matter of course at Klarrio. Because the blue and red teams already collaborate so closely internally, purple essentially forms the natural, automatic zone in which it operates daily. This internal process certainly doesn’t render independent external penetration tests superfluous. On the contrary, Klarrio views its own red team exercises as an extremely rigorous preliminary check. Customers subsequently still engage external parties for an objective and independent audit to certify the final platform.
Open source is transparent and a growing target
Klarrio builds its platforms largely on carefully selected open-source components. This is due to a vendor-agnostic philosophy and the broader desire to promote European cloud sovereignty. By working with fully fledged European alternatives such as Exoscale and OVH, the company avoids a heavy dependency on proprietary software from American hyperscalers. Nevertheless, the use of open source entails specific risks, primarily in the complex area of supply chain security. Hackers are increasingly targeting the popular underlying open-source projects that are deeply rooted in the supply chains of thousands of companies. A well-known example of this is the xz backdoor, an incident in which a patient attacker operated as a legitimate contributor for years to eventually, silently, implement malicious code. Because seventy to ninety percent of modern corporate code now consists of open-source components, the ultimate impact of just one compromised project can be truly disastrous.
To effectively contain this insidious risk, Klarrio applies a strict set of screening criteria before an open-source component is even considered for a project. A critical look is taken at exactly who manages the project as well as the procedures by which new contributors and their code are verified. Finally, Klarrio considers whether the project is actively and soundly maintained, ensuring that newly discovered vulnerabilities will be patched in a timely manner, even in the distant future.
To get an overview, a Software Bill of Materials (SBOM) is used by default. This is essentially a highly detailed digital inventory list of all components and dependencies located within a specific product. Because this SBOM is continuously linked to current global databases of known vulnerabilities, the system generates an immediate warning as soon as a security issue arises anywhere. Gorinsek indicates that if a new critical flaw of the Log4Shell caliber is discovered tomorrow, the team will know, thanks to the SBOM, exactly where in the platform the vulnerable version of the software is located within seconds.
Tip: “Blind AI deployment leads to knowledge loss and software failures”
The human link and the rise of AI code
No matter how advanced and watertight the technology may be on paper, the human factor invariably remains the weakest link. It is rarely the brilliant, technically complex exploit that causes a data breach. Often, simple misconfiguration, a misunderstood internal request, or a developer granting admin privileges thoughtlessly and hastily tops the list of incident causes. Moreover, in the current climate, zero-day vulnerabilities are actively exploited within minutes of discovery, placing immense daily time pressure on security teams.
To address this human aspect structurally and positively, Klarrio launched a formal Security Champions program in early 2025. Through this initiative, every development team is assigned at least one ‘champion’. This colleague acts as the accessible first point of contact on the work floor for all security-related questions and simultaneously bridges the necessary gap to the specialized security architects. Gorinsek states that there are three strict conditions for the success of such a concept. First, the absolute top management must clearly convey the energy and message that security is a top priority. Second, all employees must understand the context and realize why this focus is so crucial for the survival of the projects. And finally, the teams must receive the right tools and training to know how to apply this in daily practice.
Management directly facilitates this cultural change by explicitly allocating ten percent of working time to security-related activities. The developers receive intensive training in topics such as threat modeling, robust authentication standards like OpenID Connect, and fending off threats from the well-known OWASP Top 10. The ultimate, overarching goal is for security to no longer feel like a mandatory obstacle, but rather an integral part of the standard way of working.
This heightened vigilance in the workplace has become more urgent due to the rapid rise and integration of AI-generated code in software development. Van Nyen warns that it’s absolutely insufficient to merely know superficially which AI models are being used by developers. It’s at least as important to critically verify the origin of the AI-generated code and to tightly regulate how it is processed in the final production environment. Recent publications regarding incidents at AWS prove that this isn’t an abstract or theoretical risk. There, AI-generated code deployed by less experienced employees without sufficient oversight led to significant system failures. If even the largest, seemingly most robust organizations in the world run into this problem, it certainly underscores the need for rigorous internal processes.
Limiting the impact of an attack
In addition to continuously training its own staff, Klarrio invests heavily in architectural choices that minimize the impact of a successful cyberattack. The Zero Trust principle is central to this vision. Whereas classic network security in the past relied heavily on a strong, static perimeter, Zero Trust is based on the hard reality that no network or individual component is secure by definition. Within a Zero Trust architecture, every single component, whether a database or a microservice, must continuously prove itself to the other components. This happens with every interaction, regardless of whether the request originates from within or outside the network. If an attacker unexpectedly manages to penetrate one specific part of the vast data platform via a ruse or vulnerability, they cannot simply move freely to the rest of the ecosystem. As a result, the direct impact zone of the incident remains strictly limited to that single compromised component. This containment prevents large-scale data loss and significantly simplifies and accelerates the subsequent recovery process.
In this context, Vermeylen also emphatically points out the importance of active log monitoring. Advanced systems that analyze all log streams in real-time and immediately detect anomalous behavior—such as a compromised user account suddenly attempting to export terabytes of sensitive customer information to an unknown cloud service in the middle of the night—can automatically generate alerts or terminate connections. At the same time, he adds an important technical caveat. The monitoring tools themselves must also be configured with the utmost care and security. If this isn’t done, these systems unintentionally transform into a massive security risk, because they conveniently bundle all the sensitive data and login patterns that an organization is trying to protect onto a single, centralized platter for cunning attackers.
Compliance is the result, not the goal in itself
Ultimately, companies operate in an increasingly complex landscape that is being regulated at a rapid pace by weighty European legislation. Directives such as NIS2, the Cyber Resilience Act, and the highly impactful European Product Liability Directive are increasingly determining the rules of the game. The latter directive goes to unprecedented lengths in terms of consequences, as manufacturers of software products can henceforth be held directly and severely liable for significant damage resulting directly from insufficient or defective security of their product. While Klarrio wholeheartedly agrees with the necessity of such strict regulations to protect the digital society, experts strongly warn against the pitfall of checkbox compliance. This is the dangerous practice whereby companies tick off lists purely as a process to appear formally compliant on paper, without increasing the technical security of their systems in any real sense.
In this regard, Gorinsek expresses the firm expectation that an entire, opportunistic economy of small audit firms will emerge in the coming years. These firms will provide organizations with the coveted ‘compliant’ stamp for a quick fee, inadvertently leading to a false sense of security in boardrooms. But Klarrio’s approach is based on a different and much more deeply rooted premise. Compliance must always be the logical result of very robust and well-thought-out security practices, and never the initial reason for implementing those practices. Vermeylen summarizes this philosophy by stating that when an organization operates ‘Security by Design’ from the ground up, becoming formally compliant with new legislation is just a relatively small administrative step. However, if you have to retrofit those same stringent security requirements years later onto a fundamentally insecure, outdated solution, it quickly becomes a virtually impossible, frustrating, and above all, prohibitively expensive undertaking.
Ultimately, of course, the harsh reality doesn’t start with a blank sheet of paper for every project, also known as a greenfield scenario. Many large organizations are forced to turn to Klarrio with massive, outdated systems to which modern security must be added retrospectively. These retrofit situations are extraordinarily complex and risky to execute. A single security adjustment implemented at the fundamental platform level can unintentionally have a severe impact on all connected, outdated applications, causing systems to fail suddenly. In a new greenfield project, that significant architectural complexity is also present at the base, but this challenge is factored into both the timeline and the budget from day one.
For Klarrio, therefore, security is never a strictly defined project that is definitively closed with a handshake after successful delivery. It is an ongoing process of continuous measurement via standardized models, proactive monitoring, and immediate adjustment as soon as the environment demands it. Only with that mindset, embraced and understood by all levels of the entire organization, can a data platform truly withstand the threats of today and the unpredictable dangers of tomorrow.
Tip: Klarrio uses open source expertise to build foundational data platforms