The SBOM Workbench is a graphical user interface to scan and audit source code using SCANOSS API.
Auditing your source code for license compliance has never been easier. Simply scan your source code directory to find and identify open source components. Generate your SPDX-Lite software bill of materials (SBOM) with the press of a button.
Find prebuilt binaries for all platforms over at: Software Transparency Foundation
- Node.js v14+
- NPM (Node Packages Manager)
We strongly recommend handling your node versions using nvm
npm install --legacy-peer-depsPlease note that you should include the --legacy-peer-deps parameter in the installation command. This is because @mui/styles is not compatible with React 18. You can find more information about this at https://mui.com/system/styles/basics/.
SBOM Workbench uses node-gyp to compile SQLite3 native module. This module uses "node-pre-gyp" to download the prebuilt binary for your platform instead you need build from source. In case it does not exist for your platform, node-gyp going to build it.
Depending on your operating system, you will need prepare the correct environment to run node-gyp: See https://github.com/nodejs/node-gyp#installation
Start the app in the dev environment:
npm startFor live reloading you can use npm run start --watch to run the app using Electronmon. Warning: this tool has a high memory consumption.
To package apps for the local platform:
npm run packageSBOM Workbench is multi-language enabled. To contribute a new language please see our internationalization documentation.
SBOM Workbench support advanced settings. All the configurations needs to be included in the global config file ~/.scanoss/sbom-workbench-settings.json
"SCANNER_CONCURRENCY_LIMIT": "<integer>"
Number of threads to use while scanning (optional - default 5)
"SCANNER_POST_SIZE": "<intenger>"
Number of kilobytes to limit the post to while scanning (optional - default 16)
"SCANNER_TIMEOUT": "<integer>"
Timeout (in seconds) for API communication (optional - default 300)
You might need to specify proxy settings depending on how your network is configured
"PROXY": "<proxy_ip_address>:<proxy_port>"
If your network is using a proxy with SSL interception you can include your certificate in the configuration
"CA_CERT": "<certificate_path>"
You can disable any SSL errors, to do so you can change this option to true
"IGNORE_CERT_ERRORS": true
Local cryptography can be detected by SBOM-Workbench when an API key is set.
A default set of rules is defined for local cryptography detection. However, a custom set of rules can be defined at the root of the project to be scanned with the following name scanoss-crypto-rules.json. A sample file can be found here.
Example structure of the file:
[
{
"algorithm": "md5",
"strength": "128",
"keywords": [
"md5_file",
"md5",
"md5crypt",
"aprcrypt",
"md5_encrypt",
"md5_block_data_order",
"ossl_md5_sha1_",
"MD5_Init"
]
}
]SCANOSS provides a settings file to customize the scanning process. The settings file is a JSON file that contains project information and BOM (Bill of Materials) rules. It allows you to include, remove, or replace components in the BOM before and after scanning.
The scanoss.json object allows you to configure various aspects of the scanning process. Currently, it provides control over which files should be skipped during scanning through the skip property.
The bom section defines rules for modifying the BOM before and after scanning. It contains three main operations:
Rules for adding context when scanning. These rules will be sent to the SCANOSS API meaning they have more chance of being considered part of the resulting scan.
{
"bom": {
"include": [
{
"path": "/path/to/file",
"purl": "pkg:npm/[email protected]",
"comment": "Optional comment"
}
]
}
}
Rules for removing files from results after scanning. These rules will be applied to the results file after scanning. The post processing happens on the client side.
{
"bom": {
"remove": [
{
"path": "/path/to/file",
"purl": "pkg:npm/[email protected]",
"comment": "Optional comment"
}
]
}
}
Rules for replacing components after scanning. These rules will be applied to the results file after scanning. The post processing happens on the client side.
{
"bom": {
"replace": [
{
"path": "/path/to/file",
"purl": "pkg:npm/[email protected]",
"replace_with": "pkg:npm/[email protected]",
"license": "MIT",
"comment": "Optional comment"
}
]
}
}
- Full Match: Requires both PATH and PURL to match. It means the rule will be applied ONLY to the specific file with the matching PURL and PATH.
- Partial Match: Matches based on either:
- PURL only (PATH is optional). It means the rule will be applied to all files with the matching PURL.
Here's a complete example showing all sections:
{
"bom": {
"include": [
{
"path": "src/lib/component.js",
"purl": "pkg:npm/[email protected]",
"comment": "Include lodash dependency"
}
],
"remove": [
{
"purl": "pkg:npm/[email protected]",
"comment": "Remove deprecated package"
}
],
"replace": [
{
"path": "src/utils/helper.js",
"purl": "pkg:npm/[email protected]",
"replace_with": "pkg:npm/[email protected]",
"license": "MIT",
"comment": "Upgrade to newer version"
}
]
}
}
You can add your 'scanoss.json' on the root of your project
The SBOM Workbench includes support for a collaborative workspace, a feature designed to enhance teamwork. View more details here.
SBOM Workbench is an open source project, and we love to receive contributions from our community. There are many ways to contribute. For more information see the Contributing Guide and Code of Conduct.
This project was made using Electron React Boilerplate