Scanning artefacts - Considerations

Determining the composition of a software may have different reasons. The reason will determine the depths and focus. Thus, make sure that you are clear about your motivation as this will affect time, duration and efforts you will want to invest. Potential motivations could be: 

• Securing your build from vulnerabilities
• Protecting you or your clients from malware
• Understanding legal situation / compliance
• Managing export controls or evaluating quantum security

In addition to the different motivations you may have different information available for analysis. Given you have a 3rd party library, you may have access to the sources or not, while you most likely have access to your own sources code. Sometimes you want see what the contents of an image or a virtual machine are. In other cases you have just a list of packages.

Finally the situation will have an impact. Given are about to buy a 3rd party solution and want to do your due diligence you may be willing to spend more effort and time than while being a developer committing the sources to your repository. 

All these factors will impact the wanted result, the methods applied and the depth of the investigations. Please take this in consideration, when thinking about your scanning approach.

Securing your build from vulnerabilities

There are two types of scans you may be interested in when aiming for this goal:

1. Scan your code for programming issues or code smells that may lead to runtime problems by using so called Static Application Security Testing (SAST) tools.  
2. Scan the packages and / or files fed in the build for known vulnerabilities

While the SAST scans evaluate the programmed code itself for programming issues, e.g. by verifying compliance with programming best practices, quality challenges, performance issues or even programming mistakes, the scanning for known vulnerabilities happens on a more abstract level by comparing the name of the component with collected knowledge about already identified and communicated vulnerabilities of these components.

It is most unlikely that you will find private package names refrred to in a CVE, since only you will have access to your own product sources. A third party may find vulnerabilities in your solution. If this will be the case, they will most likely assign the CVE to your solutions name, not any of your internal package names. 

However, TrustSource supports collecting results from SAST scanning. It is possible to push SARIF-formatted findings into the Software-Quality API and add the findings for further release processing and reporting. SARIF stands for Security Analysis Result Interchange Format and has established itself as a well supported standard for this sort of data. 

All other analysis, whether package or file, can be executed with any sort of scanner, preferably our ts-scan, but we also have an reporter implemented in ORT or can receive third party SBOM data from any source through CycloneDX or SPDX uploads.

All SBOMs will be processed when entering the platform and verified agains our Vulnerability Lake information. If any known vulnerabilities will be found, they will be assigned to the corresponding component automatically. 

Protecting your clients from malware

When using 3rd party software or any kind of software solutions, you do not have the sources available, you should be alerted. All you have not build may carry malware. To identify malware in binaries YARA is a suitable tool. TrustSource's ts-scan includes a yara lib allowing you to scan these 3rd party components for known malware indicators.

To learn more, read the yara documentation or see the ts-scan documentation on how to execute the malware scanning. As of now, malware reports will be available in the ts-scan output only. The main reason for this is, that we would advise to remove all malware immediately and clean the code base from any code stemming from the related sources. IDENTIFIED MALWARE IS A AN INHERENT RISK AND NEEDS TO BE REMOVED IMMEDIATELY.
We plan to introduce markers for the compliance manager, so that they may get aware of threats. But we do not plan to provide deeper handling support for identified malware. This seems to be out of scope for our current focus. 

Understanding legal situation / compliance

Another use case may be the scanning for license indications. Generally every piece of software falls under the copyright. This is a special right since it automatically will come into existence by creating something. It does not need to be registered like a patent for example. And it grants its owner rights to deny others use, distribution or even modification of the whatever it covers. Thus, every piece of code, every snippet, that ever has been published somewhere is under copyright protection.

Owners of the copyright may do whatever they like with it. As long as they do nothing, all use, distribution etc. remains forbidden. Thus, even a published code snipped is not free for use, especially not in a commercial context. Therefore it is essential to assess the complete dependency chain of your sources for potential licenses contained.

This is done by collecting all sources from the package management systems and scanning them on file base. Since this can be cumbersome and may take a hell of work, TrustSource offers different automation scenarios to support you on this task as well as a legal engine to evaluate the findings. See Managing Compliance Risk for more details on the legal compliance topic.

To learn how to use TrustSource DeepScan, go to 

• Scanning on file level using ts-deepscan or
• Use DeepScan at scale 

The latter is a containerised implementation that you may use to automate scanning of complete SBOMs  in depth. TrustSource will evaluate all given components, pull them either from the registry or identify the repository and execute the scan. Depending on your preferences, you may execute the scans on the TrustSource platform or within your private VPC. 

Managing export controls or evaluating quantum security

Export Controls

Whenever your software product is crossing a border, you may face import or export control regulations. Even within the European union, e.g. when importing to France, you are obliged to enumerate the encryption algorithms used. Thus, you do good in identifying and declaring the encryption algorithms in your solution. To achieve this, you need to scan all sources or make use of pre-scanned data.  

TrustSource supports you with this management task. See Managing export controls for more details on how TrustSource can support you in declaring used crypto algorithms. 

Quantum Safety

Quantum computing is around the corner. The power of quantum computers will erode the security delivered by many encryption algorithms. Depending on structure and bit size, some of today's known secure algorithms will become insecure. The US NIST conducted a study on the quantum safety of algorithms and tendered the development of quantum safe encryption algorithms. Meanwhile three algorithms were declared as quantum safe. See this announcement for more details.

However, depending on the upcoming development in this area, it is beneficial to keep track of the algorithms used in your software or the components your software uses. With our ts-scan / ts-deepscan tools and/or our SCANOSS integration we are able to determine the algorithms used in your solution. In the INTERNAL > ANALYSIS > ALGORITHMS REPORT you may search your portfolio for the appearance of a specific algorithm.