...

Web App

You can view details:

Image Removed

And drill-down to the single issue, a Fixed version is also suggested:

Image Removed

including all References and Exploits:

Image Removed

SCA Desktop

Image Removed

:

Image Added

And drill-down to the single issue, a Fixed version is also suggested:

Image Added

including all References and Exploits:

Image Added

SCA Desktop

Image Added

Application Architecture

SCA Reviewer is able to create a Design Structure Matrix (DSM) by reading the compiled code (JAR, DLL binaries) and/or related UML diagrams.

DSM-Design Structure Matrix

An example of SCA Reviewer’s automatically generated Design Structure Matrix is shown below:

Image Added

A Design Structure Matrix consists of a matrix to visualize Dependencies of hierarchically organized elements and a set of algorithms which can be applied on the matrix to sort the elements in order to discover layering.

A Design Structure Matrix (DSM) is made by two parts

• A matrix to visualize dependencies

• Algorithms which can be applied on the matrix to discover e.g. layering in the software.

The DSM consists of a matrix with the same elements in the rows and columns

• The hierarchy of packages and elements is visible on the left.

• The relations between the elements are shown in the cells.

In a DSM, the hierarchy can also be folded in whole or in part. The relational strengths of the collapsed cells are simply combined. As a result, the DSM will become more compact, but will still remain correct in terms of content.

In this way it is possible to display a system with thousands of elements and still keep the overview.

DSM Architectural Discovery

By applying a partitioning algorithm on the DSM, the layering of the software will be discovered by SCA Reviewer during the binary analysis. Such an algorithm tries to reorder the DSM in such a way that as many relationships as possible come under the diagonal.

After partioning elements with many inbound relationships (providers) have shifted to the bottom, while the elements with many outgoing relationships (consumers) have shifted to the top.

Cyclic relations can be easily spotted, because the type of relations remain above the diagonal.

DSM Assist in refactoring (Desktop only)

A DSM can be used to improve the dependency structure. One can think of:

• Removing cyclic dependencies.

• Improving the cohesiveness of a component by move elements to other component were the have stronger relations.

In the matrix we can move an element to another component or layer, combine it with other elements or split and then recalculate all dependencies to see if this yields a better dependency structure.

After recalculating the dependencies it can be seen that the cyclical relationship between the presentation and application layer has disappeared.

The advantages of such an impact analysis are particularly evident in improvement scenarios that take place at the architectural level and thus affect multiple components. Without the use of a DSM, such analysis are unreliable, because the intended and the actual software architecture often do not match.

DSM-Supported Languages

• .NET: C# and vb.NET Assembly

• JAVA, Clojure, Groovy, Kotlin JAR files

• C/C++ Source and Header files

• UML in Sparx System Enterprise Architect format

• DSM Files from 3rd-party tools (for example ArgoUML)

• DSI Model. Two DSI Model files can be compared

A DSI Model file is a way to import 3rd-party analyzer’s DSM output to SCA Reviewer.. A DSI file represent an analyzer’s output. Each code analyzer must export its DSM results to DSI file. To ensure that the SCA Reviewer can import this file, it must conform the DSI file XSD schema below:

CI/CD plugin

Software Composition Analysis Jenkins and Bamboo native plugins and CLI Interface (test on many CI/CD platforms) provide a 360 degrees solution covering all your DevOps needs. 3rd-party libraries can be analyzed (Open Source Analysis-OSA) using a shared folder located on Network File System (NFS), a Nexus Repository or JFrog Artifactory for discovering Vulnerable Libraries, Vulnerable Frameworks, Blacklisted/ Discontinued/ Outdated / Obsolete/ Deprecated libraries and frameworks. Legal issues like: Blacklisted Licenses, Licenses Conflict, No-licensed libraries, Suspicious (modified) licenses and Poor-man Copyrights are fully-detected from the tool.

...

**Security Reviewer’s SCA unique features

Package Managers

SCA supports several Package Managers.

...

