Page Comparison

Security Reviewer – Software Composition Analysis (SCA) identifies project dependencies on 3^rd-parties components directly inside your SDLC, as Jenkins Plugin, Bamboo Plugin or using the CLI Interface. Security Reviewer – Software Composition Analysis is able to identify Java, C/C++, Ruby, Groovy, Perl, PHP, JavaScript, TypeScript, 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.

...

**Security Reviewer’s SCA unique features

Anchor
packages packages

Package Managers

SCA supports the following Package Managers:

• NPM 
• Packrat
• Docker Package Manager
• Nuget
• Maven (Apache)
• Ant (Apache)
• Gradle 
• RubyGems
• Pip (Pypi)
• Gomod
• GoDep
• CocoaPods 
• SWIFT Package Manager
• PHP Composer
• SBT
• Python Package Metadata
• Python Package Distribution 
• Anaconda
• Rust Cargo
• CPAN
• Akku.scm
• CRAN
• Leiningen
• LuaRocks
• PEAR
• au3pm

...

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.

OSS Component Inventory – 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.

I support the following SBOM standards:

• CycloneDX
• SPDX
• SWID

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.

...

COPYRIGHT (C) 2014-2020 SECURITY REVIEWER SRL. ALL RIGHTS RESERVED.