// For software vendors and device makers
For software vendors: keep the open source inside your product patched
Software vendors that embed open source, such as a ZooKeeper ensemble, a Kafka broker, an Elasticsearch node or a PostgreSQL server inside a shipped product, can get patched, signed builds of the exact version they ship from OSSeva, with an SBOM and a VEX statement per CVE that their customers' security teams can read. The vendor is the one customers' scanners blame, and under the EU Cyber Resilience Act the manufacturer of a product with digital elements has to handle vulnerabilities in its components, open source ones included, for the support period. OSSeva supplies the builds and the evidence; it does not make a product conform to the Act. Enter your work email and the component and version you embed, and an engineer replies within 1 business day.
- For
- Software vendors and device makers that ship open source inside a product customers install or run
- What you get
- Signed, patched builds of the version you embed, applied to upstream source with no fork, so configuration and data format stay the same
- Evidence for your customers
- SBOM (CycloneDX or SPDX), VEX statements (OpenVEX or CSAF) and a CVE record per release, with Assure
- Patch window
- Critical CVEs (CVSS 9.0 or higher) within 48 hours, High within 7 days
- Tiers
- Patch: signed builds. Assure adds 24/7 reactive support and the audit evidence. Operate adds a 15-minute P1 response.
- Cyber Resilience Act
- Component facts for your own vulnerability handling and Article 14 reporting. OSSeva makes no conformity claim.
Cyber Resilience Act text checked on 20 October 2026 against the Official Journal version of Regulation (EU) 2024/2847 on EUR-Lex (Articles 3, 13, 14, 24, 69 and 71, Annexes I, II and VII). Scanner behaviour checked on the same date against the Trivy Java documentation and the OpenVEX specification. Next review 18 January 2027.
Trusted globally by enterprises
What we patch: the components vendors embed most
Find the row that matches what you ship. Each link goes to the page with that component's version matrix, end-of-life dates and the advisories published since the line ended. If the version you embed is not on those pages, say so in the form; an engineer will tell you whether it can be covered.
| Embedded component | How it usually ships inside a product | What OSSeva patches |
|---|---|---|
| Apache ZooKeeper | A server or client jar bundled in the product, often through Apache Curator, or the coordination layer your cluster mode needs | Patched builds of 3.4, 3.6 and 3.7; 3.5 as custom support scoped per engagement |
| Apache Kafka | Brokers or client libraries inside a streaming or data product, often still on ZooKeeper | Kafka 2.8 to 3.9 brokers, Connect and clients, and the ZooKeeper ensemble behind them |
| Elasticsearch | A search node in a customer-installed product, often pinned to 7.10.2 | Elasticsearch 7.17 and 7.10.2 as drop-in packages and images |
| RabbitMQ | A broker for asynchronous messaging in an installable product | Patched 3.x builds and the Erlang/OTP runtime under them |
| Redis | A cache or queue in an appliance or an on-premises release | Redis 6.2 and 7.0 as signed packages and images |
| PostgreSQL | The metadata or application database inside a product | Major versions past community end of life |
| Bitnami-based images | Helm chart dependencies pinned to bitnamilegacy tags | Bitnami-compatible drop-in images, signed, for the lines above and more |
Coverage is as stated on each linked page and on the supported versions list, which is the authority if the two ever differ.
ZooKeeper extended support →Kafka on ZooKeeper →Elasticsearch 7.17 and 7.10.2 →RabbitMQ 3.x →Redis 6.2 and 7.0 →PostgreSQL after end of life →Bitnami drop-in images →Supported versions →
One advisory, as your customer's scanner sees it
Your customer scans the installed product, finds the ZooKeeper jar inside it and reads off every advisory whose affected range covers that version. The example below is the one the Apache project fixed in 3.7.2, 3.8.3 and 3.9.1 and not on the lines that had already ended. The scanner reports it against your product whether or not your configuration ever enables the feature at issue. The answer is a statement from the party that knows the configuration, not a reassurance in an email.
| CVE | Published | CVSS | Affected range (NVD) | Fixed upstream in |
|---|---|---|---|---|
| CVE-2023-44981 | 2023-10-11 | 9.1 | <3.7.2; >=3.8.0 <3.8.3; 3.9.0 | See advisory |
Which VEX status applies depends on the build and the configuration: fixed where the build you ship carries the backport, not_affected with a stated justification where the vulnerable code cannot be reached in your product. A VEX statement names a product, so OSSeva's statements name the patched component build, and the statement for your product is yours to issue with the component statement behind it.
Why your scanner flags the ZooKeeper inside a product, and what a credible VEX statement contains →
The embedded-component problem: you picked the version, your customers inherit the finding
A component that ends inside your product creates four problems, and the first one reaches you before the others.
The ticket lands on you, not on the project
Your customer's scanner reads the jar, package or image inside your installed product and raises the finding against your product. Their security team cannot patch it without you, so every scan cycle sends you the same ticket until you can show what was fixed.
Upstream stops fixing the line you ship
ZooKeeper 3.5 ended on 1 June 2022 and 3.7 on 2 February 2024. A product that shipped either one has been carrying advisories with no upstream fix since, and the next advisory usually names only the supported lines, so the ended ones are never assessed.
Moving the component means a new product release
Clients, Curator versions, configuration and data formats are tied to the component line. Upgrading means releasing, testing and getting customers to install a new version of your product for every release you still support, which is why the component outlives the plan to replace it.
Your support period can outlast a component
The Cyber Resilience Act asks a manufacturer to set a support period of at least five years, or the expected use time if shorter, and lets it take into account the support periods of integrated third-party components that provide core functions. A component whose upstream support ends inside your product's support period is a gap you have to fill by upgrading, replacing or buying continued patching.
The dates that matter
1 Jun 2022
ZooKeeper 3.5 reaches end of life. A product that embeds it is already past upstream fixes before the Cyber Resilience Act applies.
2 Feb 2024
ZooKeeper 3.7 reaches end of life, per the Apache project's releases page.
11 Jun 2026
Cyber Resilience Act Chapter IV (conformity assessment bodies) applies.
11 Sep 2026
Article 14 applies: a manufacturer notifies actively exploited vulnerabilities, with an early warning within 24 hours. Article 69(3) extends it to in-scope products already on the market.
11 Dec 2027
The rest of the Act applies, including the vulnerability handling requirements in Annex I Part II and the SBOM in the technical documentation. Under Article 69(2), a product placed on the market before this date is covered only if it undergoes a substantial modification, except for Article 14.
What a software vendor gets from OSSeva
Patched builds of the version you ship
Fixes applied to upstream source for the line you embed, signed with GPG (packages and Maven artifacts) and cosign (container images), with SHA-256 checksums. No fork, and configuration and data format unchanged. Critical CVEs are patched within 48 hours and High within 7 days.
SBOM and VEX your customers can read
An SBOM for the build in CycloneDX or SPDX, VEX statements that say which advisories are fixed or do not apply, and a CVE record per release with the delivery date and build identifier. This is the Assure evidence pack, delivered so you can pass it to the customers who ask.
Component facts for your own file
For each advisory: the CVE id, the affected range, the build that fixes it and the VEX status. That is what you need to decide quickly whether an actively exploited vulnerability touches your product, and what to put in your vulnerability handling record. Filing the notification stays with you.
Support behind it when a customer escalates
Assure includes 24/7 reactive support, so a customer's escalation about the embedded component reaches an engineer who knows the build. Operate adds a 15-minute P1 response when you also want the component run for you.
How scanners find the component inside your product, and what answers each
A scanner does not test whether a vulnerability is exploitable. It matches what it can read from your product against an advisory range. How it reads the component decides what the finding looks like and which document closes it, so it is worth knowing which route your largest customers' scanners take.
The Java rows follow Trivy's documentation, checked on 20 October 2026; other scanners differ in detail, so ask which one your biggest customers run.
How a scanner identifies an embedded component, what goes wrong on a patched build, and the document that answers it
| How it is found | What the scanner reads | What goes wrong on a patched build | What answers it |
|---|---|---|---|
| Jar metadata | pom.properties and MANIFEST.MF inside the jar: group, artifact and version | A backported build keeps the upstream version string, so every upstream advisory whose range covers it matches. | A VEX statement with status fixed for that CVE and build, and a CVE record naming the build identifier. |
| Java database lookup | If the metadata is missing or incomplete, the scanner looks the jar up in its database of published artifacts (Trivy marks this experimental) | A patched jar is not a published artifact, so the lookup matches nothing and the scanner reports an unrecognised component or silence. | An SBOM entry that records the patched jar as its own component, with its own version string and supplier. |
| Nested and shaded jars | Inner jars inside your product's jar, identified with the same logic as the outer one; Trivy's table output shows only the outer jar's name | The finding carries the name of your jar, not ZooKeeper's, so the customer opens it against your product and cannot tell which component it is. | VEX statements that list the component as a subcomponent of your product (OpenVEX supports this), with your SBOM naming the same identifier. |
| Packages and image layers | The package database or language manifests in the appliance, virtual machine or container image | The package version is the matching key, so a patched package with an unchanged version still matches the advisory range. | A signed package or image, its checksum and the VEX statement, so the customer can verify they have the fixed build. |
| Network scan | The version the running service reports on its port | The reported version is the upstream number, whatever was backported underneath. | The CVE record with the build identifier, plus the VEX statement, attached to the finding. |
| Your own SBOM | The package URLs or CPEs you publish for the product | If your SBOM lists the upstream identifier for a patched component, consumers match upstream advisories against it. | List the patched component as a distinct entry and use the same identifier in every VEX statement. |
OSSeva's statements and SBOMs describe the patched component build. Whether a statement can also carry your product identifier is confirmed on the discovery call.
The Cyber Resilience Act and open source you embed: what the manufacturer owes
If you make a product with digital elements available on the EU market under your own name, in the course of a commercial activity, you are its manufacturer, and Regulation (EU) 2024/2847 puts the open source inside it on your account. Article 13(5) requires due diligence when integrating third-party components, including free and open-source ones that were never sold. Article 13(6) requires you to report a vulnerability you identify in a component to whoever maintains it and to remediate it. Article 13(8) requires you to handle vulnerabilities in the product, components included, for the support period.
Two details matter to a vendor. First, the SBOM is a manufacturer duty, but it sits in the technical documentation and goes to a market surveillance authority on a reasoned request (Annex VII, point 8); whether to give users an SBOM is your decision (Annex II, point 9). A customer's auditor asking for one is a contract and audit question, not a Cyber Resilience Act one. Second, a vendor that publishes and maintains open source itself may be an open-source steward under Article 24 rather than a manufacturer, which carries a different and lighter set of duties. Whether either applies to you is a question for your counsel.
Regulation (EU) 2024/2847: the provisions that reach an embedded open source component, and who does what
| Provision | What it asks of the manufacturer | What OSSeva supplies | What stays with you |
|---|---|---|---|
| Article 13(5) and 13(6) | Due diligence on third-party components, including open source; report a vulnerability found in a component to its maintainer and remediate it, sharing any fix where appropriate | A source-built, signed build and the CVE record of what it fixes | Choosing the component and version, the due diligence record and the report to the maintainer |
| Article 13(8) and 13(9) | A support period of at least five years, or the expected use time if shorter, and security updates kept available for at least 10 years or the rest of the support period, whichever is longer | Patched builds of a covered line for as long as it is on a contract | Setting the support period, shipping the update and keeping it available |
| Annex I Part II, points 1 and 2 | Document vulnerabilities and components, including an SBOM in a commonly used, machine-readable format covering at the very least the top-level dependencies; remediate without delay with security updates | An SBOM of the component build in CycloneDX or SPDX, and signed security updates | The SBOM for your product and the decision on what to remediate first |
| Annex I Part II, points 4 and 8 | After an update is available, publicly disclose fixed vulnerabilities; disseminate updates without delay and, unless agreed otherwise for a tailor-made product, free of charge | CVE id, severity, affected range and the fixing build for each advisory | The public advisory text and delivery of the update to users |
| Article 14, applies since 11 September 2026 | Notify an actively exploited vulnerability: early warning within 24 hours, a notification within 72 hours, a final report within 14 days after a corrective or mitigating measure is available | The facts the notification needs for an embedded component: affected range, fixing build and VEX status | The notification itself, through the single reporting platform. OSSeva does not file for you. |
Wording is paraphrased from the Official Journal text of Regulation (EU) 2024/2847, checked on 20 October 2026. The full rule-to-evidence map, including PCI DSS, DORA and CMMC, is on the audit evidence page and is not repeated here.
What to hand your customer's security team
Most of the questions arrive in the same order. This is the evidence for each, and who produces it.
| The customer asks | You hand over | Where it comes from |
|---|---|---|
| Which open source is in this product? | The product SBOM, with the patched component listed as its own entry | Your SBOM; the component SBOM comes from OSSeva with Assure |
| Why does my scanner say this component is vulnerable? | A VEX statement per CVE: fixed, or not_affected with a justification | OSSeva's statement for the component build; the product-level statement is yours |
| Is the build you shipped the patched one? | The signature and checksum, and the steps to verify them | OSSeva's signing keys and verification steps on the security page |
| Who patches it, and how fast? | The patch window and the support behind it | Critical CVEs within 48 hours, High within 7 days; Assure 24/7 reactive support |
| What happens when upstream support ends? | The end-of-life date, your support period and your plan | Yours, with the end-of-life dates on the version pages as an input |
Who this is not for, and what OSSeva does not claim
If the version you embed is still supported upstream, upgrade it; OSSeva will say so on the call. If your product only runs the component inside a service you host and ships nothing to customers, the scanner finding rarely reaches you, and the case for extended support is weaker. If the component is not on the supported versions list, an engineer will tell you whether it can be added.
OSSeva does not certify that a product conforms to the Cyber Resilience Act, does not act as an assessor or notified body, does not file reports for you, does not set your support period and does not decide whether the Act applies to you. The evidence is OSSeva's record of what it patched, when, and in which build; your counsel and your assessor decide what it proves. This page is not legal advice.
What to bring to the 15-minute discovery call
The call settles scope, and these are the facts that decide it: the component and exact version you embed, how it ships (jar, package, image or appliance), how many product releases still pin it, which scanner your biggest customers use, and the support period you have set for the product. An engineer then tells you which of the three tiers fits and what the evidence pack would contain for your build.
Sources, checked 20 October 2026
The Cyber Resilience Act provisions above come from the primary text. Scanner behaviour comes from the scanner's own documentation.
How do you handle an embedded open source component whose upstream support has ended?
| Option | What you get | Trade-off |
|---|---|---|
| Upgrade the component in your product | Upstream fixes and upstream advisories: the cleanest answer for every customer. | A new release of your product for every version you still support, and customers have to install it. Until it lands, the old release still carries the finding. |
| Replace the component | A supported alternative, such as KRaft, ClickHouse Keeper or etcd in place of ZooKeeper where your product allows it. | Product work, and only where the replacement speaks the protocol your product needs. |
| Assess every CVE yourself | Full control of each VEX statement. | Each statement needs an engineer to prove the fix or show the code is unreachable, and an auditor can reject a vendor's own self-assessment. |
| Maintain your own backports | A build exactly as you want it. | Your engineers carry every advisory on a line the project has stopped looking at, and the evidence file is yours to write. |
| Another extended-support provider | Patches for the line from that provider. | The evidence is whatever that provider publishes. Ask for an SBOM, VEX statements and signed builds before you rely on it. |
| OSSeva patched builds with the evidence pack | Signed patched builds of the version you embed, an SBOM, VEX statements and CVE records, with Critical CVEs patched within 48 hours and High within 7 days. | Covers the lines on the supported versions list. You still ship the update, own the product SBOM and your support period, and plan the upgrade. |
Cyber Resilience Act provisions and dates checked on 20 October 2026 against the Official Journal text; scanner behaviour against Trivy and OpenVEX documentation on the same date. See the sources list above. This page is not legal advice.
Our product embeds ZooKeeper 3.5: who patches it?
The Apache project stopped fixing 3.5 on 1 June 2022, so nobody upstream does. OSSeva supports 3.5 as custom support, scoped per engagement, and ships standard patched builds for 3.4, 3.6 and 3.7. Either way you remain the party that ships the update to your customers: OSSeva supplies the signed build, the CVE record and the VEX statements, and you put the build into your next release or hotfix.
What SBOM and VEX will our customers' auditors accept?
No supplier can promise what an auditor accepts, because the assessor decides. What you can give them is evidence they can read: an SBOM in CycloneDX or SPDX that you check against CISA's 2026 minimum elements, and VEX statements with one of the four statuses and, for not_affected, a justification. The audit evidence page lists what each rule asks for.
Does the Cyber Resilience Act apply to the open source we embed?
If you make a product with digital elements available on the EU market in the course of a commercial activity, you are the manufacturer and you answer for its components: due diligence under Article 13(5), reporting a component vulnerability to its maintainer under Article 13(6), and handling vulnerabilities for the support period under Article 13(8). Article 14 reporting has applied since 11 September 2026, including to products already on the market; the rest applies from 11 December 2027. Ask your counsel whether you are in scope. OSSeva makes no conformity claim.
Does OSSeva make our product Cyber Resilience Act compliant?
No. OSSeva supplies patched builds and the evidence of what was patched, when and in which build. The product SBOM, your support period, the technical documentation, any conformity assessment and the Article 14 notifications stay with you.
Can we ship OSSeva's patched builds to our customers inside our product?
The builds are made from the component's upstream source, with configuration and data format unchanged, so they replace the jar, package or image in your next release. The terms for shipping them inside your product, and how the per-cluster pricing model applies when the component runs at your customers' sites, are settled on the discovery call and confirmed in writing before you rely on them.
We make appliances and devices. Is that covered?
OSSeva's builds are packages, Maven artifacts and container images of server software such as ZooKeeper, Kafka, Elasticsearch and PostgreSQL. An appliance or device that runs one of those lines on a server-class operating system fits; firmware for constrained hardware does not. For medical devices, the post on the FDA and end-of-life components covers what a premarket submission has to show.
How is OSSeva priced for an embedded component?
OSSeva prices per cluster or ensemble, not per node, and keeps prices off this site. Book the 15-minute discovery call, say where the component runs and how many product releases pin it, and you get a quote.
Get a quote
Tell us the component and version you embed.
A 15-minute discovery call, the versions in scope, and a sample evidence pack on request.
Prefer to talk or read more first?