Open source software (OSS) or free and open source software (FOSS) is computer software for which the human-readable source code is made available to the public under license terms permitting the study, modification, and distribution of the software to anyone and for any purpose. The “free” of FOSS refers to the liberty to study, modify and distribute – it does not require that it be made available without cost. The fact that OSS and FOSS can be studied, modified and distributed has created open source communities in which developers continually modify, enhance and troubleshoot the software and contribute these changes back to the community. As a result, the vast majority of enterprises use OSS components in their own proprietary software applications. Doing so brings a host of benefits, including accelerating development time, reducing costs and producing more stable and secure code. While the use of OSS has seen a significant increase over the last 10 years, compliance with the OSS license terms often has not kept up. Many users who download an OSS component may not appreciate that doing so obligates them to abide by a specific software license associated with its use. Unlike commercial software applications or software-as-a-service (SaaS) offerings, click-through acceptance of OSS license terms and conditions are not typically required to gain access to the OSS code. Instead, the license terms are merely referenced on the download site or embedded in a text file within the download package. While there are hundreds of different OSS licenses, they can be broken down into a small subset of license types. They range from: the most permissive licenses, such as Berkley Software Distribution (BSD), MIT and Apache, which permit almost any use of the OSS component and simply limit warranties and disclaim liabilities; to weakly protective licenses, such as the Mozilla Public License (MPL); to the most restrictive “copyleft”-style licenses, such as the GNU General Public License (GPL) or the GNU Lesser General Public License (LGPL). Copyleft licenses can require that any software with which they are packaged must also be distributed under the same copyleft license terms. Use of the more restrictive licenses can therefore have a viral effect, requiring disclosure of, and permitting third parties to use, the source code of one’s own proprietary code. Further, different licenses impose different requirements on modification and distribution of the OSS component. For example, the LGPL license requires users to distribute the source code (or otherwise make it available) if they distribute the OSS component to third parties. Other license types require that users identify changes they have made to the OSS component in a header or other text file included in the distribution package.

...

...

Image Removed

The consequences of breach of a commercial software license are relatively clear: the commercial software vendor can sue for damages resulting from the breach of the license terms. But in the OSS context, what are the real risks as a practical matter? Technically, the copyright owners of an OSS component could sue for infringement and/or breach of the OSS license terms. 

...

The most significant effort with any OSS audit is inventorying existing use of OSS components. That inventory can occur manually by interviewing each developer and asking them to identify the OSS components they have downloaded and used in the development process. For long standing development teams that have never been through this exercise, that can be a difficult, if not impossible, task. While it may be easy to remember OSS components that were recently incorporated into a development project, that may not be true for software developed years ago. Alternatively, third party software products exist that can automate the inventory process.

Image RemovedImage Added

I It support the following SBOM standards:

• CycloneDX
• SPDX
• SWIDSARIF
• GitHub

Security Reviewer – Composition Analysis module can scan your software code and, using sophisticated pattern matching algorithms, identify the various OSS components present in your software code. While some vendors require that source code be uploaded to their cloud environment for processing, Security Reviewer can operate entirely on-premises and using hashed values of the source code to avoid the risk of source code disclosure outside the enterprise. Unless an enterprise is in the early stages of its development process or has kept an accurate running list of OSS components, the automated process will be far more accurate and complete. Further, in more and more significant financing and M&A transactions, the investors or acquirers themselves are using such automated tools as part of the due diligence process, so to simply assume that the manual inventory process will be “good enough” may be misguided. Representing compliance and possession of an accurate list of OSS components, only to later find out from a counterparty using an automated tool that this is not the case, can be just as bad, if not worse, than not having completed an audit at all.Image Removed

Image Added

OSS License Inventory

Whether done manually or via an automated process, the first step is to complete an accurate and complete inventory of each OSS component present in the software. Next, one must identify the license type associated with each OSS component. If the inventory was done manually, then this will require a search of the source website of each OSS component to determine the applicable license type. If the inventory was automated, Security Reviewer automated tool identifies the license type for you, based on its extensive database of OSS components. While there are hundreds of different OSS license types, most OSS inventories tend to consist of only a few dozen license types.Image Removed

• Use Characteristics Inventory

• Next, for certain OSS license types, the enterprise must determine how the OSS component is used.

These use characteristics typically include:

...

...