OSCAR_in_action

TrustSource adds EoL data

YOUR SOFTWARE PORTFOLIO IS QUIETLY AGING — AND BECOMING A SECURITY LIABILITY

Imagine this: an attacker discovers a critical vulnerability in a component your software relies on. The vendor knows about it too. But they’re no longer issuing patches — because the product has officially reached End of Life. No fix. No update. No support. Just an open wound that grows more dangerous with every passing day.

This isn’t a hypothetical. It happens every day, in organizations that simply don’t know which of their components have already been discontinued.

WHAT “END OF LIFE” ACTUALLY MEANS

End of Life (EoL) marks the point at which a software product or component is no longer maintained by its vendor. No security updates. No bug fixes. No support. Organizations running EoL software are, in effect, operating with a permanently unguarded entry point — entirely legal, but deeply hazardous.

This has three types of implications:

  1. Security: Known vulnerabilities remain permanently unpatched. Every new CVE disclosure can become an existential threat — with no remediation path available from the vendor.
  2. Operations: EoL components lose compatibility with evolving systems, libraries, and interfaces. What works today can silently break tomorrow, disrupting critical business processes.
  3. Compliance: Regulatory frameworks including GDPR, HIPAA, and PCI-DSS require organizations to maintain reasonable security standards. Running EoL software can directly undermine compliance — with serious liability exposure in the event of a breach.

THE CYBER RESILIENCE ACT CHANGES EVERYTHING

The EU’s Cyber Resilience Act (CRA), which entered into force in 2024 with obligations phasing in through 2027, elevates EoL from a vendor business decision to a regulated commitment.

Under the CRA, manufacturers of digital products must:

  • Disclose support periods — clearly, before purchase
  • Provide a minimum of five years of security support (or the expected product lifespan)
  • Deliver security updates free of charge throughout the support period
  • Communicate EoL in advance, with adequate notice and migration guidance

This is a genuine paradigm shift. EoL is no longer a discretionary product decision – it is a legally binding obligation with regulatory consequences. Manufacturers declaring unreasonably short support windows will need to justify this to market surveillance authorities.

For CISOs and C-suite leaders, the implications are direct: operating EoL software must be actively managed – and documented – as part of broader CRA compliance.

Do you want to learn more about the impact the CRA will have on your software development? Profit from applying our free CRA assessment!

HOW MACHINES GET TO KNOW THE END OF LIFE DATE

Modern IT environments comprise thousands of software components. Manual tracking can’t be the strategy anymore. This is why two machine-readable standards for lifecycle information are emerging:

  • EoX (OASIS/Cisco): A structured data model defining discrete lifecycle milestones — from End of Sale through End of Security Support to End of Service Life. Automated asset management systems consume this data and can surface risks proactively before they become incidents.
  • CycloneDX (OWASP): A leading standard for Software Bills of Materials (SBOMs) supports structured lifecycle and EoL metadata. When a library maintainer declares EoL in their published SBOM, downstream consumers — application developers, integrators, and end users — automatically inherit that information through the supply chain.

The result: EoL management becomes scalable — shifting from manual research to continuous, automated monitoring across the entire software supply chain.

IDENTIFY THE SILENT RISK IN YOUR PORTFOLIO

EoL doesn’t just affect operating systems – it applies equally to open-source libraries, frameworks, middleware, container images, and commercial components. In a typical enterprise portfolio, far more EoL components are running than most IT teams realize.

The questions every leadership team should be asking:

  • Which components in our portfolio have already reached EoL?
  • Which will reach EoL in the next 6–12 months?
  • Do we have processes that warn us in time – so that we have enough time to react?

OSCAR_in_action

TRUSTSOURCE: EOL MANAGEMENT THAT DOESN’T SLEEP

TrustSource has built EoL monitoring into the core of its software supply chain security platform — not as an afterthought, but as an operational capability.

