I’ve had this conversation a number of times recently with companies building connected devices.
At some point, it almost always comes up: “Can’t we just build this ourselves using open source?”
Technically, yes.
But if you’re responsible for cybersecurity, that’s not the real question.
The real question is: what are you taking ownership of when you decide to build?
The €200K starting point
One team I spoke with estimated roughly €200K to build an internal solution.
That number wasn’t surprising. What was more interesting is that they couldn’t point to a single open source solution that covered their needs.
They were planning to combine several tools to get there.
Which is usually how this starts.
You’re not building a tool, you’re building a system
In practice, this usually means:
- one solution for SBOM generation
- another for SCA
- separate vulnerability data sources
- custom scripts to connect everything
- something internal for reporting and workflows
Each component works on its own.
But the system as a whole? That’s something you now have to design, build, and maintain.
What cybersecurity teams should push back on
When this decision is discussed at management level, it often gets framed as: “Build once vs buy annually.”
That framing is incomplete.
If you’re in a security role, these are the points that matter:
1. You are taking on long-term ownership
This is not a one-time project.
You are committing to:
- maintaining integrations
- validating data accuracy
- adapting to new vulnerabilities and sources
- supporting audits and reporting
2. There is no single source of truth
With multiple tools:
- data lives in different places
- logic is fragmented
- consistency becomes a challenge
This increases operational risk, not reduces it.
3. You are responsible for proving compliance
With regulations like the Cyber Resilience Act, expectations are clear:
- traceability (HBOM + SBOM)
- continuous monitoring
- documented processes
- auditability
If something doesn’t hold up, the responsibility sits internally.
4. You are redirecting critical engineering capacity
This is the part that is often underestimated.
The engineers building this system are the same people who should be building your product.
So the real impact is:
- delayed features
- slower releases
- reduced innovation capacity
That trade-off is rarely visible in budgets, but it directly affects the business.
What this decision actually is
This is not a tooling decision.
It’s a strategic ownership decision.
You are choosing between:
- owning and maintaining a complex internal system
- relying on a platform that is designed to handle that complexity
A simple way to frame it internally
If you need to explain this upwards, a useful way to position it is:
“We can build something that works, but we will also take on full responsibility for keeping it working, keeping it compliant, and proving that over time.”
That usually changes the conversation.
Final thought
Building your own solution is not wrong.
But it comes with a level of ownership that is often underestimated at the start.
And once that ownership is internal, it doesn’t go away.