Kevin Korte

For decades, technology has been a service within the company. It was seldom more than an afterthought to C-Suits and Boards. It was something attached to marketing and operations. Our increased reliance on tech and the prevalence of Open Source are quietly changing how boards think about technology risk. Especially in light of the latest IT failures and the ever-increasing demand for AI, Open Source has risen to the forefront of digital transformation initiatives. After all, it does not just cut costs. Open Source rewires how users, administrators, and executives see dependence, resilience, and strategic control over your digital backbone.

From “Black Box Risk” To

For decades, most strategy-level technology decisions have been left to IT departments or even vendors. Organizations signed multi‑year contracts, accepted closed platforms, and hoped the provider’s roadmap would stay aligned with the company’s strategic goals. Risk conversations focused on service-level agreements, indemnities, and how quickly the vendor would patch the next headline vulnerability. In that world, technology risk was a black box. You could audit processes around the software, but not the software itself.

Open Source shifts that conversation from blind trust to inspectable risk. Because the code is visible, your teams or partners can look for backdoors, weak cryptography, or hard-coded credentials rather than relying on statements in a pitch deck. During my time at Univention, I saw public-sector customers who would not have been allowed to deploy identity software unless their own experts reviewed the source code first. They were not trying to second‑guess every implementation detail. They simply wanted the option to verify that no one had quietly built in a side door.

This inspectability changes how you manage worst‑case scenarios. With closed software, your contingency plan is often “wait until the vendor fixes it.” With Open Source, you have an additional path: assign internal engineers or hire external experts from the community to fix or harden the code, even if the original maintainer is slow to react. On the strategic level, these options give you the flexibility to act and maintain agility when the world crumbles.

When Open Source AI Clarifies And Amplifies Risk

Interestingly, more boards have recognized this issue regarding AI. For boards, the first consideration for AI wasn’t technical but how to maximize shareholder value. The reframing has moved all considerations from a merely technical change into the strategic realm.

Yet AI projects ultimately face the same risk factors as the rest of AI. Can we build and control it? Do we want our most critical decisions to run through models we cannot inspect, or through systems where at least the architecture, interfaces, and safeguards are open to scrutiny?

Open Source AI frameworks show both sides of this trade‑off. A recent incident involving the Open Source Ray framework exposed thousands of companies, from Uber to cloud providers, to attackers who could steal credentials, control servers, and corrupt AI models. On the surface, this looks like a reason to retreat from open tools. But look closer at what happened next. Security researchers could analyze the flaw, reproduce attacks, coordinate fixes, and publish hardening guidance without waiting for a single vendor’s permission. The same openness that created a broader attack surface also enabled a faster and more transparent response.

Following the Cybersecurity Vulnerability and Exposure announcements isn’t the board’s responsibility. However, as board members, we should notice the broader pattern. AI systems built on open components allowed visibility into where risk sits. It showed which framework, which deployment pattern, and which configuration were affected. This knowledge made it easier for IT departments to respond and also enforce consistent security controls.

For one of my financial services clients, standardizing AI workloads on a hardened, largely open stack allowed the board’s risk committee to move from “we have dozens of AI experiments somewhere in the organization” to a simple question: “How many workloads run on the approved, monitored platform, and what exceptions have we allowed?” That is what Open Source can do: turn vague concern into tractable oversight.

Cybersecurity: from secrecy to shared defense

The above example also contradicts one misunderstanding about Open Source. If attackers can see the code, does that not make life easier for them? This concern is understandable, but it confuses secrecy with security. Most serious standards bodies now explicitly warn against relying solely on “security through obscurity.”

In Open Source security tools, the risk equation changes from “can we hide enough?” to “can we respond fast enough?” When a critical vulnerability is discovered in an open library, thousands of engineers across companies and countries begin investigating it. Patches are proposed, reviewed, and deployed in hours or days, not weeks. At Univention, we saw school systems and satellite operators rely on this dynamic. They could not afford to wait for a distant vendor’s quarterly patch cycle to secure identity systems used by millions of students or to protect ground‑station links. Instead, they built their security posture around open components that the global community was already closely monitoring.

Of course, openness does not absolve an organization of its responsibility. When an AI‑related vulnerability like the ShadowRay campaign emerges, organizations that have simply copied open components without governance are exposed just as badly as those who bought a vulnerable proprietary product. The difference is in what happens after discovery. With an open stack, your CISO can mandate specific versions, apply custom hardening, and even fund upstream fixes that align with your risk appetite. That turns your company from a passive licensee into an active participant in its own security destiny.

What Boards Should Ask Next About Open Source?

If you sit on a board, the question is no longer “should we use Open Source?” You already do, through your operating systems, development tools, cloud platforms, and security libraries. The real question is whether you treat that reality as unmanaged exposure or as a strategic advantage. Open Source reshapes risk by shifting the right levers. You can see more of what is under the hood. You can act faster when things go wrong. You can avoid staking your entire digital future on a small set of opaque vendors.

This does not mean every system must be open. There will always be domains where proprietary products make sense, and open models like AI require careful access control to prevent abuse. But over time, boards that make openness, transparency, and interoperability default requirements will find their risk discussions calmer and more concrete. Instead of debating marketing claims, you can ask simple, testable questions: can we inspect it, can we move it, and can we fix it if we have to?

In a world where AI, cybersecurity, and identity are deeply intertwined, those questions may be among the most powerful tools a board has. Open Source does not remove risk, but it makes risk visible and, with the right governance, manageable. That is why the shift toward open is not just a developer preference. It is becoming a board‑level strategy.