TrustSource @ LSEC on SBOMs
Let’s meet at the IIOT SBOM Nov. 10th!
Thank you @ LSEC – Leaders In Security for inviting us to talk about #SBOM #DevSecOps and the upcoming challenges form the security point of view. @Jan will address the challenges around generating SBOMs, how to tackle it on the automation side in his talk “Getting the SBOM right, and then?”. Further on the talk will address thoughts on the life cycle perspective, what comes after the SBOMs creation. It also will also report about the work the #LinuxFoundation #OpenChain Automation work group is performing as well as invite to a new sort of SBOM user group, outlining best practises on defining SBOMs.
Looking forward having great conversations and learn even more about the challenges you are facing while creating SBOMs in the IIOT world.
C U there!
Gleaning
(22.11.22) Thank you very much for the kind hosting and the gerat exchange to all other speakers and participants at the IIOT SBOM. It has been great to learn about your demands and thoughts. Looking forward talking to you further. All speeches have been recorded and are avialble at the IIOT SBOM website. Jan’s talk we linked here.
It is split into two sections due to coordination with some speakers from different time zones. However, the first part addresses the SBOM and its contents. What should go in, what is a suitable format and what are the benefits of producing SBOMs (besides compliance with regulatory requirements). The second part addresses SBOM creation automation, transfer a few experiences from the legal SBOM design and spins a few thoughts on what you may do with SBOMs whilst they are around.
Free Vulnerability Lake Search - Better identify potentially vulnerable Components and other Tools
TrustSource Vulnerability Lake Search
Both software developers and security researchers are familiar with the challenge of assigning known vulnerabilities to open source components. Although the CPE (Common Platform Enumeration) codes provide a standardised scheme for associating vulnerabilities, the nomenclature was originally developed for vendor software and only fits poorly in the context of open source components, which often lack a clear “organisation”.
This leads to problems in finding and correctly assigning them. Sometimes the project name wins, e.g. “kubernetes:kubernetes“, other times it is the organising foundation, e.g. “apache:http“. Sometimes projects pass through different organisations over time, like the widely used Spring framework. Then information can be found under “pivotal_software:spring_framework” and from 2019 under “vmware:spring_framework“, which will cause a lot of irritation for years to come due to the concurrency of versions.
And, to top it off, there are even challenges with the project names themselves: “npmjs” or rather “npm_js” or “npmjs:npm”?
TrustSource Vulnerability Lake Search turns the tables: it provides search options to search in the existing CPEs and thus ensures to find the right keys to be considered.
With the help of TrustSource Vulnerability Alert I will catch all Known Vulnerabilities even while asleep!!
TrustSource Vulnerability Alert
With the help of the TrustSource Vulnerability Alert, you can always stay up to date. The identifiers found with the search described above can be subscribed to. Registered users – registration is free and easy, e.g. via a GitHub account – can add selected terms to a list. These lists are checked every few hours against updates from managed sources such as the NVD. If updates or new entries are found, the subscriber receives an email with a link to the new information.
TrustSource customers get this functionality automatically applied to all the bills of materials (SBOMs) in their solution(s). TrustSource-Scanners
determine the SBOMs while your application is being built and therefore know all the dependencies, including the transitive ones. In addition, you can also add infrastructure components to the project in TrustSource itself, and thus identify the vulnerable libraries that do not occur in your own source code.
Vulnerability alerts can be communicated either by email to the relevant project participants or to the system’s own inbox. The latter is especially necessary to avoid failures due to absences or other filters of asynchronous communication.
To enable easy integration into surrounding systems, all these functions are also available via API. However, the use of the API is subject to a fee and is not part of the free plans.
In order to enable a quick classification of the criticality, TrustSource always shows the information on the attack vector as well as the criticality in CVSS values (Common Vulnerability Scoring System, find details on CVSS here) in addition to the description of the CVE or its assignment to the OS components.
TrustSource Life Cycle Alert
These capabilities result in yet another service that TrustSource makes available to its customers: The Life-Cycle Alert.
The obligation of a software manufacturer to inform its customers about known vulnerabilities does not end with the delivery of the software, it usually begins only then. This is even more true for equipment manufacturers. The less possibility there is to motivate the customer for timely updates, the more complex the situation becomes.
If, in the course of time _after_ the release of the software, known vulnerabilities emerge in the components used, it is up to the manufacturer to inform its customers in the sense of proper information provision. This obligation is already applied in the area of medical devices (MDR) and will certainly extend to other areas.
TrustSource makes it possible to record SBOMs that have been released and thus subject them to continuous monitoring. Every patch or release status that has been generated on a customer product can be tracked and alerted accordingly.
