Over the years, the use of open-source libraries and components has become an indispensable part of our application development processes. Thanks to the power of the community, libraries and components that successfully handle many fundamental — and even complex — operations have emerged.
At this point, we have access to components that already have working solutions, have been tested by many different people, have had their bugs resolved in proportion to their usage, and no longer need to be rewritten. Everything described so far represents the full side of the glass. On the empty side, however, are those with malicious intent.
Libraries and components known to be used by thousands or even millions of people are in a highly attractive position for reaching vast audiences all at once — and even infiltrating their systems. For this reason, many attackers today target projects hosted on source code and package management/distribution platforms such as NPM, PyPI, and GitHub.
In a scenario where attackers successfully infiltrate a targeted package and/or application, they will have simultaneously gained access to all systems using that library and/or application — you can reach our research on recent Supply Chain Security incidents here.
Fortunately, the ecosystem is not made up of malicious actors alone. Many individuals and even organizations regularly carry out work in areas such as identifying potential security vulnerabilities in projects within the ecosystem and detecting malicious content added to libraries and applications by attackers.
CVE — NVD — SCA
The flow from the discovery of a vulnerability in a library or application, through its registration in the NVD — National Vulnerability Database, to its availability for use by scanning tools can be summarized as follows.
As can be understood from the flow, we are able to determine whether vulnerabilities identified by researchers exist within our organization's projects with the help of SCA — Software Composition Analysis tools.
SecFlowX
At this point, SecFlowX provides us with a detailed view at both the project and organization level. It enables our application dependencies and vulnerability statuses to be obtained either through CI/CD integration or via scans that can be initiated directly from SecFlowX.
NO-CVE Vulnerabilities
So what do we do if a malicious package or application has no CVE identifier? One of the most concerning issues for organizations right now is malicious packages that carry no CVE. The malicious code injected into the LiteLLM application is one of the clearest examples of this situation — because the vulnerability currently has no CVE assigned.
The image below shows a grype scan output for a sample project containing the litellm==1.82.8 dependency.
As can be seen, the scan yields no detection related to the vulnerable package. It would not be fair to blame grype or any similar SCA tool for this, as no such record exists in the tool's database — it may be possible for solutions with CTI sources and dedicated research teams to generate custom identifiers for vulnerabilities of this nature.
So how do we solve this problem? The answer is straightforward: through package inventory tracking. If we know all the dependencies and version information of the organization's projects, we can check whether we have any components that are affected by the vulnerability. The result obtained by scanning the same project from the previous step through SecFlowX is as follows.
Bingo! As can be seen, we have confirmed that the litellm==1.82.8 library which we know to be vulnerable — is present in our inventory, and we did so without a CVE identifier.
Summary
Software Supply Chain attacks and defense strategies are becoming increasingly critical with each passing day. Knowing the components used in an organization's inventory is no longer optional it is a mandatory requirement. At this point, SecFlowX can help you make your existing application security processes more secure and sustainable.
Detailed usage walkthrough on the platform:
