TrustSource adds OpenSSF Scorecards

click here to enlarge image

In our component database, where we collect meta and clearing information on components, we added the Open Source Security Foundation (OpenSSF) Scorecard to help exploring the security status of open source projects. The score, introduced by the OpenSSF project of the Linux Foundation in 2020 and currently evaluated on regular basis for about 1 million open source projects on Github, is an aggregated value reflecting the security measures taken by the open source project. It can be used as an indication on how much you may trust the security efforts of a particular project without having evaluated it further.

What does the Scorecard tell?

The scorecard value or score is the result of sixteen checks reflecting secure software development best practises. They comprise the domains of development, testing, maintenance and vulnerabilities but also code and build management. Based on the a comprehensive set of best practises the tests scan the code repository for evidence, that the practises are actively supported by the project.

Currently 18 tests are available, 16 of which are available through the API. The detailed documentation can be found here. Each test will receive a score between 0 and 10, with 10 being the best possible score. The tests come with a result and and a risk as weight. The sum of all tests together with their weight derives the total score.

Some tests may sometimes not be applicable due to project design decisions, e.g. if the project does not supply packages through Github, the packaging test will not apply, since the current implementation does not yet provide a mechanism to verify the different package managers.

However, given you want to make a decision whether or not to use a particular component, running a scorecard test – or looking at the component in our database – will help you getting an impression on what effort you might need to invest in securing the component. The higher the score the more you may trust on the component.

What does the Scorecard NOT tell?

Please do not understand a high score as a guarantee for a secure component! Also a low score does not immediately relate to a weak or flawy component! There is no logic in assuming that a low score is an indication for a vulnerable component!

The score indicates which steps the project takes to ensure the code it provides follows best practises and therefor has a high likeliness of being free from errors and vulnerabilities. But it is no guarantee! If all is done fine, all tests boost to 10, there still might be the chance that a vulnerability occurs in an upstream component which is not simple or possible to fix for the project itself.

Use the score as an indicator but make the decision of whether to use a component or not based on its functionality not only on the score. You will – especially in these early days when the score is not yet widely adopted –

What comes next?

However, we highly recommend using scorecards because they give an indication of how strongly you may rely on your upstream components.

Since TrustSource knows all the components you apply inside your solution, it will now be possible to make more out of the single scores. A simple average will not make sense. Due to the amount of components an average score will have to be expected somewhere at a meaningless 5. But we are currently experimenting with quantiles or top 10 and low 10 averages as well as the relation of not scored components compared to scored ones.

In addition we will provide a service, that will allow you to check your own components by just providing a URL and transferring the scorecard to non github projects. Given we achieve some success, we will contribute our developments back to OpenSSF.

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


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?


New Features in TrustSource v2.5

We’ve put a lot in the feature box again!

Rejoice with us and try it out right away!

New Features:

New role Portfolio Manager and Portfolio Overview introduced:
In response to customer requests, a Portfolio Manager role has been introduced, which can always keep an eye on the totality of issues. For this purpose, an explicit portfolio overview was built, which allows to identify critical components from the portfolio overview within only three clicks.
New search options for Vulnerability Lake:
It is now also possible to search for CPEs or component identifiers and subscribe to them if suitable. This makes it easy to track different identifiers or sources.
Ability to display vulnerability descriptions directly (Get Details):
Allows the description of a vulnerability to be displayed directly so that the screen does not have to be changed. This allows decisions to be made directly in context.
Vulnerabilities for infrastructure components:
With the help of the vulnerability lake, it is now also possible to better resolve the known vulnerabilities for the infrastructure components and display them in detail in the application.
Automatic fixing of legal todos with the help of the notice file
It is now possible to generate the notice file as a pre-version without approval. TrustSource now automatically sets all obligations that are slain with the notice file to “completed” and refers to the notice file. This saves a lot of maintenance work.
Interoperability: Support for all CycloneDX SBOMs
We have included CycloneDX. Both in the core for manual uploads of modules or 3rd party software, and via API. This means that in addition to SPDX, CycloneDX is now also fully possible via both channels, which enables integration with almost all scanners. In the course of this, an import API for SPDX (v2.2+) was also created.
Dependencies are displayed using a SunBurst diagram for greater clarity.
CMake integration: With the help of this new scanner, C-Make built projects can be easily scanned and transferred to the platform for further analysis.
Improvements:

Attack vector representation has been equalised and made more readable.
Since the addition of additional sources, the deep link to the NVD was impractical, so we have provided an internal representation. This will also change slightly in the coming weeks.
Loading times of larger scans optimised and shortened
Vulnerability Alert mails now contain appropriate deep links so that the new information can be jumped to directly.
Internal optimisations in the area of Vulnerability Assignments.
Changes in the framework no longer only affect the analysis and the results, the notice file is now also adapted.
New intro for new users.
Improvements for the administration of components (Component Manager)
ts-node-client updated to work with newer node versions.
Tagging capabilities improved, especially for components, projects and modules, to simplify filtering.
Improved sorting capabilities in CompDB
Added chronicle of legal settings. This means that older states can also be retrieved.


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!


How to convince your Management of the importance of Open Source Compliance

How to convince Management

Often when talking to our customers from the corporate areas, we recognize a reasonable acceptance for the topic in the developers levels. There is an awareness for the “copyright”-aspects of software. On the one hand this is due to the many years of beating the drum for that topic, that most engaged developers experienced meanwhile. On the other hand it is due to many of them publishing software by themselves.

Unfortunately these experiences are moving in the background in the same way as financial aspects appear in the foreground. The more people focus on financial and commercial aspects of a product or service, the less room for respect of creative freedom seems to exist. This does not mean, that managers tend to underestimate the quality of work they receive in open source products nor shall it put the league of managers in the corner of ignorant work bots. But whenever you are facing deadlines for delivery and/or have to align budget constrains with a competitive feature list, open source compliance remains the 2nd priority to look for.

Not looking for open source compliance might be a bad mistake…

This might be a bad mistake! Open Source Compliance is not an option, it is a must! The key aspect of open source compliance is the generation of a “Software Bill of Materials”. The closer your solution is to a piece of hardware, the more it will be relevant as it is most likely that the software will be distributed with this piece of hardware. Missing out on compliance – even by accident – might be seen a as criminal act. Not addressing compliance aspects in a commercial organisation is a sort of fraud.

…especially due to the fact, that it can be heavily automated!

Thus management is well suited taking care of compliance. Especially due to the fact, that it meanwhile can be heavily automated. Integrate the generation of SBOMs with your CI/CD chain, derive the context of your solution and resolve the resulting requirements can be fully automated at almost no costs by using free and open source tooling. Learn about available options in the article on the “Open Source Compliance Tooling Capability Model”.

However, if you will have to convince your management to care for more compliance or want to learn on how to setup and establish a compliance program, download the slides attached to this post or reach out to one of our consultants.


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.