Many applications incorporate external open source and third-party components that enable developers to build new functionality quickly and efficiently.

But while the use of open source components has many benefits, it also introduces risk.

A Universal tool

Security Reviewer – Software Composition Analysis (SCA Reviewer) analyzes your application software, identifies project dependencies on 3^rd-parties components,

and builds a components inventory that lets you track any external piece of code that could be part of your application, directly inside your SDLC, as Jenkins Plugin, GitLab Runner, GitHub Action or integrating to your SecDevOps by using the CLI Interface.

Furher, SCA Reviewer is able to detect:

• Vulnerable Libraries
• Vulnerable Frameworks
• Vulnerable Containers
• Vulnerable Repositories
• Discontinued Libraries (abandoned by the community)
• Obsolete Libraries
• Poor Man copyrights
• Secrets
• IoC/CSPM: Terraform, CloudFormation, Docker, Azure ARM, Git & Kubernetes Helm charts misconfigurations

During Coding

In the first step of the Secure Application Life Cycle, developers will assemble the logic of the application using a mix of open source packages and their own custom code.

Open source packages will require Software Composition Analysis (SCA) to identify the open source packages and vulnerabilities inside.

This analysis is also key to prevent the exposure of secrets by scanning for configuration issues, hard-coded secrets, logs, binaries, and other ways in which secrets could be leaked.

Into the build

Both custom code and open source components must be committed to a Git repository as well as a CI/CD tool.

This then kicks off the build pipeline. One of the jobs of the CI/CD tool is often to build a container image that will live in a repository, which itself lives inside a registry.

The resulting image or repo/folder will need to be scanned for vulnerabilities. Generating a software bill of materials (SBOM),

gives you full visibility into the risks of the applicable third-party libraries and components used in your application, including tracking which software licenses are being used.

Deployment

Infrastructure-as-code (IaC) templates specify the physical resources for your cloud deployment in code, allowing you to ensure that your actual deployment is as originally intended.

And the deployment itself, if you have many containers, will be managed by an orchestrator such as Kubernetes (k8s) or remain a group of Docker Images.

The IaC templates must be scanned for misconfigurations so issues can be solved early in the code versus later in production.

Docker and Kubernetes also require appropriate configurations, so flagging misconfigurations in Docker/Kubernetes is key to reducing your attack surface.

During Running

Kubernetes clusters will generally be run on cloud services.

The Kubernetes clusters must be scanned again in runtime for vulnerabilities, and the actual cloud accounts also need to be scanned for misconfigurations.

In the shared security model with cloud providers, it’s the customer’s responsibility to harden the cloud environment in which the applications are run.

One tool to rule them all

A universal scanner like SCA Reviewer means using just one tool in place of the eight tools listed in the scenario above, bringing about the following changes for application security and developer teams:

• A single view of your risk is easier to create.
  SCA Reviewer either provides its own reporting UI or integrates with another reporting tool for a single view of truth.

• You can validate and track the progress of remediation and internal educational programs.
  For example, an engineer can use SCA Reviewer to do testing on their local machine, DevOps can use it to scan their CI/CD pipeline, and a cluster admin can scan running workloads. This makes it possible to see which of the vulnerabilities that were present in the engineer’s initial testing made it all the way through to runtime.

• You can fix issues earlier with consistent checks across the life cycle.
  For example, you could use the same ruleset that looks for IaC misconfigurations as misconfigurations in your cloud accounts. If you find a misconfiguration in a cloud account for a running workload, you can be assured that there’s an IaC rule to flag the same issue earlier in the life cycle.

• It’s easier to get started with and scale security across teams.
  Learning one tool requires much fewer people than learning eight tools. Context-shifting between tools is also less of an issue. Further, the learning curve will be less steep for one tool that covers a range of elements versus adding point solutions one by one over time. Imagine a scenario in which you’d automatically get the same results as you would from multiple scanners without having to know about them or configure them. That should be the experience of a universal scanner.

Technologies

SCA Reviewer is provided as:

• Web App, delivered as a group of Docker Images
• SCA Desktop. .NET Core app for Windows, Linux and macOS
• CI/CD plugin. Native Jenkins plugin, GitLab Runner, GitHub Action . High experienced CI/CD integrations via CLI 
• CLI 

Web App

You can view details:

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

including all References and Exploits:

SCA Desktop

Result Summary will show a summary of Vulnerabilities’ Categories discovered in your Deployment Kit

Software Bill Of Material (SBOM)

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.

It support the following SBOM standards:

• CycloneDX
• SPDX
• SARIF
• GitHub

Findings

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.

Application Architecture

SCA Reviewer Desktop 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:

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.

Command Line Interface (CLI)

SCA Reviewer offers a very simple CLI interface, suitable for your preferred DevOps integration,for Windows, Linux and macOS.

Two command are available: SCACheck (for local scan) and TRSCAScan (for remote scan, running on Team Reviewer server), having the same arguments:

Analyzers

