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.


TrustSource and SCANOSS will work closer in supporting Open Source Compliance

TrustSource und SCANOSS will work closer in supporting Open Source Compliance

In the run-up to the Open Source Summit Europe 2022, SCANOSS – provider of probably the largest database for open source information – and TrustSource – the automation solution for processes in the area of open chain security and compliance – have agreed to cooperate more closely in the future.

The OpenChain Tooling Workgroup has been developing the Open Source Compliance Capability Model over the last months. This model describes the different competences and skills required for a comprehensive handling of open source compliance. “SCANOSS has standardised >snippet scanning< with the first Open Source solution, which has been broadly adopted by Open Source communities like, e.g. OSS Review Toolkit”, reports Jan Thielscher, who is currently coordinating the workgroup. “This is exactly the area we (TrustSource) have been avoiding so far due to its complexity. Working closer with SCANOSS, we will be able to offer our customers access to their incredible information base. This helps to close the last white spot on our capability map by adding the snippet and export restrictions aspect.”

Currently, it is already possible to import scan results generated using the SCANOSS Workbench or SCANOSS CLI into TrustSource and thus follow up the findings in the compliance process managed by TrustSource. ScanOSS users are thus given the opportunity to not only have results available in the form of an audit result, but to integrate them into the regular context of a company-wide compliance management. TrustSource users will initially benefit from the ability to use the additional insights provided by SCANOSS. In the near future, the extended insights such as export controls, etc., which SCANOSS can provide, will also be available to manage or monitor compliance with in TrustSource.

“That will round things off,” says Jan Thielscher. “Of course, insufficient metadata, undeclared licences or unclear commit situations continue to pose challenges for OSPOs, but the majority of the tasks can already be automated thanks to the high level of integration and the many reports that are available due to the high level of integration. And that’s where the immense efficiency gain can be realised!”

Meet us at the Open Source Summit in Dublin @ B.19

Learn more about the Open Chain Tooling Workgroup Capability Model, TrustSource and how much process automation is already available in the area of open source compliance.


TrustSource Upgrade to v2.5.59

2.

5.

59.

We are happy to announce the latest upgrade to v2.5.59. As usual we added a few features, improved and fixed a few things. For detailed information see our Changelog.


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.

It sounds promising but you are not sure whether your specific demand will be met?

Or would you prefer to get hands-on experience in a free trial?


Free Open Source Compliance Training

For years, the same questions have arisen again and again in the context of open source:

  • Am I allowed to use open source in applications used for business purposes?
  • What are the consequences of using open source?
  • Is the GPL a “toxic” license?
  • What do the American licenses mean for us in Europe?

The irritation hits developers in particular, who are confronted with the use or deployment of open source in the front line. Now, computer scientists are rarely also lawyers, and even if law and computer science are similar in many aspects, it is not trivial to interpret a license without prior legal knowledge.
To help overcome this gap, we have provided a basic Open Source Compliance – Training. The training introduces the topic, briefly describes the background and gives insight into the essential aspects of licenses. More than 4 hours of video material, presentations and quizzes have been incorporated into the freely available, self-paced online training course.

In the course the participant gets an overview of:

  • The motivation and background of open source compliance,
  • The challenges that make open source compliance more than just making a list,
  • Solution concepts that help to anchor standard compliant open source compliance in an organization.

The presentations, held in English, are divided into small, short bites, so that they can be easily consumed in between online meetings or in short doses at the beginning of each day.
Direct access can be found here on the Trainings page.


TrustSource v2.0 to come!

TrustSource 2.0 comes with new look & feel

We are proud to announce availability of the upcoming v2.0 of TrustSource by May 7th.

Since the list of features has become a bit crowded over the last few versions, we have arranged the navigation area into groups. These are organized according to the phases of value creation, which helps to find your way more quickly: Scanners in the Inbound group, Vulnerability Information and Project Management Tasks goes into Internal, or Notice File Generation you will find in Outbound.

More focus in work

Furthermore, we help our customers to focus. Especially in larger organizations with extensive project portfolios, it becomes important to move quickly and focus. With the help of the “Pin to Dashboard” function, it is now possible to pin projects directly to the dashboard, enabling direct link with just a few clicks. Also included in this segment is the ability to tag projects and modules. Table views can be filtered with the help of tags, which quickly provides more visibility. In later expansion stages, the tags will also be usable in the reports and other overviews.

Vulnerability Lake

