Every public supply-chain incident produces the same meeting. One side proposes replacing the open-source component with a commercial product, on the grounds that a vendor is accountable and open source is a free-for-all. The other side argues that open source is safer, because anyone can inspect the code and the community responds quickly.
Both arguments contain something true, and neither is a basis for a decision. Commercial products routinely embed open-source components, so buying one does not remove the open-source supply chain; it hides it behind a contract. And "anyone can read it" is not the same as "someone did read this release".
Langeberg Software is fictional, and its systems and figures are illustrative. After the incident in Part 3, Langeberg's leadership asked the obvious question: should we replace the open-source gateway with a managed commercial one? This part is about how the platform team answered it.
CloudNala's view is that "open source" and "commercial" are licensing and support models, not risk ratings. The useful question about any component is what evidence exists about how it is built, maintained and released, and how it is contained in your environment.
Replace the stereotype with a question
Each stereotype converts into a question that can be answered.
"Open source is risky" becomes: who maintains this, how active are they, and how quickly and openly have they handled problems before? A project with several active maintainers, protected release processes and a record of clear advisories is a different proposition from a single-maintainer project last updated a year ago.
"A vendor product is safe" becomes: what does the vendor ship inside it, how do they manage their own dependencies, and what will they tell you during an incident? Ask for their bill of materials and their advisory process. Many will provide both. Some cannot.
"Popular means vetted" becomes: who has actually reviewed this release? Popularity means many eyes are available; it does not mean they looked. Popular packages are also preferred targets, because a compromise reaches more victims.
"Permissive licence, done" becomes: do the licences of the model weights and datasets match the code's? An open-source serving framework running a model with a restrictive licence is a licensing question the code licence does not answer.
Signals you can actually check
Some of this evidence can be gathered systematically. The OpenSSF Scorecard project runs automated checks against open-source repositories and scores each from 0 to 10: whether branches are protected, whether code changes are reviewed, whether releases are signed, whether CI tokens follow least privilege, whether known vulnerabilities are outstanding, and more. It is a useful first pass, not a verdict. A high score says the project's practices look sound from the outside. It does not say a particular release is safe.
Other signals need a person:
- Maintainer base. How many people can publish releases, and how is publishing protected?
- Release integrity. Are releases built in CI and signed, with provenance a consumer can verify? Frameworks such as SLSA describe what good looks like.
- Advisory history. When something went wrong before, how fast and how clearly did the project respond? The March 2026 incident covered in Part 1 is a useful example in its own right: the project published a dated advisory with affected versions, indicators of compromise, remediation steps and a list of verified safe versions within days. That response is evidence, and it counts in the project's favour as much as the compromise counts against it.
- Dependency footprint. How many dependencies does it pull in, and how many of those are themselves well maintained?
The same questions apply to a commercial product, asked of the vendor instead of read from a repository.
Signals set the controls; they do not replace them
The mistake to avoid is treating a strong signal as permission to skip the basics. Every component, whatever its signals, is pinned, inventoried and contained, as described in Parts 2, 6 and 7. Signals decide how much additional scrutiny and containment a component needs on top of that.
Strong signals justify standard containment and normal review: pinned versions, scanning, the egress and identity controls from Part 7, upgrade records.
Weak signals do not mean "reject". They mean the component runs with tighter containment, more review on each upgrade and a date to revisit, or that someone with authority accepts the risk explicitly and in writing.
What Langeberg decided
The platform team compared three options for its gateway: stay on the open-source project, move to a managed commercial gateway, or move to the gateway capability bundled with one of its cloud providers. They scored each on the same questions.
| Question | Open-source gateway | Managed commercial gateway | Cloud provider's gateway |
|---|---|---|---|
| Who maintains it, how is release protected? | Active project, CI release, signed images | Vendor; process described on request | Provider; process documented |
| What is inside it? | Fully visible; SBOM generated by Langeberg | Partially disclosed | Not disclosed in detail |
| How does it handle incidents? | Public, dated advisories | Contractual notice period | Provider security bulletins |
| Can Langeberg contain it? | Fully: self-hosted, own network | Partly: traffic leaves Langeberg's network | Partly: within provider controls |
| Where is the data processed? | Langeberg's chosen region | Vendor's regions | Provider's regions |
| Lock-in | Low | Medium | Medium to high |
Values are illustrative and reflect Langeberg's situation, not a general ranking.
They stayed on the open-source gateway, with the pinning, inventory, containment and upgrade records from this series in place. The deciding factor was not open versus closed. It was that self-hosting let them contain the component fully and keep data processing in a South African region their customers expected, and that the project's own incident response was better documented than the alternatives' contractual promises. A different organisation, with a smaller platform team and different data constraints, could reasonably reach the opposite answer. The point is that it would be reaching it on evidence.
For the broader procurement view, including when to build, buy or grow capability, see Buy, build or grow?.
The series in one paragraph
Shared AI infrastructure is software supply chain, with unusual reach. Pin every version and upgrade deliberately. Know the containment sequence and keep the evidence that answers "were we exposed?" Treat skills, MCP servers, prompts, models and datasets as inventory with owners and a record of what they touch. Design containment in so a compromise is bounded even when it is not prevented. Record upgrades as decisions. And judge components on evidence about how they are built and how they are contained, not on whether their licence is open.
Back to the start: Part 1, Your AI gateway is part of the software supply chain. All parts are on the series page.
How CloudNala can help
We help teams make component decisions for AI infrastructure on evidence: maintainer and release signals, vendor questions, containment options and data-location constraints, scored side by side for their own situation. The output is a decision record the team can defend to leadership, customers and auditors, whichever way it goes.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an AI Supply Chain Review or write to us at consult@cloudnala.co.za