Provide a representative product
Submit a representative source code package or firmware image.
Schedule an Assessment
Identify open-source components, license risks and vulnerabilities hidden across your product software. Our specialists analyze a representative source code package or firmware image to give you a practical first view of your compliance exposure.
What you’ll receive from us:
- Preliminary SBOM
- License and copyleft risk analysis
- Vulnerability review
- Clear view of potential compliance gaps
Start with one product
You don’t need to assess your entire portfolio at once. Start with a representative product and gain an initial view of what is actually inside its software.
1
We analyze the software
Our specialists identify open-source components and assess potential license, copyleft and vulnerability risks.
2
Receive your initial assessment
We review the findings with your team, explain the most relevant risks and help you understand where further action may be needed.
Gain a practical view of your current compliance exposure and clear recommendations for the next steps.
3
Why open source becomes a product risk
Open-source compliance in a product business goes beyond knowing which packages developers intended to use.
| Facts & Figures | What it means |
|---|---|
| 70 to 90 percent | Typical share of an embedded codebase made up of open source and third-party code, most of it never formally cleared. |
| Snippet level |
Copied functions, AI generated code, vendor SDK drops and forked drivers carry license obligations that a package-manager view never sees. |
| 10 to 20 years | Service life of an industrial asset, long after the upstream community stopped patching the library inside it. |
| December 2027 | Full CRA obligations apply to products with digital elements placed on the EU market, so design decisions taken today are already in scope. |
Why manufacturing is different
When software is distributed as part of a physical product, open-source license obligations need to be understood and addressed before shipment.
-
Embedded code is copied, not just imported
Reference drivers, vendor SDK samples, forked upstream files, and AI generated code are pasted straight into the firmware tree. There is no manifest entry, no package manager record and no declaration, yet the license obligations travel with the code all the same. Only snippet-level source code scanning brings that code back into view.
-
Distribution triggers copyleft
Unlike a hosted backend, a machine is distributed. GPL, LGPL and AGPL obligations become concrete: complete corresponding source, a written offer, installation information and license texts in the manual. Discovered at shipment rather than at design time, a single copyleft finding is enough to stop a launch.
-
You cannot simply upgrade the library
A CVE in a crypto or protocol stack inside a certified safety controller means re-validation, re-qualification and possibly re-certification. What engineering needs is a prioritized, context-assessed short list with a documented justification for everything excluded, not a four-thousand-line raw vulnerability dump.
-
Your product outlives its dependencies
A line commissioned today will still be running in 2040. Kernel branches reach end of life; packages are abandoned, and maintainers disappear long before the asset is decommissioned. Someone must own that obsolescence risk for the entire installed base, and increasingly the regulator expects it to be the manufacturer.
-
OT constraints block the usual fixes
Air-gapped cells, hard real-time loops, no agents permitted on the controller and change windows that open once a quarter. Compliance evidence has to be produced from development artefacts, without touching a running line.
-
Customers now audit you
OEM procurement, defense and automotive customers request SBOMs, license documentation and CRA conformity evidence in the request for quotation itself. No SBOM increasingly means no bid, which makes compliance a sales qualifier rather than a back-office exercise.
The Cyber Resilience Act is a product-engineering deadline
Products designed this year will still be on the market when full obligations apply. Anything with a digital element placed on the EU market falls in scope, including machines, controllers, gateways, and the software updates delivered to them.
Reporting obligations apply
Manufacturers are required to report actively exploited vulnerabilities and severe security incidents affecting products with digital elements. An early warning is generally required within 24 hours of becoming aware of the issue
2026
Main CRA obligations apply
The main Cyber Resilience Act obligations apply from 11 December 2027, including requirements related to cybersecurity, vulnerability handling and technical documentation.
2027
Compliance must be maintained
Manufacturers need appropriate processes and evidence covering software components, vulnerabilities, security updates, documentation and product support.
Now
What compliance requires from you
Each requirement needs to be translated into concrete product, engineering and organizational processes.
| Obligation | What it means in practice |
|---|---|
| Component inventory | A maintained SBOM per release, covering at least top-level dependencies, retrievable years later. |
| Vulnerability handling | Monitoring, triage, remediation, and documented coordinated disclosure policy. |
| Secure updates | Signed, verifiable and deliverable updates, including devices sitting behind an OT firewall. |
| Documentation | Risk assessment, test evidence, declaration of conformity, and the conformity file, retained for ten years. |
| Transparency | The support period communicated to customers, and end of support handled deliberately rather than by silence. |
Our service catalogue:
Whether you need to understand a single product or establish compliance across a wider portfolio, we support the open-source compliance lifecycle.
-
1.
CRA readiness and conformity evidence
A gap assessment against the essential requirements of the Cyber Resilience Act, translated into engineering work packages rather than legal prose.
- Policies, processes and tools
- Actionable roadmap to compliance
-
2.
SBOM creation for firmware & embedded products
We create a component-accurate SBOM per device, variant and firmware release from source, or directly from the binary image when no source exists.
- Full-file and snippet matching against our comprehensive open-source knowledge base
- SPDX and CycloneDX output, ready for customer portals
- Per-variant SBOMs mapped to part numbers and release trains
-
3.
Vulnerability monitoring and risk assessment
Continuous CVE matching against your SBOM inventory, filtered down to what is genuinely relevant in your device configuration, with a written justification behind every exclusion.
- Documented assessment and technical details per finding
- Severity scoring
- Individual risk assessment
-
4.
License clearance and copyleft strategy
Every component classified and every obligation resolved before the device ships, rather than during a customer audit or in response to an enforcement letter.
- Copyleft exposure map covering GPL, LGPL, AGPL, MPL and EPL boundaries
- Static versus dynamic linking analysis across the source tree
- Written offer, attribution and license notice packages
- Complete corresponding source bundles per release
-
5.
Supplier and tier-n SBOM governance
Compliance is only as strong as your weakest supplier. We operate SBOM requirements across contracts, supplier onboarding, and incoming inspection.
- SBOM clauses for purchasing terms and development agreements
- Incoming SBOM quality gates and automated validation
- Verification scans of delivered source drops and SDKs against the declared SBOM
-
6.
Compliance as a managed service
Compliance is not a project that ends. We run the tooling, the triage and the evidence pipeline for your installed base so that your engineers stay on product development.
- Scanning support and customer SBOM request handling
- Quarterly obsolescence and end-of-life component reviews
- Audit-ready evidence archives per product and per release
Why manufacturers choose us?
A software manifest shows the components that were intentionally included in a product. However, it may not capture copied code, modified upstream files, SDK samples, or other open-source elements added during development.
Our analysis goes beyond declared packages by examining the source code itself. This helps identify open-source components, snippets and dependencies that may not appear in a manifest, providing a more complete picture of the software contained in your product.
Request Your Free Compliance Assessment
-
Use our Open Source Compliance Checklist for Industrial Products to review your current processes and identify potential gaps. 324.93 KB Download
Frequently Asked Questions
-
Does the Cyber Resilience Act require an SBOM?
The Cyber Resilience Act requires manufacturers to maintain information about software components and vulnerabilities as part of their compliance and security processes.
-
How can manufacturers identify open source software in firmware?
Manufacturers can identify open source software through source-code analysis, binary scanning, firmware analysis, and snippet-level detection techniques that uncover embedded open-source components.
-
What is Software Composition Analysis (SCA)?
Software Composition Analysis (SCA) helps organizations identify open source components, track vulnerabilities, and monitor license obligations within software products.
-
How do you handle confidential source code and firmware?
We understand that source code and firmware are among your organization's most valuable assets. All submitted materials are handled confidentially and used solely for the agreed assessment scope.
Depending on your requirements, we can support secure transfer methods and controlled access procedures. Our specialists regularly work with sensitive industrial software, embedded systems and firmware environments where confidentiality and security are critical.