To simplify your daily work, we have included a complete replica of the NVD data. Updated every two hours you can now browse through the CVEs, research by organisation, product and versions (CPEs) from within TrustSource or through our API. It is our intention to grow the pool of data and make this valuable knowledge available at your fingertips.

New import API for CycloneDX SBOMs

We have also taken into account the developments on the market and included the CycloneDX standard, which is establishing itself more and more quickly. It is now possible to import CycloneDX documents. This means that all CycloneDX-compatible scanners can also be used to work with TrustSource. The documents only have to be transferred to the new API /import/scan/cyclonedx.

Improvements

In addition to that, we also will introduce a row of improvements

  • It will now possible to jump back and forth between the scan – the raw data introduced to TrustSource by any scanner or the CycloneDX SBOM upload – and the analysed dependency view. This will help to understand the dependency hierarchy.
  • We have improved the speed of loading the analysis selector. Daily scanned but never changed projects had a tendency to produce a heavy latency.
  • DeepLinks from DeepScan results view into the repository are now also supported for specific branches

Fixes

The following fixes will be provided:

  • Deletion of license alias in a non sequential order will not produce empty aliases anymore
  • Preventing an internal error when module or component names were extraordinarily long during Scans
  • Date representation in Safari sometimes did not work correctly
  • Some adjustments to component crawlers and the storage of results will reduce the amount of buggy data

Want to learn more about SBOMs or OpenSSF? Feel free contacting us!


TrustSource

How TrustSource protects against dependency confusion attacks

What has happened?

Security researchers have managed to gain access to various high-security networks with the help of a dependency confusion attack. With this attack, they managed to send protected information and data from within the affected networks to the outside. However, depending on the attack scenario, other activities would also be imaginable. Once behind the defense lines, the damage scenario can be freely chosen.

How was the attack executed?

The security researchers got the idea when they found names of private packages in the published open source tools of the companies (Apple, Adobe, etc.)

Companies often use open source and supplement certain functionalities or graphical controls with their own libraries. These, in turn, are developed by only one team and made available as separate packages or libraries to other development teams. This is efficient and convenient because the broad set of development teams does not have to worry about it, yet the look-and-feel remains consistent across different applications or services.

If the companies now play software back to the community and the references to such “private” packages are not removed from the source code, the release will carry the name of these packages outside. This in itself is not that dangerous. It only becomes interesting if the information is exploited for a dependency attack (see next page).

How could you protect yourself from this to happen?

  • Component naming:
    If the internal component names follow a naming scheme, such as ORG.COPMANY.UNIT.UITOOLS, it becomes much more difficult for third parties to create corresponding names in the package managers without causing a stir. ORG.COPMANY.UNIT.UITOOLS is more noticeable than the 100th version of UITOOLS.
  • Configuration of packet manager proxies:
    To be successful in the attack, the local distribution mechanisms must be outwitted. It should be ensured that no updates are pulled from outside for certain package types, e.g. with the help of the name identifier or a simple blacklist.
  • Version control:
    With the help of a version history, it quickly becomes possible to determine which versions are in use. A jump from 1.2.3 to 69.1.0 can be discovered quickly or is noticeable.

What is a dependency confusion?

Modern package systems use package managers, especially to manage the ever-growing number of open source components. Each build specification therefore contains a list of the components to be included. In Java this is the POM.XML file, in Node.JS (JavaScript) it is the PACKAGES.JSON.

In this file the components and the minimum requirements to the components, the version numbers are indicated. Since many components change frequently, the requirements often contain not only the exact version number, e.g. 1.2.3, but a note like ^1.2.3, which means something like: “Give me at least 1.2.3 or newer.” . If the maintainer of the component updates to e.g. 1.2.4 (new patch) or 1.3.0 (new feature), the own solution would be able to profit from the innovations with the help of the formulation during the next build.

If a malicious actor now posts a newer version in a package manager, for example a 12.1.0, he can be relatively sure that this version would be provided by the package management for the context described above.
If the project now builds a new version, the malicious code would be pulled from outside, integrated into a QA system, and deployed there. Depending on the damage scenario chosen, a lot can be done with this.

You want to manage vulnerability protection along the complete lifecycle of your product?

TrustSource can help to protect you!

If you use TrustSource, it will know the current versions of your modules and solutions, as well as publicly available components. Sudden version jumps of publicly available components are detected by our systems and reported to our support team for review. Critical developments are reported back to the projects.

If you are already using TrustSource, you are probably familiar with the concept of “linked modules”, the integration of releases of your own software. If versions appear here that were previously unknown, this also leads to a report to the respective project manager. In this way, you can be sure to notice corresponding developments quickly.