The platform aggregates EoL data from multiple upstream sources and manual collection, covering both components and distributions, and surfaces this information directly within the context of each project. In practice, this means:

  1. Policy-driven alerts: Every project in TrustSource can define its own thresholds — for example, a warning 9 months before EoL and a policy violation 2 months before EoL. The right people are notified while there is still time to act.
  2. Portfolio-level reporting for leadership: CISOs and central security officers can screen the entire portfolio — or individual projects — for EoL exposure in a single report. Comprehensive visibility at a glance, ready for compliance evidence and executive decision-making.
  3. Downstream API: TrustSource closes the loop across the value chain. Through an integrated API, customers and internal applications can programmatically retrieve current EoL data at any time — ensuring that lifecycle intelligence flows not just into your organization, but through it.

THE BOTTOM LINE: EOL IS NOW A BOARD-LEVEL ISSUE

The Cyber Resilience Act makes EoL a matter of executive accountability. Machine-readable standards make it manageable at scale. And platforms like TrustSource make it operational – automated, continuous, and auditable.

The question is no longer whether EoL risks are lurking in your portfolio. The question is: will you find out in time – or too late?

Do you want to know, how you may feed EOL data into your processes?


wp-tease-img

Securing the foundations

Is Your C/C++ Supply Chain Still a “Wild West”?

While modern ecosystems like Rust or Go enjoy streamlined package management, the C/C++ landscape – the bedrock of embedded systems – remains strewn with “ghost dependencies” and hidden risks. In an area where software persists in the field for decades, “you can only patch what you know”.

Our most recent whitepaper, “Securing the Foundation,” dives deep into why traditional SCA tools often fail in the embedded world and how to achieve true visibility. In the paper we discuss, why it requires attention:

  • The Dependency Paradox: Fragmented build systems and manual “vendoring” create blind spots in your inventory.
  • Compliance & Licensing: Static linking and copyleft components (like GPL drivers) can create complex legal requirements for proprietary code.
  • Export Control: Identifying cryptographic algorithms is no longer optional for cross-border shipping.
  • Quantum Readiness: With quantum computing on the horizon, maintaining an accurate inventory of cryptographic algorithms is a critical foundation for future safety.

Further-on  we suggest  Bimodal Scanning as a solution approach to overcome the shortcomings. We challenge the suggested approach and guide the reader through a demonstration in a use case on the well known e Intel® RealSense™ Library, using our open source tooling.

Ready to bring transparency to your software supply chain without much friction?

Download the Whitepaper here (check the box on the lower right side) or reach out to the TrustSource team for a technical demonstration of our bimodal scanning solution

#EmbeddedSystems #CyberSecurity #CPlusPlus #SupplyChainSecurity #SBOM #TrustSource #QuantumSafety


Cyber Resilience Act published

EU Cyber Resilience Act published

The EU Cyber Resilience Act (CRA) was published today. This establishes its validity and timetable, as the publication date determines the corresponding implementation dates: The start of actual validity – i.e. the date from which every software manufacturer or representative of such a manufacturer who places software on the market in the EU must be compliant – is December 11, 2027.

More precisely: The regulations, in particular Art. 13 and Annexes I and II, apply to all products with digital elements that are placed on the EU market from this date. For products that are placed or have been placed on the market beforethis date, the requirements apply as soon as they undergo significant changes after this date, see Art. 69 II CRA. However, the reporting requirements under Art. 14 must be met for all products from September 11, 2026, regardless of the date of market entry (Art. 69 III CRA).

From now on, there is a transitional period until which software providers must deal with the new requirements and implement them. Implementation is not trivial in some cases and requires some organizational change, e.g. the inclusion of any risk analyses and assessments that may not yet exist in the release process, the declaration of support periods or the establishment of suitable vulnerability management processes.

– Unless otherwise stated, all references in the following refer to the text of the CRA –

You want to know more about the challenges your organisation is facing now?

Talk to one of our experts!

For whom is the Cyber Resilience Act relevant?

In principle, the CRA applies to anyone who provides a product with digital elements, i.e. software support. However, it also restricts its application to groups that are already regulated elsewhere. For example, products that are only used in the automotive, marine or aviation sectors or are subject to the Medical Device Regulation are excluded. However, it can be assumed that a dual-use option, i.e. usability in other, non-regulated areas, will also restore validity.

Roles of the actors

