One contract for
all of your open source.
ALVPHA Upstream is your external Open Source Program Office: we take on transparency, security, lifecycle and all communication with the open-source projects inside your products — permanently. You keep one point of contact, and commitments you can hold us to.
Reporting obligations under Art. 14 CRA apply from September 11, 2026; full manufacturer obligations from December 11, 2027. Anyone selling products with digital elements in the EU must know, monitor — and prove — what open source is inside them.
Software with no one to call.
Modern products are largely built from community open source — components with no contract, no hotline, no owner. As long as everything works, nobody notices. It becomes visible when:
- —a vulnerability is published and nobody knows whether and where you are affected,
- —a defect appears and it is unclear: component, configuration, or your own code,
- —a component quietly reaches end of life because its maintainer moved on,
- —an auditor or customer asks for evidence that does not exist.
Most organisations simply have no role for any of this. ALVPHA Upstream is that role — external, contractual, permanent.
Every component its own channel: unclear ownership, lost knowledge, no evidence.
One contract, one point of contact: defined processes, public traces, audit-grade evidence.
The CRA clock is ticking.
The Cyber Resilience Act is in force — its transition periods end in stages. Start today and the effort spreads across two years. Wait, and you remediate under deadline pressure.
CRA in force
Regulation (EU) 2024/2847 entered into force. The transition periods have been running since.
Reporting obligations
Actively exploited vulnerabilities and severe incidents must be reported to CSIRT and ENISA within 24 hours (Art. 14).
Full obligations
All manufacturer obligations apply: risk assessment, SBOM, vulnerability handling and security updates across the support period.
Three layers, one responsibility.
Transparency & evidence
Component inventory, licence classification, SBOM, continuous monitoring of vulnerabilities, end-of-life and maintainer activity. Audit-grade reporting — ready for CRA and NIS2 evidence.
Support desk
One ticket with us — never with a thousand projects. We reproduce, triage, research issues, releases and workarounds, and own the status through to resolution.
Upstream delivery
We file issues by each project’s rules, report security findings exclusively through private channels, develop patches, and see the pull request through merge and release — then integration-test on your side.
Verifiable means: publicly countable.
Our work leaves public traces in the projects themselves. Those traces are exactly what we publish as a running upstream track record:
The upstream track record goes live with our first client projects — every number will be publicly verifiable, directly in the projects’ repositories.
We sell our process — not other people’s work.
- ✓Critical intake acknowledged ≤ 30 minutes
- ✓Triage ≤ 2 hours, reproduction analysis ≤ 4 hours
- ✓Upstream escalation within a defined window
- ✓Daily status updates on critical cases
- ✓Integration testing as soon as a fix is available
- ✕Community reaction or fix times
- ✕Project release dates
- ✕That a pull request will be accepted
Where we patch ourselves, we go further: our own maintained fix with a real remediation commitment — until the upstream merge makes it obsolete. We deliberately give no guarantees on volunteer work we don’t control; that is what separates a serious offer from an empty promise.
CRA Readiness Assessment.
Step one is an inventory with a clear outcome: a complete open-source inventory of your products, SBOM generation, a gap analysis against CRA requirements — using the German BSI Technical Guideline TR-03183 as the benchmark — and a prioritised action plan.
Fixed price after a short scoping call. The assessment leads directly into ongoing operations with ALVPHA Upstream.
Note on medical devices: medical devices are not governed by the CRA (they fall under MDR/IVDR). We offer a separate, MDR-anchored assessment — talk to us.
In short.
01What is an external Open Source Program Office (OSPO)?
An OSPO is the function that governs how a company deals with open source: inventory, licences, security, contact with the projects. Large corporations run dedicated teams for this. ALVPHA Upstream provides exactly that function as an external, contractually defined service — without you having to hire specialists.
02Who is ALVPHA Upstream for?
Manufacturers of products with digital elements — machinery and plant engineering, industrial electronics, IoT and embedded — that must comply with the EU Cyber Resilience Act and do not want to build an OSPO of their own. Product responsibility stays with you; we supply transparency, operations and evidence.
03Does ALVPHA Upstream replace our developers?
No. Your teams keep building your product. We take on the part that rarely has an internal owner: permanent responsibility for the open-source components underneath — from vulnerability monitoring to the merged patch in the upstream project.
04What does this have to do with the Cyber Resilience Act?
The CRA obliges manufacturers to know the components inside their products, handle vulnerabilities, and — from 11 September 2026 — report actively exploited vulnerabilities within 24 hours. That requires exactly the capabilities ALVPHA Upstream delivers as a service: inventory, SBOM, monitoring and a dependable handling process.
05Do you guarantee open-source projects?
No — deliberately. We guarantee our own process: response times, triage, escalation, our own patches. We make no commitments on volunteer work in projects we don’t control; that is what separates a serious offer from an empty promise.
06How do we start?
With the CRA Readiness Assessment: inventory, SBOM, gap analysis against the CRA requirements (benchmark: BSI TR-03183) and a prioritised action plan — at a fixed price after a short scoping call. From there, a direct path into ongoing operations.
01ALVPHA Upstream is an independent service provider. We are not the official support of the open-source projects we work with, and we never present ourselves as such.
02We make technical determinations on licences and obligations. We do not provide legal advice on individual cases — for that we work with specialised law firms.
03We report security vulnerabilities exclusively and responsibly through each project’s security process — never in public.
Let’s talk about your open-source portfolio.
Briefly describe your situation — product environment, stack, CRA status. We reply within two working days.