Merge pull request #111 from johnmhoran/84-republish-2023-05-03-purl-post

84 republish 2023 05 03 purl post

Author: johnmhoran

website/blog/authors.yml

@@ -28,6 +28,16 @@ pombredanne:
     linkedin: philippeombredanne
     github: pombredanne
 
+team:
+  name: AboutCode team
+  title: Open source for open source
+  url: https://github.com/aboutcode-org
+  image_url: /img/nexB_icon.svg
+  page: true
+  socials:
+    linkedin: https://www.linkedin.com/company/nexb
+    github: https://github.com/aboutcode-org
+
 tg1999:
   name: Tushar Goel
   title: Software Engineer

website/blog/curated-licenses-public-database-scancode-licensedb/ScanCode-LicenseDB-1536x1085.png

@@ -0,0 +1,58 @@
+---
+slug: scancode-licensedb
+title: ScanCode LicenseDB -- 2,000+ licenses curated in a public database
+authors: [team]
+tags: [license compliance, license detection]
+hide_table_of_contents: false
+---
+
+The ScanCode LicenseDB is all about identifying a wide variety of licenses that are actually found in software.
+
+![scancode-db-blog](scancode-db-blog.png)
+
+New software licenses appear constantly (like mushrooms popping out of the ground after a heavy rain) and old nearly-forgotten ones are rediscovered when someone [scans a codebase](https://www.nexb.com/scancode/) that incorporates legacy code (like finding rare medieval manuscripts in the back shelves of a library). The [ScanCode LicenseDB](https://scancode-licensedb.aboutcode.org/) precisely identifies and organizes licenses and their metadata so that multiple members of the software community can understand exactly which licenses are being referenced in project documentation.
+
+If you have seen a license notice, passed it on to your legal team for scrutiny, and completed that review, but you probably do not want to repeat that process over and over again.
+
+With over 2,000 licenses, ScanCode LicenseDB is arguably the largest free list of curated software licenses available on the internet, and an essential reference license resource for license compliance and SBOMs. ScanCode LicenseDB is available as a website, a JSON or YAML API, and a git repository making it easy to reuse and integrate in tools that need a database of reference software licenses.
+
+Here are some key points about the ScanCode LicenseDB:
+
+- Is a list of 2,092 licenses recognized by scancode-toolkit as of 2023-03-13
+- Identifies each license by the license key defined in scancode-toolkit
+- Provides an SPDX Identifier (with link) to every license and exception on the SPDX License List, and a “Licenseref” identifier for every license and exception not on the SPDX License List.
+- Provides license texts in plain text formats.
+- Provides license texts and metadata in yml and json.
+- Freely accessible via [API](https://scancode-licensedb.aboutcode.org/help.html#api)
+- Data licensed under CC-BY-4.0
+- Community supported on [GitHub](https://github.com/nexB/scancode-licensedb).
+
+And below are some frequently asked questions about the ScanCode LicenseDB.
+
+**Q: What are the inclusion criteria for a license to be in the ScanCode LicenseDB?**
+
+A: The only requirements are a text and a usage in existing code. The ScanCode LicenseDB includes multiple categories of licenses, not just open source: permissive, copyleft, commercial, proprietary free, source-available, etc. More information on license categories is available here: https://scancode-licensedb.aboutcode.org/help.html#license-categories
+
+**Q: Does the ScanCode LicenseDB compete with other license lists, such as the SPDX license list?**
+
+A: No. The ScanCode LicenseDB is intended to **supplement** other license lists. When new licenses are discovered by scancode-toolkit or the software community, they are added to the list with references to other lists whenever possible.
+
+**Q: What is the process for adding or correcting licenses in the ScanCode LicenseDB?**
+
+A: License curation is primarily a task of the active participants in [AboutCode.org](https://www.aboutcode.org/), but any member of the software community is welcome to log and respond to issues at https://github.com/nexB/scancode-licensedb/issues. See https://scancode-licensedb.aboutcode.org/help.html#support for more details.
+
+**Q: Is a license in the ScanCode LicenseDB “approved” or “recommended for use”?**
+
+A: The ScanCode LicenseDB is all about identifying the wide variety of licenses that are actually found in software. There is no attempt to approve or disapprove of license terms, and there is no attempt to correct poorly written licenses. The only license interpretation provided is a license category, which represents the best judgment of the license curators.
+
+**Q: How are licenses discovered (detected) by scancode-toolkit?**
+
+A: For license detection, ScanCode uses a (large) number of license texts and license detection ‘rules’ that are compiled in a search index. When scanning, the text of the target file is extracted and used to query the license search index and find license matches.
+
+For copyright detection, ScanCode uses a grammar that defines the most common and less common forms of copyright statements. When scanning, the target file text is extracted and ‘parsed’ with this grammar to extract copyright statements.
+
+More detailed information is available at https://scancode-toolkit.readthedocs.io/en/stable/explanation/scancode-license-detection.html#scancode-license-detection.
+
+**Q: How can I get help or contribute to ScanCode LicenseDB?**
+
+A: You can chat with the AboutCode community on [Gitter](https://app.gitter.im/#/room/#aboutcode-org_discuss:gitter.im), or report issues or ask questions at https://github.com/nexB/scancode-licensedb/issues.

website/blog/curated-licenses-public-database-scancode-licensedb/scancode-db-blog.png

@@ -0,0 +1,57 @@
+---
+slug: non-vulnerable-dependency-resolution
+title: Non-Vulnerable Dependency Resolution
+authors: [tg1999]
+tags: [dependencies, vulnerabilities]
+hide_table_of_contents: false
+---
+
+Dependencies may come with vulnerabilities that can be exploited by attackers.
+
+![non-vulnerable-dependency](non-vulnerable-dependency.png)
+
+Dependency resolution is the process of identifying and installing the required software packages to ensure that the software being developed runs smoothly. However, these dependencies may come with vulnerabilities that can be exploited by attackers.
+
+Until now, these contexts have been considered as separate domains:
+
+- Package management tools resolve the version expression of the dependent package of a package to resolved versions in order to install the selected versions.
+
+- Security tools check if resolved package versions are affected by known vulnerabilities (even when integrated in a package management tool)
+
+As a result, the typical approach to get a non-vulnerable dependency tree is:
+
+1. Resolve a dependency tree and install the resolved package versions.
+
+2. For each resolved dependent package version, translate the identifiers and look in a vulnerability or bug database to determine if a version is affected by a vulnerability and which package version fixes this vulnerability, if any.
+
+3. Update the vulnerable versions with fixing versions.
+
+4. Repeat step 1 until you have exhausted all possibilities. Stop on conflicts if a resolution is not possible when considering functional requirements and vulnerability fixing versions.
+
+That approach is complex, tedious and time-consuming. It also suggests non-vulnerable versions without consideration for the functional dependency requirements necessary when reconsidering each dependency separately. This is a waste of time and effort as the non-vulnerable suggestion may not satisfy the functional constraints. Stated otherwise, the result may be a non-vulnerable package tree where packages do not work together and do not satisfy functional requirements, e.g., this results in potentially non-functional software.
+
+[![maven-find-transitive-dependencies](maven-dependency-tree.png)](https://www.tutorialworks.com/maven-find-transitive-dependencies/)
+
+Here at nexB, we propose a new method and process to resolve software package vulnerable version ranges and dependency version constraints at the same time. This enables developers to obtain a resolved software package version tree matching the blended constraints of functional and vulnerability requirements in order to provide non-vulnerable and up-to-date software code.
+
+The process would go through these typical steps:
+
+1. Given an input software package, collect its direct functional dependency requirements from its manifests and/or lockfiles. Optionally, parse these requirements to normalize them as [Package-URLs](https://github.com/package-url) and [Version Range Specs](https://github.com/nexB/univers).
+
+2. Fetch the known package versions set from the ecosystem package registry.
+
+3. Collect known affected package versions ranges and fixed ranges from a vulnerability database or service using the identifiers from step 1.
+
+4. Combine the version ranges of each dependency from steps 1 and 3 in a single new version range and for each dependent package.
+
+5. Feed the combined ranges from step 4 as input to the dependency resolver. Obtain resolved dependencies that satisfies both constraints. The resolver may further request additional versions and ranges using the processes from steps 1 through 4 when new dependent packages are collected during the resolution process.
+
+6. Obtain and output the results of the combined resolution of step 5. Report conflicts and optionally suggest conflict resolutions.
+
+With this new process, we get a resolved package dependency tree with versions that satisfy both functional and vulnerability or bug constraints in a single resolution pass.
+
+It’s worth noting that non-vulnerable dependency resolution is an ongoing process. Developers should regularly monitor their software packages for any newly discovered vulnerabilities and update their packages accordingly. This is particularly important when new vulnerabilities are discovered in commonly used packages, as these can have a significant impact on a wide range of software applications.
+
+In conclusion, non-vulnerable dependency resolution is an essential practice that should be adopted by all developers. By selecting software packages that are free from known vulnerabilities, developers can significantly reduce the risk of security breaches in their software applications. Additionally, regularly monitoring and updating packages, as well as ensuring that packages are obtained from trusted sources, can further enhance the security of software development.
+
+To understand this topic in more detail, read this defensive publication on [Non-Vulnerable Dependency Resolution](https://www.tdcommons.org/dpubs_series/5224/) from the Technical Disclosure Commons.