Upload SBOM/C-SCRM Recommendations #247
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ljharb
reviewed
Nov 20, 2024
| In particular, these two technologies have been promoted by policy makers and open source software consumers and advocates to address these challenges: | ||
|
|
||
| * **SBOMs**: provide an inventory of components included in a software product in an ecosystem-neutral format | ||
| * **Software Provenance Attestation**: a trusted and verifiable claim of where a software component, artifact or product came from |
There was a problem hiding this comment.
Suggested change
| * **Software Provenance Attestation**: a trusted and verifiable claim of where a software component, artifact or product came from | |
| * **Software Provenance Attestation**: a trusted and verifiable claim of where a software component, artifact, or product came from |
| The OpenJS Foundation supports the intent of the regulatory regime governments are seeking to build. However, broad adoption of these technologies by volunteer, part-time maintainers in many cases is hard to justify. Based on our analysis, we recommend that: | ||
|
|
||
| * **SBOMs in the Node.js ecosystem** | ||
| * Should only be generated for end-user facing JavaScript applications and never for individual Javascript libraries that do not provide functionality for end users. This is due to npm’s dependency resolution algorithm, which produces dependency trees for isolated libraries that should not be expected to represent the dependencies of that library when resolved in the context of a JavaScript application. Thus, only JavaScript applications should generate SBOMs. |
There was a problem hiding this comment.
Suggested change
| * Should only be generated for end-user facing JavaScript applications and never for individual Javascript libraries that do not provide functionality for end users. This is due to npm’s dependency resolution algorithm, which produces dependency trees for isolated libraries that should not be expected to represent the dependencies of that library when resolved in the context of a JavaScript application. Thus, only JavaScript applications should generate SBOMs. | |
| * Should only be generated for end-user facing JavaScript applications and never for individual JavaScript libraries that do not provide functionality for end users. This is due to npm’s dependency resolution algorithm, which produces dependency trees for isolated libraries that should not be expected to represent the dependencies of that library when resolved in the context of a JavaScript application. Thus, only JavaScript applications should generate SBOMs. |
| * **SBOMs in the Node.js ecosystem** | ||
| * Should only be generated for end-user facing JavaScript applications and never for individual Javascript libraries that do not provide functionality for end users. This is due to npm’s dependency resolution algorithm, which produces dependency trees for isolated libraries that should not be expected to represent the dependencies of that library when resolved in the context of a JavaScript application. Thus, only JavaScript applications should generate SBOMs. | ||
| * **npm Package Provenance** | ||
| * I not recommended for JavaScript libraries and applications as currently implemented as it does not provide the real world security value that many assume it does. We’ve recommended several substantial improvements to npm and GitHub to resolve these gaps so that the sometimes substantial effort needed to implement package provenance can be justified. |
There was a problem hiding this comment.
Suggested change
| * I not recommended for JavaScript libraries and applications as currently implemented as it does not provide the real world security value that many assume it does. We’ve recommended several substantial improvements to npm and GitHub to resolve these gaps so that the sometimes substantial effort needed to implement package provenance can be justified. | |
| * Is not recommended for JavaScript libraries and applications as currently implemented, as it does not provide the real world security value that many assume it does. We’ve recommended several substantial improvements to npm and GitHub to resolve these gaps so that the sometimes substantial effort needed to implement package provenance can be justified. |
| ### **Large numbers of smaller transitive dependencies** | ||
| --- | ||
|
|
||
| The npm Package Registry is the largest software ecosystem registry on the Internet. One of the reasons for this is that, unlike other language ecosystems, JavaScript packages often have a large number of small transitive dependencies. Packages in npm average over 300 transitive dependencies, while the next closest (Ruby) averages less than 100\. |
There was a problem hiding this comment.
Suggested change
| The npm Package Registry is the largest software ecosystem registry on the Internet. One of the reasons for this is that, unlike other language ecosystems, JavaScript packages often have a large number of small transitive dependencies. Packages in npm average over 300 transitive dependencies, while the next closest (Ruby) averages less than 100\. | |
| The npm Package Registry is the largest software ecosystem registry on the Internet. One of the reasons for this is that, unlike other language ecosystems, JavaScript packages often have a large number of small transitive dependencies. Packages in npm average over 300 transitive dependencies, while the next closest (Ruby) averages less than 100. |
| ### **Recommendations for JavaScript library packages** | ||
| --- | ||
|
|
||
| 1. **Library Maintainers:** Individual library packages that **DO NOT** include compiled language tools (eg: CLI tools), binaries or containers should not publish SBOMs. |
There was a problem hiding this comment.
Suggested change
| 1. **Library Maintainers:** Individual library packages that **DO NOT** include compiled language tools (eg: CLI tools), binaries or containers should not publish SBOMs. | |
| 1. **Library Maintainers:** Individual library packages that **DO NOT** include compiled language tools (eg: CLI tools), binaries, or containers should not publish SBOMs. |
|
|
||
| 7. **Application Maintainers:** JavaScript Applications **SHOULD** publish SBOMs for their application, that also **INCLUDE** SBOMs for compiled code tools, binaries, and containers. | ||
| * The challenges related to library SBOM accuracy do not apply to application SBOMs. | ||
| * Despite the presence of ecosystem native package-lock.json and npm-shrinkwrap.json manifest files this information is more easily consumed by end users in an cross-ecosystem standard format. |
There was a problem hiding this comment.
Suggested change
| * Despite the presence of ecosystem native package-lock.json and npm-shrinkwrap.json manifest files this information is more easily consumed by end users in an cross-ecosystem standard format. | |
| * Despite the presence of ecosystem-native `package-lock.json` and `npm-shrinkwrap.json` manifest files, this information is more easily consumed by end users in a cross-ecosystem standard format. |
Comment on lines
+148
to
+151
| GitHub’s announcement referenced three attacks that they are seeking to prevent with package provenance: [malware in ua-parser-js](https://github.com/advisories/GHSA-pjwm-rvh2-c87w), [malware in coa](https://github.com/advisories/GHSA-73qr-pfmq-6rp8), [malware in rc](https://github.com/advisories/GHSA-g2q5-5433-rhrf). These attacks were all accomplished by malicious actors who: | ||
|
|
||
| 1. [ATT\&CK T1586.003](https://attack.mitre.org/techniques/T1586/003/): Compromised a maintainer’s npm account through undisclosed means | ||
| 2. [CAPEC-538](https://capec.mitre.org/data/definitions/538.html): Added malware to the package and published the now malicious package to npm as an updated version of the legitimate package |
There was a problem hiding this comment.
it doesn't actually prevent these attacks, though - it just means that attackers with repo access would have to be a bit more clever about obfuscating the source of the malicious code.
|
|
||
| * Lack of support for MFA prompts in GitHub Actions requires maintainers to use single factor access tokens and stop using credentials that support MFA | ||
| * Use of GitHub Actions increases the attack surface for package hijacking by: | ||
| * Likely increasing the number users able to publish a given package |
There was a problem hiding this comment.
Suggested change
| * Likely increasing the number users able to publish a given package | |
| * Likely increasing the number of users able to publish a given package |
|
|
||
| * #### **GitHub Actions does not support CLI 2FA prompts** | ||
|
|
||
| GitHub Actions do not have the ability to pause for an MFA prompt from a CLI tool. There are free third party services with GitHub Actions that provide this functionality such as the [wait-for-secrets GitHub Action](https://github.com/step-security/wait-for-secrets) by [StepSecurity](https://www.stepsecurity.io) and [Wombat Dressing Room](https://github.com/GoogleCloudPlatform/wombat-dressing-room) by [GCP](https://opensource.googleblog.com/2020/01/wombat-dressing-room-npm-publication_10.html). Unfortunately, in this model the maintainer must provide their npm credentials to a third party server. |
There was a problem hiding this comment.
Suggested change
| GitHub Actions do not have the ability to pause for an MFA prompt from a CLI tool. There are free third party services with GitHub Actions that provide this functionality such as the [wait-for-secrets GitHub Action](https://github.com/step-security/wait-for-secrets) by [StepSecurity](https://www.stepsecurity.io) and [Wombat Dressing Room](https://github.com/GoogleCloudPlatform/wombat-dressing-room) by [GCP](https://opensource.googleblog.com/2020/01/wombat-dressing-room-npm-publication_10.html). Unfortunately, in this model the maintainer must provide their npm credentials to a third party server. | |
| tHub Actions do not have the ability to pause for an MFA prompt from a CLI tool. There are free third party services with GitHub Actions that provide this functionality such as the [wait-for-secrets GitHub Action](https://github.com/step-security/wait-for-secrets) by [StepSecurity](https://www.stepsecurity.io) and [Wombat Dressing Room](https://github.com/GoogleCloudPlatform/wombat-dressing-room) by [GCP](https://opensource.googleblog.com/2020/01/wombat-dressing-room-npm-publication_10.html). Unfortunately, in this model the maintainer must provide their npm credentials to a third party server, or set up their own server. |
(wdr requires you to set up your own server)
|
|
||
| In the npm ecosystem, the closest equivalent to a SBOM is the package-lock.json file. This file contains an exact description of the JavaScript package’s fully resolved hierarchical package dependency tree as found in the node\_modules folder. It is automatically generated when npm performs an action that adds, updates, or removes a dependent package (ie: when node\_modules is modified). | ||
|
|
||
| It is not possible to publish the package-lock.json to the npm Registry in its standard file location and it is not used by npm when package consumers resolve that package’s dependencies. It is typically stored in the source repository and serves as a reference of a given local environment’s hierarchical package dependency tree. |
There was a problem hiding this comment.
Suggested change
| It is not possible to publish the package-lock.json to the npm Registry in its standard file location and it is not used by npm when package consumers resolve that package’s dependencies. It is typically stored in the source repository and serves as a reference of a given local environment’s hierarchical package dependency tree. | |
| It is not possible to publish the `package-lock.json` to the npm Registry in its standard file location and it is not used by npm when package consumers resolve that package’s dependencies. It is typically stored in the source repository and serves as a reference of a given local environment’s hierarchical package dependency tree. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.