TrustSource adds EoL data
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.
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:
- Security: Known vulnerabilities remain permanently unpatched. Every new CVE disclosure can become an existential threat — with no remediation path available from the vendor.
- Operations: EoL components lose compatibility with evolving systems, libraries, and interfaces. What works today can silently break tomorrow, disrupting critical business processes.
- Compliance:
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.
Do you want to learn more about the impact the CRA will have on your software development? Profit from applying our free CRA assessment!
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.
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?
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:
- 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.
- 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.
- Downstream API:
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:
Do you want to know, how you may feed EOL data into your processes?
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
ts-scan available as github-action
Streamline Your Supply Chain Security: TrustSource’s ts-scan Now Available as a GitHub Action
We are thrilled to announce that TrustSource’s powerful Software Composition Analysis (SCA) tool, ts-scan, is now available directly within the GitHub Marketplace. Integrating robust security scanning and compliance into your CI/CD pipeline has never been easier.
The new ts-scan-action allows developers to automatically generate Software Bill of Materials (SBOMs) in standard formats—including SPDX and CycloneDX—directly within their workflows directly from the Github Marketplace.
Crucially, ts-scan is designed for simplicity and privacy. It operates entirely locally, meaning no API keys required for the basic actions and no data leaves your environment during the scan process, as long as you do not want to make use of the additional TrustSource SaaS offerings, such as risk management, automated legal compliance or approval flows. (learn more at https://www.trustsource.io )
Intelligent, Zero-Config Scanning
The unique selling proposition of ts-scan is its intelligent autodetection capability. Unlike many tools that require tedious configuration to define scope, ts-scan is capable of scanning almost all target types automatically without needing explicit direction.
Whether you are targeting common package management systems, specific files, entire repositories, or Docker images, ts-scan identifies the structure and performs the analysis seamlessly.
Get Started
Elevate your project’s transparency and security today by integrating TrustSource into your GitHub workflows.
-
Get the GitHub Action: Start using it immediately via the marketplace: https://github.com/trustsource/ts-scan-action
-
Deep Dive: Learn more about the tool’s extensive capabilities in our documentation: https://trustsource.github.io/ts-scan
-
Explore the Code: Check out the core tool repository on GitHub: https://github.com/trustsource/ts-scan
Navigating PQC Threat
In the digital realm, we often take for granted that our “locks”—the encryption safeguarding our bank transfers, state secrets, and private messages—are unbreakable. For decades, this has been true. However, a silent storm is gathering on the horizon of computation: the advent of cryptanalytically relevant quantum computers.
The Quantum Threat: Breaking the Unbreakable
Current cryptographic standards, such as RSA and Elliptic Curve Cryptography (ECC), rely on mathematical problems that are prohibitively difficult for classical computers to solve (e.g., factoring large prime numbers). A quantum computer, utilizing the principles of superposition and entanglement, can process information in ways a classical machine cannot.
Specifically, Shor’s Algorithm allows a sufficiently powerful quantum computer to crack these asymmetric “locks” in minutes. This creates a “harvest now, decrypt later” risk: adversaries may be capturing encrypted data today, waiting for the technology to mature so they can unlock it in the future.
Lessons from History: The Agony of Transition
We have been here before, though never with such high stakes. Historical transitions offer a cautionary tale:
-
DES to AES: When the Data Encryption Standard (DES) was cracked in the late 90s, the migration to the Advanced Encryption Standard (AES) took nearly a decade.
-
SHA-1 Deprecation: The move away from the SHA-1 hashing algorithm (after it was found vulnerable) was plagued by “zombie” systems that continued to use the insecure standard for years, leading to widespread vulnerabilities.
-
The Y2K Comparison: Like Y2K, PQC migration has a “deadline” dictated by hardware progress. However, unlike Y2K, we don’t know the exact date the clock hits midnight.
The primary challenge in these historical shifts wasn’t the new math; it was visibility. Organizations often didn’t know where their cryptography was “hard-coded,” making updates a manual, error-prone nightmare of hunting through legacy code and hardware.
The Solution: Cryptographic Agility
Global security experts ,cryptography scientists and meanwhile the US Department of War in a memo to its leadership last November are mandating a proactive approach: Cryptographic Agility.
Crypto agility is the ability of an information system to rapidly switch between cryptographic algorithms without requiring significant infrastructure changes or massive code rewrites. Instead of being “bolted on,” security becomes modular. This approach is essential because:
-
Algorithms evolve: As NIST standardizes PQC, initial versions may need updates as new vulnerabilities are discovered.
-
Hybridization: Migration often requires running legacy and quantum-resistant algorithms side-by-side during a transition period.
-
Future-Proofing: An agile system can adapt to the next threat without a multi-year “rip and replace” cycle.
To achieve this, organizations must first establish a comprehensive cryptographic inventory, identifying every instance of encryption across national security systems, cloud assets, and IoT devices.
” Stay ahead of the curve. Secure your future today.
Take the Next Step with TrustSource
Navigating the migration to Post-Quantum Cryptography (PQC) doesn’t have to be a journey into the unknown. TrustSource provides the tools and expertise to ensure your organization remains resilient.
-
TrustSource Cryptographic Discovery Services:
We help you identify, inventory, and assess your current cryptographic footprint, mapping out a risk-managed path to quantum resistance. - TrustSource SBOM Inventory and Compliance Workflows:
Store your SBOMs in the TrustSource inventory or use the approval workflows to manage the risks before releasing your software. Document existence and usage of crypto algorithms based on our component knowhow whether for export controls or your crypto agility implementations. - TrustSource Crypto Reporting:
Profit from the portfolio wide analysis of used crypto algorithms, define migration strategies based on components and portfolio risks. - TrustSource Crypto Policies:
Use policies to prevent the implementation and/or use of weak algorithms across the whole organization directly in the build chains.
Want to learn more on PQC?
Update ts-scan to v1.5.2
Based on the events surrounding the Shai-Hulud worm, we have adjusted the basic configuration of our SCA scanner ts-scan. In its standard configuration, it no longer executes scripts from the <scripts> section of package.json. Instead, a warning is issued that there may be an insecure configuration. To execute the scripts anyway, the parameter node:enableLifecycleScripts must be explicitly added to the scan call from version 1.5.2 onwards.
We recommend that our customers and users update ts-scan to the latest version – v1.5.2 in this case – to better protect their environment from malicious activity triggered by unwanted script execution.
PLEASE NOTE: This is not a vulnerability caused by ts-scan. The ability to embed arbitrary scripts in package.json and have them executed is a feature of the Node environment. This has existed for quite some time and was already discussed years ago as a potential security vulnerability. However, no action has been taken against it so far.