From 055811cdf8e8a83ee38c3523bc683d6539f916f1 Mon Sep 17 00:00:00 2001 From: Michael Herzog Date: Fri, 29 May 2026 11:08:25 -0700 Subject: [PATCH 1/2] Editorial updates Corrected some links Updated getting started pages to remove multiple links to aboutcode projects (i.e., one link per page Signed-off-by: Michael Herzog --- website/docs/getting_started/cravex.md | 125 ++++++++++++------ .../getting_started/license-compliance.md | 106 +++++++++------ .../software-identification.md | 44 +++--- .../docs/getting_started/software-security.md | 36 ++--- 4 files changed, 195 insertions(+), 116 deletions(-) diff --git a/website/docs/getting_started/cravex.md b/website/docs/getting_started/cravex.md index 9008d42..dff28b7 100644 --- a/website/docs/getting_started/cravex.md +++ b/website/docs/getting_started/cravex.md @@ -2,29 +2,43 @@ The EU’s Cyber Resilience Act (CRA) aims to enhance the cybersecurity of products with digital elements, ensuring that hardware and software sold in -the EU are designed with strong security measures. It stipulates that manufacturers remain responsible for cybersecurity throughout a product lifecycle. +the EU are designed with strong security measures. It stipulates that +manufacturers remain responsible for cybersecurity throughout a product lifecycle. -The AboutCode [CRAVEX](https://nlnet.nl/project/CRAVEX/#) (Cyber Resilience Application for Vulnerability Exploitability Exchange) project was designed -to make it easier for any organization to efficiently comply with the emerging CRA and other regulatory requirements and improve its overall security posture. A primary goal for **CRAVEX** is to provide an open source -solution for small- and medium-size enterprises (SMEs). +The [CRAVEX](https://nlnet.nl/project/CRAVEX/#) (Cyber Resilience Application +for Vulnerability Exploitability Exchange) project was designed to make it +easier for any organization to efficiently comply with the emerging CRA and +other regulatory requirements and improve its overall security posture. A +primary goal for **CRAVEX** is to provide an open source solution for small- +and medium-size enterprises (SMEs). ## Key CRA Provisions At a summary level, the key CRA provisions include: -- **Cybersecurity**: Manufacturers must ensure that products with digital elements meet essential cybersecurity requirements, including risk +- **Cybersecurity**: Manufacturers must ensure that products with digital +elements meet essential cybersecurity requirements, including risk assessments, security-by-design practices, and vulnerability management. -- **Vulnerability Reporting**: Manufacturers are required to report any actively exploited vulnerabilities to the European Union Agency for Cybersecurity (ENISA) within 24 hours. -- **Security Updates**: Manufacturers must provide timely and effective security updates to address vulnerabilities. -- **Documentation**: Manufacturers must provide documentation and certification to demonstrate compliance with CRA requirements. +- **Vulnerability Reporting**: Manufacturers are required to report any +actively exploited vulnerabilities to the European Union Agency for +Cybersecurity (ENISA) within 24 hours. +- **Security Updates**: Manufacturers must provide timely and effective +security updates to address vulnerabilities. +- **Documentation**: Manufacturers must provide documentation and +certification to demonstrate compliance with CRA requirements. - **Enforcement**: The CRA includes penalties for non-compliance. The most challenging CRA requirements for most organizations are those for -timely reporting and remediation of actively exploited vulnerabilities in a product. At a minimum this will require organizations to: +timely reporting and remediation of actively exploited vulnerabilities in a +product. At a minimum this will require organizations to: -- Create and maintain an accurate and current SBOM for each digital product (by version) -- Rapidly create and publish a VEX (Vulnerability Exploitability eXchange) document for any actively exploited vulnerability that affects a product +- Create and maintain an accurate and current SBOM for each digital product +(by version) +- Rapidly create and publish a VEX (Vulnerability Exploitability eXchange) +document for any actively exploited vulnerability that affects a product -The AboutCode focus for CRA compliance functions and features is the [**DejaCode**](https://dejacode.readthedocs.io/en/latest/reference-3-cravex.html) application. +The AboutCode focus for CRA compliance functions and features is the +[**DejaCode**](https://dejacode.readthedocs.io/en/latest/reference-3-cravex.html) +application. ## Software Bills of Materials (SBOMs) Most modern product SBOMs are composed of some combination of: @@ -32,28 +46,46 @@ Most modern product SBOMs are composed of some combination of: - First-party code: Software created and owned by your organization. - Open source code: Software acquired from an open source project and subject to an open source license. -- Third-party proprietary code: Software acquired from a supplier that is subject to a proprietary license. In most cases today this code will include embedded open source software or have dependencies on open source software. +- Third-party proprietary code: Software acquired from a supplier that is +subject to a proprietary license. In most cases today this code will include +embedded open source software or have dependencies on open source software. -_NB: The CRA regulations apply to any code that you distribute. They do not normally apply to tools and other software for internal use-only._ +_NB: The CRA regulations apply to any code that you distribute. They do not +normally apply to tools and other software for internal use-only._ -In recent history, the focus for SBOMs has been open source software, but an accurate SBOM must include all first-party and third-party code in a product. +In recent history, the focus for SBOMs has been open source software, but an +accurate SBOM must include all first-party and third-party code in a product. This means that you need to request accurate and current SBOMs from your -proprietary software suppliers and have tools that enable you to import and manage third-party SBOMs into your SBOM management system. +proprietary software suppliers and have tools that enable you to import and +manage third-party SBOMs into your SBOM management system. -[DejaCode](https://dejacode.readthedocs.io/en/latest/) provides robust features to import, edit and export SBOMs in CycloneDX (versions 1.6, 1.5 or 1.4) or SPDX format (version 2.3). For CycloneDX you also have an option to export a combined SBOM + VEX document. +[DejaCode](https://dejacode.readthedocs.io/en/latest/) provides robust +features to import, edit and export SBOMs in CycloneDX (versions 1.6, 1.5 or +1.4) or SPDX format (version 2.3). For CycloneDX you also have an option to +export a combined SBOM + VEX document. - SBOM data are stored in **DejaCode** Products. -- You can also import scan data from [**ScanCode.io**](https://scancodeio.readthedocs.io/en/latest/) to create packages in **DejaCode**, enrich the package metadata, and assign them to a Product. -- The primary software identifier in **DejaCode** is [PURL (Package-URL)](https://package-url.github.io/www.packageurl.org/docs/purl/purl-spec-introduction). -- You can experiment with the Product/SBOM features with a free [DejaCode trial account](https://public.dejacode.com/account/register/) +- You can also import scan data from [ScanCode.io](https://scancodeio.readthedocs.io/en/latest/) +to create packages in **DejaCode**, enrich the package metadata, and assign +them to a Product. +- The primary software identifier in **DejaCode** is [PURL (Package-URL)](https://packageurl.org/docs/purl/introduction). +- You can experiment with the Product/SBOM features with a free [DejaCode +trial account](https://public.dejacode.com/account/register/) -As you change software in your products you need to update the corresponding Product in **DejaCode** for each Product or SBOM version. +As you change software in your products you need to update the corresponding +Product in **DejaCode** for each Product or SBOM version. ## Vulnerability identification -After you have created an SBOM for each Product in [DejaCode](https://dejacode.readthedocs.io/en/latest/) you can quickly identify current applicable vulnerabilities for a Product using the dynamic **DejaCode** integration with [**VulnerableCode**](https://vulnerablecode.readthedocs.io/en/latest/). **DejaCode** displays vulnerabilities for Products, Components and Packages. In each case there is an option to display only items with a known vulnerability. DejaCode also provides reports with this information. +After you have created an SBOM for each Product in **DejaCode** you can +quickly identify current applicable vulnerabilities for a Product using the +dynamic **DejaCode** integration with [**VulnerableCode**](https://vulnerablecode.readthedocs.io/en/latest/). **DejaCode** displays vulnerabilities for Products, Components and Packages. + In each case there is an option to display only items with a known + vulnerability. DejaCode also provides reports with this information. ## Vulnerability analysis and triage One of the most complex tasks for managing vulnerabilities is to determine -which vulnerabilities require your attention and in which order. For each vulnerability **DejaCode** provides three key metrics to support your analysis and triage: +which vulnerabilities require your attention and in which order. For each +vulnerability **DejaCode** provides three key metrics to support your analysis +and triage: - _Exploitability_: Exploitability indicates the likelihood that a vulnerability in a software package could be used by malicious actors to compromise systems, applications, or networks. This metric is determined @@ -67,14 +99,17 @@ maximum of 10. **DejaCode** also shows you known Package version(s) that fix a vulnerability. ## VEX reporting -The standard format for reporting your analysis of exploitable vulnerabilities is VEX (Vulnerability Exploitability eXchange). There are currently three evolving VEX specifications: +The standard format for reporting your analysis of exploitable vulnerabilities + is VEX (Vulnerability Exploitability eXchange). There are currently three + evolving VEX specifications: - [CSAF](https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html) from OASIS Open - [CycloneDX VEX](https://cyclonedx.org/capabilities/vex/) from the CycloneDX project - [OpenVEX](https://openssf.org/projects/openvex/) from OpenSSF -It is not clear which of these specifications will become primary, but they all cover similar data. +It is not clear which of these specifications will become primary, but they +all cover similar data. **DejaCode** provides a Product feature to record essential VEX data such as: - Status: The current state of an occurrence of a vulnerability, after @@ -88,21 +123,37 @@ You can easily export VEX information from **DejaCode** in CSAF, CycloneDX or OpenVEX format. ## Integration with software development tools -A key requirement for efficient compliance with CRA or similar regulations is integration with your software development tools. +A key requirement for efficient compliance with CRA or similar regulations is +integration with your software development tools. -- **DejaCode** provides built-in integration with issue trackers: Forgejo, GitHub, GitLab, JIRA, SourceHut. This is a two-way integration where your issue tracker is primary and the issue data is shown in **DejaCode** Requests. +- **DejaCode** provides built-in integration with issue trackers: Forgejo, +GitHub, GitLab, JIRA, SourceHut. This is a two-way integration where your +issue tracker is primary and the issue data is shown in **DejaCode** Requests. - **ScanCode.io** provides built-in integration with: - - CI/CD tools: GitHub Actions, GitLab, and Jenkins. This integration enables you to include **ScanCode.io** scans in your CI/CD pipelines or based on an event such as a commit. - - SCA tools: Anchore, cyclonedx-gomod, OSS Review Toolkit (ORT), OSV scanner, OWASP depscan, Microsoft sbom-tool, and Trivy. The primary functionality is to generate a CycloneDX SBOM from the SCA tool and load the SBOM into **ScanCode.io**. + - CI/CD tools: GitHub Actions, GitLab, and Jenkins. This integration + enables you to include **ScanCode.io** scans in your CI/CD pipelines or + based on an event such as a commit. + - SCA tools: Anchore, cyclonedx-gomod, OSS Review Toolkit (ORT), OSV + scanner, OWASP depscan, Microsoft sbom-tool, and Trivy. The primary + functionality is to generate a CycloneDX SBOM from the SCA tool and load + the SBOM into **ScanCode.io**. -_NB: All integrations also offer a "generic" template that you can adapt for integration with other similar tools._ +_NB: All integrations also offer a "generic" template that you can adapt for +integration with other similar tools._ ## Coming soon -We are working on a new [CRAVEX 2 Code Reachability](https://nlnet.nl/project/CRAVEX2-codereachability/) project to make vulnerability triage faster and more efficient. The two major enhancements are: - -- A rule-based system to automatically filter or rerank vulnerabilities in the context of a managed application, system or device. This will integrate the emerging SSVC scoring for decision tree-driven automation. - -- Vulnerable code "reachability" to determine if the code impacted by a CVE is present, used and exploitable in a product. This will integrate and extend the features of other FOSS projects such as [BANG](https://github.com/armijnhemel/binaryanalysis-ng). - -The **CRAVEX** projects are funded through the [NGI0 Entrust Fund](https://nlnet.nl/NGI0/), a fund established by NLnet with financial support from the European Commission's Next Generation Internet programme, under the aegis of DG Communications Networks, Content and Technology under grant agreement No 101069594. +We are working on a new [CRAVEX 2 Code Reachability](https://nlnet.nl/project/CRAVEX2-codereachability/) +project to make vulnerability triage faster and more efficient. The two major +enhancements are: +- A rule-based system to automatically filter or rerank vulnerabilities in the + context of a managed application, system or device. This will integrate the + emerging SSVC scoring for decision tree-driven automation. +- Vulnerable code "reachability" to determine if the code impacted by a CVE is + present, used and exploitable in a product. This will integrate and extend + the features of other FOSS projects such as [BANG](https://github.com/armijnhemel/binaryanalysis-ng). + +The **CRAVEX** projects are funded through the [NGI0 Entrust Fund](https://nlnet.nl/NGI0/), +a fund established by NLnet with financial support from the European +Commission's Next Generation Internet programme, under the aegis of DG +Communications Networks, Content and Technology under grant agreement No 101069594. diff --git a/website/docs/getting_started/license-compliance.md b/website/docs/getting_started/license-compliance.md index 40000ab..a3cb81a 100644 --- a/website/docs/getting_started/license-compliance.md +++ b/website/docs/getting_started/license-compliance.md @@ -1,14 +1,19 @@ # License Compliance -Compliance with licenses for third-party software is a very broad topic which was historically separated into two distinct domains: +Compliance with licenses for third-party software is a very broad topic which +was historically separated into two distinct domains: - Licenses for commercial software products where a purchasing department or similar organization has the primary responsibility for negotiating license -terms and conditions and an IT group has primary responsibility for tracking compliance with the license (e.g., number of seats, etc.). Commercial license +terms and conditions and an IT group has primary responsibility for tracking +compliance with the license (e.g., number of seats, etc.). Commercial license agreements are private (although the supplier may make standard license agreement text available publicly). - Licenses for open source software where anyone in an organization can acquire and use the software. Someone using open source software may be -required to agree to license terms when downloading the software, but there is normally no contract or other agreement recorded in the organization. Many organizations today have created an OSPO (Open Source Program Office) or -similar group to track compliance with open source licenses. Open source licenses are public but there are typically no counter-signed license +required to agree to license terms when downloading the software, but there is + normally no contract or other agreement recorded in the organization. Many + organizations today have created an OSPO (Open Source Program Office) or +similar group to track compliance with open source licenses. Open source +licenses are public but there are typically no counter-signed license agreements. In both domains legal staff have typically been responsible for setting @@ -16,30 +21,45 @@ policies and monitoring compliance with those policies. For modern software development the boundary between commercial and open source licenses has become fuzzy with the increasing use of so-called "dual" -licenses (with a choice of commercial or open source license for the same software), "source available" licenses (which have characteristics of both +licenses (with a choice of commercial or open source license for the same +software), "source available" licenses (which have characteristics of both commercial and open source licenses) and various pseudo-open source licenses. The reality for modern software development is that you need to identify the specific license terms and conditions for any third-party software that you use and report it in SBOMs and other documentation ## Identify licenses for software and for data -The first task for license compliance is to identify and document all third-party software that you use - regardless of whether the usage is +The first task for license compliance is to identify and document all +third-party software that you use - regardless of whether the usage is internal-only or external to your organization. ScanCode from AboutCode is the industry-leading software scanning tool -and it is embedded in many open source SCA (Software Composition Analysis) projects including [FOSSology](https://www.fossology.org/) and [ORT](https://oss-review-toolkit.org/ort/). ScanCode is also embedded in many commercial -SCA products. There are three primary ScanCode projects: -- [ScanCode Toolkit](https://scancode-toolkit.readthedocs.io/en/stable/) is a set of code scanning tools that detect the origin (copyrights, authors, URLs, etc.) and license for any type of software. It uses a robust set of rules to detect more than 2,400 licenses and also clues to partial license text. You can use the Toolkit as a library or command line utility. +and it is embedded in many open source SCA (Software Composition Analysis) +projects including [FOSSology](https://www.fossology.org/) and +[ORT](https://oss-review-toolkit.org/ort/). ScanCode is also embedded in many +commercial SCA products. + +There are three primary ScanCode projects: +- [ScanCode Toolkit](https://scancode-toolkit.readthedocs.io/en/stable/) is a +set of code scanning tools that detect the origin (copyrights, authors, URLs, +etc.) and license for any type of software. It uses a robust set of rules to +detect more than 2,400 licenses and also clues to partial license text. You +can use the Toolkit as a library or command line utility. - [ScanCode.io](https://scancodeio.readthedocs.io/en/latest/) is an application (Web UI and API) where you can run standard or custom pipelines to -identify licenses, copyrights, packages, dependencies and vulnerabilities. It also has pipelines to match deployment "binaries" (compiled or interpreted) to +identify licenses, copyrights, packages, dependencies and vulnerabilities. It +also has pipelines to match deployment "binaries" (compiled or interpreted) to corresponding source. You normally run ScanCode.io as a Docker container. - [ScanCode LicenseDB](https://scancode-licensedb.aboutcode.org/) is the reference database for the 2400 licenses detected by ScanCode. It is limited -to public license texts but not to only those licenses that meet the OSI definition of open source. ScanCode's objective is to identify licenses regardless of whether they are open source, proprietary or in-between. Each -license in the LicenseDB is labelled with a License Category, such as 'Copyleft', 'Permissive' or 'Public Domain'. +to public license texts but not to only those licenses that meet the OSI +definition of open source. ScanCode's objective is to identify licenses r +egardless of whether they are open source, proprietary or in-between. Each +license in the LicenseDB is labelled with a License Category, such as +'Copyleft', 'Permissive' or 'Public Domain'. -There are also other [AboutCode projects](/projects/) that are components or extensions of ScanCode. +There are also other [AboutCode projects](/projects#scancode-projects) that +are components or extensions of ScanCode. ## Apply license usage policies The only feasible way to automate license compliance for third-party software @@ -47,18 +67,24 @@ is to define and apply license policies that are easy for anyone in your organization to recognize. [DejaCode](https://dejacode.readthedocs.io/en/latest/) incorporates a -License Library including the current **ScanCode LicenseDB** data and any licenses that you choose to add to the Library. The **DejaCode** license +License Library including the current **ScanCode LicenseDB** data and any +licenses that you choose to add to the Library. The **DejaCode** license management features include: -- _License conditions_ document standard license terms and conditions like specific attribution or redistribution obligations, patent-related conditions, warranty disclaimers, usage restrictions and more. +- _License conditions_ document standard license terms and conditions like +specific attribution or redistribution obligations, patent-related conditions, +warranty disclaimers, usage restrictions and more. - _License profiles_ provide an easy way to group a set of commonly recurring _License conditions_ for license review and assigning a usage policy. - _License usage policies_ allow to define any number of license policies. A -common approach is to start with a simple set of policies like 'Recommended', 'Approved', Restricted', and 'Prohibited'. Later you can refine your approach +common approach is to start with a simple set of policies like 'Recommended', +'Approved', Restricted', and 'Prohibited'. Later you can refine your approach to define more granular policies, such as more granular policies for internal-only versus external use. In **DejaCode** you can define _License usage policies_ at the component, -package, product-component or product-package levels. Both **ScanCode Toolkit** and **ScanCode.io** can apply license policies that you create in **DejaCode** (or some other system that can define comparable policies). A license policy +package, product-component or product-package levels. Both **ScanCode Toolkit** +and **ScanCode.io** can apply license policies that you create in **DejaCode** +(or some other system that can define comparable policies). A license policy is documented in a YAML file. ## Produce SBOMs @@ -67,16 +93,20 @@ compliance and vulnerability risk management. License compliance is a strong use case for an SBOM because license data are much less volatile than vulnerability data. -- [DejaCode](https://dejacode.readthedocs.io/en/latest/) provides features to -import, edit and export SBOMs in CycloneDX (versions 1.6, 1.5 or 1.4) or SPDX format (version 2.3). For CycloneDX you also have an option to export a -combined SBOM + VEX document. SBOM data are stored in **DejaCode** Products. +- **DejaCode** provides features to import, edit and export SBOMs in +CycloneDX (versions 1.6, 1.5 or 1.4) or SPDX format (version 2.3). For +CycloneDX you also have an option to export a combined SBOM + VEX document. +SBOM data are stored in **DejaCode** Products. A Product can be third-party or first-party (or second-party:customer). You -can define a Product at any level - e.g., some may be at a component or assembly level. You can experiment with the Product/SBOM features with a free [DejaCode trial account](https://public.dejacode.com/account/register/) -- [ScanCode.io](https://scancodeio.readthedocs.io/en/latest/) provides -features to import and export SBOMs in CycloneDX (version 1.7, 1.6, 1.5 or -1.4) or SPDX format (version 2.3 or 2.2). You can use the `load_sbom` -pipeline to load one more SBOMs as a Project and use `add-on` pipelines to -enrich the data before you export it as an SBOM. You can also export Project data in JSON or XLSX format. If you need to edit an SBOM, you should use **DejaCode** instead of **ScanCode.io** +can define a Product at any level - e.g., some may be at a component or +assembly level. You can experiment with the Product/SBOM features with a free +[DejaCode trial account](https://public.dejacode.com/account/register/) +- **ScanCode.io** provides features to import and export SBOMs in CycloneDX +(version 1.7, 1.6, 1.5 or 1.4) or SPDX format (version 2.3 or 2.2). You can +use the `load_sbom` pipeline to load one more SBOMs as a Project and use +`add-on` pipelines to enrich the data before you export it as an SBOM. You can + also export Project data in JSON or XLSX format. If you need to edit an SBOM, + you should use **DejaCode** instead of **ScanCode.io** ## Automate compliance Two common and key obligations for compliance with open source software @@ -84,19 +114,21 @@ licenses are: ### Attribution Almost all open source licenses, except for "Public Domain", require some form -of attribution in source code, derivative works or documentation (or all of these) if you distribute the open source software in your products or +of attribution in source code, derivative works or documentation (or all of +these) if you distribute the open source software in your products or otherwise. It is usually simpler to provide attribution generously for any -open source software that you distribute rather than try to track and comply with more granular attribution obligations. +open source software that you distribute rather than try to track and comply +with more granular attribution obligations. -- [DejaCode](https://dejacode.readthedocs.io/en/latest/) provides a highly -customizable feature to generate an Attribution Notice. You can customize the -document format (Jinja2 template) for your organization and fine-tune the -Notice contents when you generate a Notice for a Product. -- [ScanCode.io](https://scancodeio.readthedocs.io/en/latest/) can generate an -Attribution Notice for a Project using an HTML template that you can customize -directly in **ScanCode.io** settings. -- [AboutCode Toolkit](https://aboutcode.readthedocs.io/projects/aboutcode-toolkit/en/latest/) is a set of command line tools to document the provenance of your code and generate Attribution Notices. You can generate an Attribution Notice from ABOUT files (small YAML files) inside a codebase or -from JSON, CSV or XLSX input files. +- **DejaCode** provides a highly customizable feature to generate an +Attribution Notice. You can customize the document format (Jinja2 template) +for your organization and fine-tune the Notice contents when you generate a +Notice for a Product. +- **ScanCode.io** can generate an Attribution Notice for a Project using an +HTML template that you can customize directly in **ScanCode.io** settings. +- [AboutCode Toolkit](https://aboutcode.readthedocs.io/projects/aboutcode-toolkit/en/latest/) +is a set of command line tools to document the provenance of your code and +generate Attribution Notices. You can generate an Attribution Notice from ABOUT files (small YAML files) inside a codebase or from JSON, CSV or XLSX input files. ### Redistribution Some open source licenses require that you offer to redistribute source code diff --git a/website/docs/getting_started/software-identification.md b/website/docs/getting_started/software-identification.md index 649f851..7db542d 100644 --- a/website/docs/getting_started/software-identification.md +++ b/website/docs/getting_started/software-identification.md @@ -19,8 +19,9 @@ represents approximately 80% of software in use according to most surveys. The AboutCode team identified this problem in 2018 in the context of working on our ScanCode and VulnerableCode projects. The solution is the PURL (Package-URL) specification which has become the most widely used software -identifier for open source software. PURL is now an Ecma standard: [ECMA-427](https://ecma-tc54.github.io/ECMA-427/) -and it is on a fast track to become an ISO standard. +identifier for open source software. PURL is now an Ecma standard: +[ECMA-427](https://ecma-tc54.github.io/ECMA-427/). ECMA-427 is on a fast track + to become an ISO standard. Our team also identified a related problem - after you have a standard way to identify software packages, what is a standard way to compare software @@ -29,11 +30,9 @@ version that you use? Our solution is the VERS (VErsion Range Specifier) specification which will be submitted to Ecma as a standard in 2026. See the [Package-URL](https://www.packageurl.org/) website -for more information about PURL and VERS. +for more information about the PURL and VERS specifications -See the Package-URL (PURL) projects section of the Home page for more -information about AboutCode tools that provide PURL- and VERS-specific -capabilities. +All AboutCode projects use PURL for software identification. ## Identify software packages and components For the basic use case of identifying software packages and components, @@ -80,7 +79,7 @@ SPDX License List. and manage a database of package metadata keyed by PURL. You can use PURLDB data via API to enrich your package and SBOM data in DejaCode, ScanCode.io, or your own application. The AboutCode team also currently hosts a public -[PURLDB](https://public.purldb.io/api/) service with REST API. +[PURLDB service](https://public.purldb.io/api/) with a REST API. ## Analyze containers The analysis of containers to produce inventories or SBOMs for the software @@ -89,11 +88,11 @@ increasing volume of software deployed on containers and the large volume of software deployed in most containers. For this use case, the primary AboutCode tools and data are: -- [ScanCode.io](https://scancodeio.readthedocs.io/en/latest/) provides the -`analyze_docker_image` pipeline for container analysis. This will produce a -software inventory for Resources (all files), Packages (package metadata), -Dependencies (from package manifest files). The scan data also includes -detailed information about image layers and their file content. +- **ScanCode.io** provides the `analyze_docker_image` pipeline for container +analysis. This pipeline will produce a software inventory including Resources +(all files), Packages (packages and their metadata), and Dependencies +(from package manifest files). The scan data also includes detailed +information about image layers and their file content. If you conclude that the ScanCode.io inventory is accurate, you can export the data in CycloneDX or SPDX SBOM format, or in JSON or XLSX format @@ -102,10 +101,9 @@ detailed information about image layers and their file content. If you need to update or enhance the scan data before you produce an SBOM, DejaCode provides several options. -- [DejaCode](https://dejacode.readthedocs.io/en/latest/) is highly integrated -with ScanCode so that you can easily import ScanCode scan data from ScanCode -Toolkit or ScanCode.io into DejaCode as a **Product**. In DejaCode, you can -then: +- **DejaCode** is deeply integrated with ScanCode so that you can easily +import ScanCode scan data from ScanCode Toolkit or ScanCode.io into DejaCode +as a Product. In DejaCode, you can then: - Enrich the package data from PURLDB - Apply your license usage policies @@ -116,9 +114,9 @@ then: - [container-inspector](https://github.com/aboutcode-org/container-inspector/blob/main/README.rst) is a static analysis tool to analyze the structure of software components in a - container image. container-inspector is used in the ScanCode.io - `analyze_docker_image` pipeline for the layer analysis, -but you can also use it as a command line utility. +container image. **container-inspector** is used in the ScanCode.io +`analyze_docker_image` pipeline for the layer analysis, but you can also use +it as a command line utility. ## Consume or produce SBOMs The EU CRA (Cyber Resilience Act) and other regulatory initiatives have @@ -142,10 +140,9 @@ AboutCode community we consider binary-source matching to be a subset of the much larger domain of matching "deploy" files to "devel" files. This matching challenge includes: -- [ScanCode.io](https://scancodeio.readthedocs.io/en/latest/) supports -"deploy-to-devel" matching with the `map_deploy_to_develop` pipeline. +- **ScanCode.io** supports "deploy-to-devel" matching with the +`map_deploy_to_develop` pipeline. This pipeline currently handles: - - Matching Linux ELF, Windows, MacOS or Rust binaries to source - Matching Go binaries to source - Matching Java `jar` or `class` files to corresponding Java, Kotlin or @@ -161,8 +158,7 @@ algorithm. You can use the **MatchCode Toolkit** as a library. - ScanCode uses several AboutCode libraries to analyze "deploy" files including: - [binary-inspector](https://github.com/aboutcode-org/binary-inspector/blob/main/README.rst) - extracts symbols from binaries in ELF, Mach-O, WinPe and - other formats + extracts symbols from binaries in ELF, Mach-O, WinPe and other formats - [elf-inspector](https://github.com/aboutcode-org/elf-inspector/blob/main/README.rst) collects data from ELF binaries - [go-inspector](https://github.com/aboutcode-org/go-inspector/blob/main/README.rst) diff --git a/website/docs/getting_started/software-security.md b/website/docs/getting_started/software-security.md index 66aa418..f4a9d00 100644 --- a/website/docs/getting_started/software-security.md +++ b/website/docs/getting_started/software-security.md @@ -5,7 +5,7 @@ vulnerabilities because this fits with our core expertise in software identification and SCA (Software Composition Analysis). We are, however, expanding our scope for software security with the recent addition of the **atom** and **chen** project to the AboutCode community, but most of our tools - and data are related to software vulnerabilities. See also [atom and chen join AboutCode](/blog/atom-chen-aboutcode). + and data are related to software vulnerabilities. Note that AboutCode tools and data for software vulnerabilities expect that software will be identified with a [PURL (Package-URL)](https://package-url.github.io/www.packageurl.org/docs/purl/purl-spec-introduction). @@ -21,10 +21,10 @@ vulnerabilities from upstream and downstream public data sources. The VulnerableCode tools collect, aggregate and correlated vulnerabilities and maps them to package versions using PURL. - AboutCode hosts the public [VCIO](https://public2.vulnerablecode.io/) + AboutCode hosts the public [VCIO](https://public.vulnerablecode.io/) database with a Web UI for queries and an API. Access is free but there are some restrictions on the frequency and volume of API requests. You can - use the VulnerableCode tools to build, maintain and + use the VulnerableCode tools to build, maintain and use (Web UI and APIs) your own private VCIO database. - [DejaCode](https://dejacode.readthedocs.io/en/latest/) integrates software @@ -43,22 +43,22 @@ your Scan project. Then you can view the vulnerability data in the UI, export it (JSON, XLSX, SPDX, CDX and other formats) or pull it from the API. ## Manage risk with aggregated vulnerability data -[VulnerableCode](https://vulnerablecode.readthedocs.io/en/latest/) provides -tools to create and maintain a database of known software vulnerabilities -from public sources up and down the software supply chain. When evaluating the -vulnerabilities for a package (or a single vulnerability) you will need -information from upstream FOSS projects and downstream projects and distros -that include software from upstream. For example, there may be significant -differences in [CVSS](https://www.first.org/cvss/) Severity scores provided by -different organizations With a **VulnerableCode** database like -[VCIO](https://public2.vulnerablecode.io/) you can see the aggregated Severity - information for each vulnerability in one place or pull it with the API for -use in other systems. +**VulnerableCode** provides tools to create and maintain a database of known +software vulnerabilities from public sources up and down the software supply +chain. When evaluating the vulnerabilities for a package (or a single +vulnerability) you will need information from upstream FOSS projects and +downstream projects and distros that include software from upstream. For +example, there may be significant differences in [CVSS](https://www.first.org/cvss/) +Severity scores provided by different organizations With a **VulnerableCode** +database like [VCIO](https://public.vulnerablecode.io/) you can see the +aggregated Severity information for each vulnerability in one place or pull it +with the API for use in other systems. ## Triage vulnerabilities One of the most complex tasks for managing vulnerabilities is to determine -which vulnerabilities require your attention and in which order. [VulnerableCode](https://vulnerablecode.readthedocs.io/en/latest/) provides three key metrics for each -vulnerability to assist with this triage: +which vulnerabilities require your attention and in which order. +**VulnerableCode** provides three key metrics for each vulnerability to assist + with this triage: - _Exploitability_: Exploitability indicates the likelihood that a vulnerability in a software package could be used by malicious actors to compromise systems, applications, or networks. This metric is determined @@ -85,8 +85,8 @@ project It is not clear which of these specifications will become primary, but they all cover similar data. -[DejaCode](https://dejacode.readthedocs.io/en/latest/) provides a Product -(inventory or SBOM) feature to record the essential VEX data such as: +**DejaCode** provides a Product (inventory or SBOM) feature to record the +essential VEX data such as: - Status: The current state of an occurrence of a vulnerability, after automated or manual analysis. - Justification: The rationale for why the impact analysis state was asserted. From c90bd5425430e6e811a1600171539829a086b4fa Mon Sep 17 00:00:00 2001 From: Michael Herzog Date: Fri, 29 May 2026 11:35:01 -0700 Subject: [PATCH 2/2] Update software-security.md Fixed PURL link Signed-off-by: Michael Herzog --- website/docs/getting_started/software-security.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/getting_started/software-security.md b/website/docs/getting_started/software-security.md index f4a9d00..cb9ec90 100644 --- a/website/docs/getting_started/software-security.md +++ b/website/docs/getting_started/software-security.md @@ -8,7 +8,7 @@ expanding our scope for software security with the recent addition of the and data are related to software vulnerabilities. Note that AboutCode tools and data for software vulnerabilities expect that -software will be identified with a [PURL (Package-URL)](https://package-url.github.io/www.packageurl.org/docs/purl/purl-spec-introduction). +software will be identified with a [PURL (Package-URL)](https://packageurl.org/docs/purl/introduction). ## Identify vulnerabilities For the basic use case of identifying software vulnerabilities, AboutCode