The role of the actor is also relevant for the assessment of validity. Conceptually, regulation attempts to make the beneficiary of the economic transaction responsible for the transaction within the EU. What does this mean?

In a simple case, a European provider manufactures a product with digital elements that falls within the regulated area (see above). This means that the supplier is directly obliged to fulfill the CRA requirements for its product, for example a manufacturer of stereo systems or jukeboxes that support music streaming or a machine tool that can be maintained remotely.

If the manufacturer of the product is based outside the EU, these obligations are transferred to its representative, the “distributor”. This can be a dealer, a partner or an implementation partner, i.e. the next economic beneficiary. It is interesting to note that the distributor must also vouch for compliance with the obligations during production. This brings with it a completely new liability regime for license sellers of American software, for example!

Open Source

As soon as open source comes into play, the chain becomes somewhat less clear. But the CRA knows and takes into account the open source concept. The actual creator of an open source solution is not subject to the requirements. However, if an actor takes an open source solution and uses it commercially, be it through support contracts, he is subject to the regulations analogous to those of a provider. For example, a SUSE is responsible under the CRA for the distribution it provides.

There are only exceptions for so-called stewards. These have to fulfill less stringent requirements. This role was created for the so-called Foundations (Eclipse, Cloud native, etc.), as they represent a form of distributor, but do not derive any economic benefits from the provision and distribution comparable to those of a conventional software provider. Recognition is required to be considered a steward.

What are the major changes?

The guiding idea behind the CRA is to improve the security situation for software consumers. Since almost everything today is controlled by and equipped with software, cyber attacks became possible almost everywhere. Every component that is connected to the Internet, Wi-Fi or even near-field communication such as ZigBee or Bluetooth is a potential attack surface and must therefore be used or provided with caution.

The provider of software on the European market must therefore fulfill the following requirements in future:

  • Provision of a software bill of materials (SBOM), see Annex I
  • Regularly carry out a risk assessment of the safety risks and include this in the documentation, see Art. 13, III and IV
  • Drawing up a declaration of conformity, see Art. 13 XII and Art. 28 I and Annex IV
  • Provision of a CE marking, see Art. 12 XII and Art. 30 I
  • Definition of an expected lifetime of the product and the provision of free safety updates within this period, see Art. 13 VIII et seq.
  • Demanding extensive reporting obligations (in accordance with Art. 14)
    • Notification of actively exploited vulnerabilities within 24 hours to the European Network and Information Security Agency (ENISA) via a reporting platform yet to be created (presumably analogous to the solution already in place in the telecom environment)
    • In addition, clarification of the assessment and measures within 72 hours
    • Information of the users of the product and the measures to be taken by them, see Art. 14 VIII.

How could TrustSource support?

  • Unified platform for software analysis, compliance & release management
  • Integrated risk management
  • Automated vulnerability management
  • Consistent, CRA-compliant documentation
  • CSAF-compliant reports
  • Standardized vulnerability reporting process
  • Implementation support

Test now

What are the consequences of non-compliance?

Every law is initially just a declaration of a behavioral requirement. But what are the consequences if you do not comply? What risks do providers face?

With publication, the member states are instructed to appoint a body that is responsible for supervision in the respective country. In Germany, this will most likely be the BSI. In turn, the BSI can then carry out or commission corresponding inspections in the event of suspicion. If deficiencies are identified, this usually leads to a request for rectification, but can also be sanctioned accordingly. The CRA provides for the following possible sanctions:

  • Up to EUR 15 million or, in the case of companies, up to 2.5% of global annual turnover in the previous financial year in the event of a breach of essential safety requirements (Annex I). (see Art. 64 II)
  • For breach of obligations imposed by the CRA, up to EUR 10 million or – for companies – up to 2% of the ww turnover (previous year) (see Art. 64 III)
  • For incorrect, incomplete or misleading reports to the authorities, up to EUR 5 million or 1% of annual turnover for companies (see Art. 64 IV)

In addition, there is the possibility of restricting the distribution of the product or withdrawing it from the market in the event of sustained non-compliance, see e.g. Art. 58 II.

You want to better understand what this means for your organisation?

Talk to one of our experts!


Privacy Preference Center