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.
Tackling the nx-Challenge
How to identify malicious NX versions in your code base
Recently it happened again: A sophisticated supply chain attack was initiated by some malicious actors. The nx-team and several security researchers (1, 2)already reported about this incident. Find here a quick summary:
What has happened?
nx is a package with a bit more than 23 mil downloads on NPM package registry. It comprises of several plugins developers use to simplify code management activities, such as some utility functions on writing files, updating configuration (devkit), manage node itself (node) or liniting JavaScript and Typescript code (lint).
The versions around 20.9.0 and 21.5.0 respectively 3.2.0 (key & enterprise-cloud) were maliciously modified. They executed an AI based search assessing local file structures of the developer’s workspace and pulled all sorts of secrets together. These were then published into a public git-repository using the develoepr’s git credentials.
What to do about it?
The very first step would be to identify whether someone in your organization is using the impacted nx tools. Given you are using TrustSource, it may be as simple as opening the `Component impact report` and search for the impacted components in the given versions, e.g. @nx/devkit in version 21.5.0 or 20.9.0. TrustSource will list you all projects where exactly this component-versions are in the list of transitive dependencies.
This is a good example, why transitive dependencies are so important. nx has about 663 dependent projects, or in other words: there are 663 other tools using nx tools. You may imagine how fast and wide the spread may be.
However, given a project is using the impacted versions, the developers must consider their complete CI/CD chain being compromised. Every developer should check whether they have a repository with `s1ngularity` in its name published throughout the last 2-3 weeks. All credentials you will find in this repository must be accepted as leaked.
But before you are going to replace them, make sure to clean up your workspace!
To get more insights and details of how to cleanup your workspace read this article.
What to learn from it?
We are glad as we are not using this tooling. But it has two interesting learnings for us:
a) So far we were very much focused on the delivery artifact. This is why ts-scan for example, as default, is not including dev-dependencies. To include dev dependencies in your scan, you will need to add the npm:includeDevDependencies parameter. If you never did run a scan using these parameters, it is most likely that the TrustSource component impact report from above will not show you any findings, despite the tools may be used by your developers.
This is important to understand and the reason why we recommend to inform all developer’s in your organization about the situation. We even recommend to ask providing scans using the above parameter and run the report again over the next days and weeks. Some of the 663 tools using nx may use it under the hood, e.g. nx-python codegen, reactionary, goodiebag, etc., so that it may not be obvious to your developers.
We further recommend to move the scans containing the dev-dependencies in a separate project/module. Assuming you have project A and it has modules A1 and A2, the scans using the dev-dependencies could target project A-DEV using modules A1 and A2. This would allow you to track all dev dependencies but keep them out of the ordinary compliance flows. projects that do not provide a PROJECTNAME-DEV can be identified simply by sorting the project list ascending.
b) Often dev environments are kept open and less secure. The saying “who should consider breaking this and what could he get?” is often heard. But here you see, what the impact may be. Starting from encryption to information and credential disclosure every developer’s work could be impacted directly. Indirectly this may lead to malicious code introduction, compromising the developer’s products, harm the developer’s company’s reputation and its customer’s business.
While this might not have been a likely event five years ago, today it needs to be taken into account as a reality. You should setup your dev environments accordingly. (internal package proxies, protected and clearly documented builds (SBOMs), strict protection of CI/CD credentials, api-keys and use of key stores, etc. Introduce the right risk management from the beginning: What could go wrong, if our code is malicious / faulty / hacked? How could that happen? What would be the impact on confidentiality/availability or integrity of our customer’s data / operations / business?
If you need support in answering these questions, feel free to reach out. Our mother company is specialized in supporting its customers in answering such questions and developing strategies on how to secure CI/CD and the development results. See here for more information.
TrustSource Security Information - TSSI250000 - empty Vulnerability
TSSI-25:0000 - Security Information
issued: 2025-01-28T22:30:00.000Z
updated: 2025-01-28T22:30:00.000Z
Synopsis
Informational: This document has been prepared and will be continuously updated to provide proof, that the feed is working properly.
Type/Severity
Security Information: Informational
Topic
Test your security alerting path.
Description
It is more interesting to see this null information than to receive an empty RSS. By getting this information, you will know that your RSS feed is working properly and you may trust that new, relevant information will reach you.
Solution
Be prepared to read real Security Advisories under this RSS feed.
Affected Services / Tools
- none
Fixes
- none
Associated CVEs
- none
Further References
- none