I may be completely misunderstanding this as I am new to the generation of a Software Bill of Materials (SBOM). But I am presently using Microsoft's SBOM tool, and while it handles 99% of all related software packages/libraries used in our product, there is one (a big one), that is not identifiable by the tool (I assume because it's locally installed and not out on NPM, etc.), and therefore is not included in the generated manifest.
The package in question is Sencha's Ext JS 6.0.3.41 (and related packages):
##[warning]Some components or files were not detected due to parsing failures or connectivity issues.
##[warning]Please review the logs above for more detailed information.
##[warning]Components skipped for "Npm" detector:
##[warning]- "ux - 6.0.3.41"
##[warning]- "soap - 6.0.3.41"
##[warning]- "legacy - 6.0.3.41"
##[warning]- "font-pictos - 6.0.3.41"
##[warning]- "font-ext - 6.0.3.41"
##[warning]- "font-awesome - 6.0.3.41"
##[warning]- "core - 6.0.3.41"
##[warning]- "charts - 6.0.3.41"
##[warning]- "amf - 6.0.3.41"
##[warning]- "theme-windows - 6.0.3.41"
##[warning]- "theme-triton - 6.0.3.41"
##[warning]- "theme-neptune - 6.0.3.41"
##[warning]- "theme-mountainview - 6.0.3.41"
##[warning]- "theme-device-base - 6.0.3.41"
##[warning]- "theme-cupertino - 6.0.3.41"
##[warning]- "theme-blackberry - 6.0.3.41"
##[warning]- "theme-base - 6.0.3.41"
##[warning]- "modern - 6.0.3.41"
##[warning]- "touch-sizing - 6.0.3.41"
##[warning]- "theme-neutral - 6.0.3.41"
##[warning]- "theme-neptune-touch - 6.0.3.41"
##[warning]- "theme-gray - 6.0.3.41"
##[warning]- "theme-crisp-touch - 6.0.3.41"
##[warning]- "theme-crisp - 6.0.3.41"
##[warning]- "theme-classic-sandbox - 6.0.3.41"
##[warning]- "theme-classic - 6.0.3.41"
##[warning]- "theme-aria - 6.0.3.41"
##[warning]- "locale - 6.0.3.41"
##[warning]- "classic - 6.0.3.41"
##[warning]- "ext - 6.0.3.41"
Since the tool can not auto-generate the appropriate entries, how should I go about creating them? I'm not sure how to generate a SPDXID value for them, though most of the other fields seem do-able. Are there any good resources on how to approach manual generation of SBOM entries in SPDX format in this sort of situation?
For example, using a version of Sencha Ext JS that is available on NPM, I get this:
{
"name": "@sencha/ext",
"SPDXID": "SPDXRef-Package-7290F3188D70A4EE3E6611F08999565DCD9F61F63596C5AFF2F0944C68263C17",
"downloadLocation": "NOASSERTION",
"filesAnalyzed": false,
"licenseConcluded": "NOASSERTION",
"licenseDeclared": "NOASSERTION",
"copyrightText": "NOASSERTION",
"versionInfo": "7.8.0",
"externalRefs": [
{
"referenceCategory": "PACKAGE-MANAGER",
"referenceType": "purl",
"referenceLocator": "pkg:npm/@sencha/[email protected]"
}
],
"supplier": "Organization: Sencha, Inc."
}
But where does 7290F3188D70A4EE3E6611F08999565DCD9F61F63596C5AFF2F0944C68263C17 come from? is it a GUID, a HASH, or something else? It's a bit unclear even after reviewing the SPDXID specs...
"{package_name} {package_version} - {package_type}", so in this case it would be"@sencha/ext 7.8.0 - Npm"which results in7290F3188D70A4EE3E6611F08999565DCD9F61F63596C5AFF2F0944C68263C17. Not t sure what to put in place ofNpmfor a local package though...Npmis a ComponentType, and in this case should be marked asOther, so the SHA256 would be generated off of@sencha/ext 6.0.3.41 - Otherand result inAFC471DD0060B4C04DB0718C9C72CC58053680480B3A122A018F29E4B3F4BECA