TrustSource @ FOSDEM 2021

TrustSource @ FOSDEM 2021

we are looking forward to the presentations of @Jan Thielscher & @Grigory Markin at FOSDEM 2021.

Open Source Compliance Tooling – Capability Reference Architecture

Jan will present the Open Source Tooling Workgroup‘s reference model in the OpenChain Dev-Room , which outlines domain-specific capabilities and their interrelationships. The model has been created over the last two years by members of the workgroup and is intended to provide an overview of the required tasks that will be needed in the context of open source compliance. It is also useful for mapping the different tools or being clear about what functionality they cover. See the complete video here.

During the talk Jan will also try to motivate tool vendors to map their tools against the model.

Capabilities in comparison

In a second talk, Grigory Markin will present the TrustSource DeepScan open source tool and the free online service DeepScan of the same name in the Dev-Room Software Composition. This solution has been developed to support open source users in identifying the effective licenses and attribution information (license & copyright) :

TrustSource DeepScan – How to effectively excavate effective licenses

In this 15 minute talk, Grigory and Jan will briefly outline the challenge of “effective” licenses and discuss the various technical possibilities and challenges of automated license analysis using similarity analysis, among other things. Finally, the tool, the current state of work and the next steps will be briefly presented.

Want to learn more about SBOMs or OpenSSF? Feel free contacting us!


Vulnerability Lake in beta

TrustSource adds Vulnerability Lake

Due to many requests we decided to open up our internal vulnerability DB for research by developers. Starting from version 2.0 TrustSource will provide its internal “known vulnerability” database for search. There will be several searches available:

  1. TrustSource Vulnerability-Lake public web UI
  2. TrustSource Vulnerability-Lake web UI
  3. TrustSource Vulnerability-Lake API

The public web UI as well as the TrustSource integrated web ui provide a simple and an expert search mode. You …

 

TrustSource Vulnerability Lake allows simple overview of vulnerability status

Want to learn more about SBOMs or OpenSSF? Feel free contacting us!


TrustSource DeepScan - Catch effective open source licenses

TrustSource DeepScan - CLI, web-based or as part of service

DeepScan is an open source tool, helping you to achieve open source compliance. You may use DeepScan to scan the repositories of your solution or the components you are applying. It will identify all license and – if wanted – copyright information. This is relevant to ensure that you have the correct understanding of the rights and obligations associated with the open source components you are using.

DeepScan is available in three flavours:

While the CLI version is fully functional, it requires the user to assess the results file by himself. The CLI-version can publish its findings either in standard out or in a file using JSON. The web-based UI provides a comfortable way to watch and work with the results. The solution integrated with TrustSource allows you to amend the findings and share your data with others.

Why are effective licenses so relevant?

Everybody developing software should have an understanding about the components he is using to provide his solution due to two reasons:

  1. Legal compliance
  2. Security

Getting a grip on legal compliance

From the legal perspective, it is essential to understand what your solution consists of. Open source does not imply free goods. Just to have free access does not mean you are free from obligations. Often open source components come with a license that requires the user to comply with certain obligations. In many cases the right to use is bound to the compliance with some obligations, e.g. attributing the copyright holder.

Theoretically every component can have its own license. In practice it turns out that there are roundabout 400 licenses and a countless number of derivates that govern the usage of open source. Some are more, some are less restrictive. However, given you do not take care for the rights and obligations associated with the components you are using, you swiftly slide out of legal conformance. In the worst case official law enforcement might charge senior management of companies not effectively preventing such risk with professional fraud.

DeepScan helps to assess repositories for license indications, exposing all findings in a comfortable way. Compiled into one reult, with links into the depth of the repository allowing fast tracking and review.

Give it a try!

No installation or registration required…  

 Keeping track of what is used improves security

The second reason, why you better should be aware of the components inside your solution is, to learn early about issues associated with such components. Given you have the structures of your solutions scanned with TrustSource, all versions of the builds are chronologically available. trustSource checks NVD and other vulnerability boards for updates and compares incoming data with its components information. If you use – or have used – a vulnerable component, you will get a notification.

This gives you an advantage over potential malicious actors. You may inform your customers still using vulnerable versions, start working on fixes or at least help them to prevent misuse by malicious actors.

So you see, there are many reasons, why you should know what is inside your code base….

To learn more about the different DeepScan solutions we provide, see this short video introduction. This speech will be provided at FOSDEM 21 in the Software Composition Analysis DevRoom.

Want to learn more about SBOMs or OpenSSF? Feel free contacting us!