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.
Questions? Stop searching further, just reach out and get answers!
New Release v1.6 available
We are happy to announce availability of v1.6! Also v1.6 comes with massive new features, focused on process improvements. Read more:
New Features
- Vulnerability-alert - It took us quiet a bit, to get the matching towards a reasonable quality, but we manged it after all. You will now get notified by TrustSource, if new vulnerabilities appear for components that you are using in your most recent build.
- "Action required" items in inbox - Especially for our compliance managers we provide an in box on the dashboard listing all open approval requests. This allows you to immediately see, where action is required.
- Dependency graph - The so called dependency list is a flat list of all components entering the project even through transitive dependencies. To allow a better understanding of the impact this component has, the graphical display allows to actually _see_ the position within the dependency graph. You may modify the appearance and expand or shrink single nodes for better visibility.
Improvements
- Improve rule sets - Based on customer feedback and own research, we were able to improve the analysis results of several licenses.
- Improved maven Plugin - The maven plugin has been extended to support the check functionality allowing to verify components on dev-desktop without the need to push a scan.
- Improved Jenkins Plugin - Also the Jenkins plugin has been extended to use the transient version of the check-API.
Fixes
- Add name in register form - Changing your name after having been invited while login in the first time is possible now.
- Propagate deletion of all members - Changing members of a project respectively a all modules within a project at once has been introduced since a while. But it has not been recognized that the propagation of an empty list does not immediately take effect. This has been fixed now.
Our next version v1.7 will focus on security and extend the login capabilities. We will introduce alternative ways to authenticate and simplify corporate SSO. The given role model has been reviewed and will be tuned towards more flexibility.
If you want to get an overview or some insights in to our roadmap, feel free contacting our sales team! They will be happy presenting you the upcoming steps.
If you feel like there should be some features you do not see on the horizon, please let us know! Our business development or your engagement manager will be happy to hear about your ambitions.
How TrustSource supports OpenChain compliance
OpenChain in a nutshell
OpenChain is LinuxFoundation project with the goal to improve trust in open source software. To achieve this, OpenChain identified a set of requirements each organization should cope with to become a valuable and trustful open source user and producer.
„Open Source components delivered by a OpenChain certified organization you may trust!“
The OpenChain specification knows six goals. Four of them focus on the organization of Open Source usage inside the company while the fifth goal addresses the contributions to open source projects.
Finally the sixth goal requests to take responsibility and declare conformity with the OpenChain rules by getting the organization certified. The following will outline the goals and show how TrustSource supports you in achieving the goals.
G1: Know your responsibilities
In a first step it is relevant to know and understand tasks and obligations within your organization. This typically results in an Open Source Policy, a manual on how to handle open source software correctly. Such a policy describes roles and responsibilities and the processes and procedures how to deal with the different use cases.
TrustSource provides pre-defined standard policies and procedures for your purpose. You may want to use and adopt them for your own purposes.
OpenChain requires you not only to provide a policy but also to ensure that your staff is aware of that policy, so that it can be assumed the policy will take effect. To cope with that requirement, a documented procedure is required to proof that at minimum 85% of staff have knowledge of it.
Starting from v1.7 TrustSource comes with a learning management system including a set of online trainings and video materials, that allow to foster the spread of OpenChain behavior and knowledge including learning success metrics.
In addition it is required that procedures to identify and catalogue the applied open source components including the determination of the corresponding rights and obligations are defined.
TrustSource provides a wizard to document the project context which is essential to derive the obligations. Changes in the context, e.g. a changed commercial model will be documented and then new obligations may be determined.
G2: Assign Responsibilities
Unfortunately the current situation concerning documentation in the open source space leave room for improvement. Thus, it is most likely to that questions by downstream users may occur concerning options of usage or contained components. To answer these questions in a professional manner, the specification requires to assign a „FOSS-liaison“, that has to be publicly announced.
The specification requires you to standardize and organize the communication following a clearly defined set of rules. This is especially relevant in case of a legal dispute.
With TrustSource you may delegate this task. You will create a mail-alias and all incoming requests will be routed to our TrustSource help desk. They will be structured, documented and worked on based on a procedure defined together with you.
To cope with the requirements of this process, it is essential that sufficient legal expertise is available for this process. The expertise may be internal or external.
G3: Review and approve FOSS
The third goal focusses on the documentation of generated software respectively the used artifacts. A process how to create the bill of materials (BoM) should be qualified and documented. Where „qualified“ addresses that the process should be suitable to really identify all used components.
This should not happen once only. It shall happen on a continuous base. Especially in continuous deployment environments an extraordinary obligation on the actuality and the need to archive older versions of BoMs arises. A pure manual approach is almost not imaginable anymore.
TrustSource may supports this optimal. Due to the integration with build tools, you have the most recent information available after each build. Each single version may be saved and archived. The „freeze release“ mechanism allows to export specific versions via API or SPDX. Thus allowing you to to provide the most recent BoM with one click.
The specification does not define any requirements concern the contents of a BoM. But within the Linux Foundation the SPDX working group - Software Package Data Exchange - has created a specification and software as well as human readable format for the license documentation. It does not solve the problem in total but provides a sound basis for a technical documentation.
However, the provisioning of a BoM does not make a fully compliant treatment of FOSS. Depending on the use case the clauses of the meanwhile more than 396 known licenses may trigger different obligations. Mean of use, commercialization type or form of distribution and other parameters will impact the identification of the resulting obligations.
This is especially important due to the fact that some of the licenses will terminate the right of use if the obligations are not met. In other words: you will not have the right to use the component. Use of a component without right is a criminal offense.
Therefor OpenChain requires a legal examination, that discovers all obligations concerning the respective use case, to ensure a legally compliant application for that particular scenario.
Here TrustSource presents one of its dominant unique capabilities: Due to the knowledge of the conditions, rights and obligations of several hundred licenses and a structured capturing of the legal context, the TrustSource legal engine may resolve the conditions of the application completely automated and case specific. As a result a list with all required obligations will be provided to the project staff.
G4: Deliver FOSS artifacts
The forth goal aims at the delivery of the created compliance artifacts together with the Software in a single dispatch.
TrustSource supports this by providing an export of an SPDX document per module or project. In a next version a complete notice file will be generated and delivered. All this can be done within the application or through the API.
Another legal requirement is audit acceptability. The means older versions must be available until it is ensured that no old version will be in use anymore. This is required to retain the ability of answering questions concerning older versions based on a solid documentation.
TrustSource stores the complete history of information and thus allows to invoke data of older versions anytime.
On this basis it is always possible to identify which components habe been used in what module and under which circumstances (legal context). On the one hand documentation makes vulnerable, because it also documents what has not been made. On the other hand documentation also creates security, because it may be confirmed that all possible actions have been taken to achieve legal compliance. Such an approach is well suited to discover potentially missing aspects or actions.
G5: Understand Community
Open source should not be a one way street. You should not only take form the community, but understand that you are invited to support and return. This typically happens through participation in open source projects, so called „contributions“.
Depending on the engagement a contribution may reach from occasional code fixes up to leadership of projects. In some cases individuals contribute on occasional basis only, in other cases complete teams are dedicated on the development of specific modules or complete projects. Depending on its input the influence on the project grows. Some companies even create their own open source initiatives.
Whether occasionally or targeted, whatever form will be selected, the commitment itself needs to be clearly regulated. This comprises questions concerning the work time versus spare time design, claims or rights concerning the created software as well as the potential claims against the company arising from provisioning the contributions.
The fifth goal addresses this form of giving-back, the contributions to the open source community. It requires that a policy exists, that clarifies the handling of such contributions. As for the policy of open source use also this policy must not only exist but being distributed and well known.
To present the policy on open source contributions the same TrustSource mechanisms as for the support of G1 may be used. TrustSource also provides a sample policy as baseline that can be used.
It is possible that the policy you will choose prohibits contribution to open source projects. In this case only the prohibition needs to be propagated. Based on our experience, a strict ban is not a suitable answer. If you are using open source seriously, you must accept that you will come across errors. Not being Abel to repair them based on a policy forbidding the contribution would be negligent.
Such contributions also require a governance procedure. Ideally it does not differ much from the governance process for the own products. This will easy understanding as well as handling for all participants.
TrustSource provides a uniform platform for both use cases providing a broad set of tools for the process support.
G6: certify adherence with OC requirements
Goal number six requests the willingness of the organization to certify the adherence to the OpenChain goals one to five, respectively the according requirements. This is currently possible using a self audit. Th website of the openChain project offers a questionnaire and OpenChain partner organizations support you in implementing the required organizational changes.
TrustSource provides the most suitable platform to ensure process conformity. This is well known and understood with all involved parties and therefor will support all further clarifications (e.g. upcoming certifications, when OpenChain advances from specification to an official Standard)
Summary
In conclusion it can be said that most likely OpenChain conformity requires your organization to change processes and mindsets. This always is a time consuming effort, requiring dedication and focus. But an enterprise wide application of TrustSource will reduce a huge part of the complexity and efforts the transformation towards OpenChain conformity will cost.
We suggest to precisely define the starting scope. It might be a good idea not to start local instead global, focussing one entity first, creating a success story and transfer these experiences accordingly. Typically good stories sell well and the spread will ease.
This is approach also is supported by TrustSource. The Multi-Entity-feature allows to differentiate several entities or business areas within one account. It will be possible to manage them together but operate them on an isolated base. They may have specific policies or black- and whitelists, but operate one LDAP for example.
Even companies or business units that use already a scanning tool, TrustSource may leave the freedom to operate at their own. The option to transfer scanning results to the TrustSource API respectively to import SPDX-documents of single modules, allows to use TrustSource as the linking platform, to ensure a sound and conform legal and security analysis as well as harmonized delivery platform. Thus allowing to ensure process conformity and harmonized governance.
TrustSource Version 1.4 released
We are proud to announce the release of v1.4!
It took some sweat, blood and a lot of testing, but now v 1.4 has been successfully released. There is a basket of new features available that will make your work much more efficient:
- the new inbox will collect all communication so you will not miss anything anymore.
- A vulnerability feed will alert you about latest changes or upcoming issues.
- CVSS-Scores and attack vector information allow a faster identification of critical issues
- Extended Obligations report - using the new obligation report it will be possible to jump directly to the associated component, so that you may work with it without switching between the two view. Also the report is now available from within the list views.
- Suitability checks - to further support SHIFT LEFT, we have created a feature which allows you to verify the suitability of not yet built in licenses and/or components. This allows developers to verify the consequences of using a product even before it will be added to the code base. The functionality also is available over the API.
- Private licenses - You are now able to create private license keys. So you may also manage your own licenses
Also we have added some improvements and Fixes. For example we were able to discover a matching problem in our vulnerability scanner.
Additional information can be found here.