SCA Reviewer is able to identify Java, C/C++, Ruby, Groovy, Perl, PHP, JavaScript, TypeScript, nodeJS, Python, Rust, Scala, GO, R, Kotlin, Clojure, ErLang, Shell, PowerShell, LUA and Auto-IT components along with .NET assemblies and Objective-C, Objective-C++, SWIFT support. Once identified, SCA will automatically determine if those components have known, publicly disclosed, vulnerabilities as well as licenses-related issues.

SCA includes the following analyzers:

**Security Reviewer’s SCA unique features

Package Managers

SCA supports several Package Managers.

All Solutions you need

Security Reviewer offers various solutions for Software Composition Analysis:

• As Security Reviewer integrated module. After Static Analysis completion, a complete application dependency report on 3rd-party libraries/frameworks will be available
• As Jenkins plugin, GitLab Runner, or GitHub Action, it features the ability to perform a Software Composition Analysis build and later view results post build. The SCA Plugin is built using same features that the static analysis plugins offer, including thresholds, charts and the ability to view vulnerability and license information should a dependency have one identified
• Full-tested integrations with Azure DevOps, Travis CI, Circle CI, TeamCity, CodEnvy, Chef, Ansible, Nexus, AnthillPro, GoCD, among others. Those dependencies can be scan inside your preferred Container System like Docker, Kubernetes, OpenShift, MesoSphere, Rancher, Quay, Singularity, Pivotal CF and any container compliant to APPC specifications

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.

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. 

While these suits have been filed, given the fact that a particular OSS component could easily have hundreds of contributors and hence hundreds of copyright owners without a common voice, litigation is not typical. Instead, compliance with OSS license terms becomes critical in the context of many important transactions, such as financing and mergers and acquisition transactions. A sophisticated investor or acquirer in any significant financing or M&A (Merge & Acquisition) transaction will always demand a representation and warranty of OSS compliance. Non-compliance creates potential ambiguity around ownership of a material asset and potential post-closing costs of compliance. That ambiguity and associated remediation costs may affect not only the value of the transaction, but also the decision whether to proceed with the transaction at all. How an enterprise manages its use of OSS can speak volumes as to its policies, procedures, structure and culture, all of which are relevant to successful transaction due diligence. To avoid the potential for OSS issues to negatively impact an important transaction, enterprises must develop and follow processes to inventory their use of OSS components, analyze their degree of compliance and remediate any non-compliance long before the term sheet stage of any transaction. Before any enterprise commences an OSS audit, it needs to educate both developers and management on the benefits and risks of incorporating OSS into their proprietary software applications. Asking individuals to participate in an audit where their prior actions could come under a microscope will be far more successful if they understand and appreciate the importance of the outcome.

External Data Sources

VEX Integration

Awesome Repos

SCA uses the following community-driven 'Awesome' lists too:
-- Awesome Java https://github.com/akullpp/awesome-java
-- Awesome .NET https://github.com/quozd/awesome-dotnet
-- Awesome Android https://github.com/JStumpp/awesome-android
-- Awesome C libraries https://github.com/kozross/awesome-c
-- Awesome C++ https://github.com/fffaraz/awesome-cpp
-- Awesome JavaScript https://github.com/sorrycc/awesome-javascript
-- Awesome TypeScript https://github.com/dzharii/awesome-typescript
-- Awesome Python https://awesome-python.com/ and https://pythonawesome.com
-- Awesome Ruby https://github.com/markets/awesome-ruby
-- Awesome Scala https://github.com/lauris/awesome-scala
-- Awesome GO https://github.com/avelino/awesome-go
-- Awesome PHP https://github.com/ziadoz/awesome-php
-- Awesome Swift https://github.com/matteocrippa/awesome-swift
-- Awesome iOS https://github.com/vsouza/awesome-ios
-- Awesome Kotlin https://github.com/KotlinBy/awesome-kotlin
-- Awesome Groovy libs https://github.com/kdabir/awesome-groovy
-- Awesome shell scripts https://github.com/alebcay/awesome-shell
-- Awesome R https://awesome-r.com
-- Awesome PowerShell https://github.com/janikvonrotz/awesome-powershell
-- Awesome Auto-It https://github.com/J2TeaM/awesome-AutoIt
-- Awesome LUA https://github.com/LewisJEllis/awesome-lua
-- Awesome Clojure https://github.com/razum2um/awesome-clojure
-- Awesome Erlang https://github.com/drobakowski/awesome-erlang
-- Awesome Rust https://github.com/rust-unofficial/awesome-rust

libhunt Service

Further, SCA uses the libHunt service:
-- Java https://java.libhunt.com/
-- .NET https://dotnet.libhunt.com
-- Android https://android.libhunt.com/
-- C/C++ https://cpp.libhunt.com/
-- JavaScript/TypeScript https://js.libhunt.com/
-- Python https://python.libhunt.com
-- Ruby/Groovy https://ruby.libhunt.com/
-- Scala https://scala.libhunt.com/
-- GO https://go.libhunt.com/
-- PHP https://php.libhunt.com/
-- Swift https://swift.libhunt.com/
-- iOS https://ios.libhunt.com/
-- Kotlin https://kotlin.libhunt.com/
-- Rust https://rust.libhunt.com/ 

License Management