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. It scans any container image, filesystem and git repository to detect exposed secrets like passwords, api keys, and tokens

• IaC/CSPM: Terraform, CloudFormation, Docker, Azure ARM, Git & Kubernetes Helm charts misconfigurations

Open

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

Open

You can view details:

Open

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

Open

including all References and Exploits:

Open

SCA Desktop

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

Open

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.

Open

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.

Open

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.

Open

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:

Open

Repositories

SCA Reviewer is able to scan:

• Folders

• Container Images

• Docker Images

• Kubernetes Clusters

• Any Git-compatible repository including GitHub, GitLab, BitBucket, ABAP Git, Azure Repo

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

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

Security Reviewer - Software Composition Analysis (SCA) discovers Vulnerable, Blacklisted, Discontinued by the Community, Deprecated and Obsolete Libraries/Frameworks. This is achieved by continuous monitoring of the following external data sources:

-- Debian Security https://security-tracker.debian.org
-- Linux Security https://linuxsecurity.com/
-- RedHat Security https://access.redhat.com/security
-- Oracle Security Advisory https://www.oracle.com/technetwork/security-advisory
-- SuSe OVAL Descriptions https://www.suse.com/support/security/oval/
-- Ubuntu CVE Tracker https://people.canonical.com/~ubuntu-security/cve/main.html
-- Alpine Linux Security https://alpinelinux.org
-- CentOS Security https://www.centosblog.com/categories/security/
-- Microsoft Security Response Center https://portal.msrc.microsoft.com/en-us/security-guidance
-- OSS Index by Sonatype: https://ossindex.sonatype.org/
-- NVD by NIST: https://www.nist.gov/programs-projects/national-vulnerability-database-nvd
-- VulnDB: https://vuldb.com/
-- Maven Central: https://mvnrepository.com/repos/central (Java, Scala, Kotlin)

-- GitLab Advisories Community (Java)

-- GitLab Advisories Community (C/C++)

-- PHP Security Advisories Database (PHP)

-- GitHub Advisory Database (Composer) (PHP)
-- NuGet Packages: https://www.nuget.org/packages  (.NET)
-- PyPy compatibility: https://bitbucket.org/pypy/compatibility/wiki/Home (Python)

-- GitHub Advisory Database (pip) (Python)

-- Ruby Advisory Database

--  GitHub Advisory Database (RubyGems) 

-- Ecosystem Security Working Group (nodeJS)

-- GitHub Advisory Database (npm)

-- GitHub Advisory Database (Go)

-- The Go Vulnerability Database

-- Open Source Vulnerabilities (crates.io) (Rust)

-- GitHub Advisory Database (Pub) (Dart)

-- GitHub Advisory Database (Erlang)
-- Common Weakness Enumeration (CWE): http://cwe.mitre.org/
-- CVE Details: https://www.cvedetails.com/

-- RetireJS: https://raw.githubusercontent.com/Retirejs/retire.js/master/repository/jsrepository.json

-- Aqualogic Trivy: https://github.com/aquasecurity/trivy-db and https://trivy.dev/v0.18.3/vuln-detection/data-source/ and https://github.com/aquasecurity/defsec/

-- VEX Repository: https://github.com/aquasecurity/vex-repo-spec

-- Open Source Vulnerabilities (OSV): https://osv.dev/

– Open Source Insights: https://docs.deps.dev/api/v3/

VEX Integration

As an OSS developer or maintainer, you may encounter vulnerabilities in the packages your project depends on. These vulnerabilities might be discovered through your own scans or reported by third parties using your OSS project.
While SCA Reviewer strives to minimize false positives, it doesn't perform code graph analysis, which means it can't evaluate exploitability at the code level.
SCA Reviewer utilizes VEX documents from repositories that comply with the VEX Repository Specification. During scanning, SCA Reviewer generates PURLs for discovered packages and searches for matching PURLs in the VEX Repository. If a match is found, the corresponding VEX is utilized.
Consequently, SCA Reviewer won’t report vulnerabilities in cases where:
• The vulnerable function in a dependency is never called in your project.
• The vulnerable code cannot be controlled by an attacker in the context of your project.
This will reduce the false positives.

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