Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SBOM/SPDX Generation: Add CPE information for CVE security s… #102

Merged
merged 3 commits into from
Apr 8, 2024

Conversation

timesys-nathan
Copy link
Contributor

This commit adds Common Platform Enumeration (CPE) information to the ouput SPDX files during SBOM generation.

This information is used by CVE security scanners (Timesys Vigiles, Intel's cve-bin-tool, etc)

Specifically, it appears FreeRTOS has 3 relevant CPEs which are currently active in the NVD:

FreeRTOS-Kernel -> o:amazon:freertos
mbedtls -> a:arm:mbed_tls
llhttp -> a:llhttp:llhttp

So, I've added the ability to map these package names to the corresponding CPE strings in the NVD.

If additional CPEs are added to the NVD in the future, the lookup dictionary will need adjusted accordingly. Some of the assumed regex logic may also need adjusted in that case. In its current state, it does correctly work for all three package names.

I have tested this commit via:

  1. Unzipping latest FreeRTOS release and cloning in the CI-CD-Github-Actions repo:
$ wget https://github.com/FreeRTOS/FreeRTOS/releases/download/202212.01/FreeRTOSv202212.01.zip
$ unzip FreeRTOSv202212.01.zip
$ cd FreeRTOSv202212.01
$ git clone https://github.com/FreeRTOS/CI-CD-Github-Actions.git
  1. Using cve-bin-tool from this Pull Request, as it adds support for CPE identification in the ExternalRef feat: add support for CPE field in SPDX document intel/cve-bin-tool#3683
$ git clone https://github.com/tgagneret-embedded/cve-bin-tool.git --branch feature/add_cpe_support_for_spdx
Install into venv:
$ cd cve-bin-tool
$ python3 -m venv venv
$ source ./venv/bin/activate
$ python3 setup.py install
$ cd ..
  1. Testing for FreeRTOS-Kernel
$ export GITHUB_REPOSITORY="FreeRTOS/FreeRTOS-Kernel"
$ python3 CI-CD-Github-Actions/sbom-generator/scan_dir.py --source-path=FreeRTOS/Source/ --repo-root-path=FreeRTOS/Source/
$ cat sbom.spdx

Which shows the additional ExternalRef info being added to FreeRTOS-Kernel:

PackageName: FreeRTOS-Kernel
SPDXID: SPDXRef-Package-FreeRTOS-Kernel
PackageVersion: v10.5.1
ExternalRef: PACKAGE_MANAGER purl pkg:https://github.com/FreeRTOS/FreeRTOS-Kernel/tree/v10.5.1
ExternalRef: SECURITY cpe23Type cpe:2.3:o:amazon:freertos:10.5.1:*:*:*:*:*:*:*
PackageDownloadLocation: https://github.com/FreeRTOS/FreeRTOS-Kernel/tree/v10.5.1
PackageLicenseDeclared: MIT
PackageLicenseConcluded: MIT
PackageLicenseInfoFromFiles: NOASSERTION
FilesAnalyzed: True
PackageVerificationCode: 8ac06e08254f9afe48688062010c0a6543b7d3ab
PackageCopyrightText: NOASSERTION
PackageSummary: NOASSERTION
PackageDescription: FreeRTOS Kernel.

For the sake of finding some CVEs, I know 10.4.1 has a few. So I switched 10.5.1 to 10.4.1 and ran:

$ cve-bin-tool --sbom spdx --sbom-file sbom.spdx

This shows:

image

  1. Testing for mbedtls
$ cd ./FreeRTOS-Plus/Source/corePKCS11/source/dependency/3rdparty/ && git clone https://github.com/ARMmbed/mbedtls.git
$ cd -
$ export GITHUB_REPOSITORY="FreeRTOS/corePKCS11"
$ python3 CI-CD-Github-Actions/sbom-generator/scan_dir.py --repo-root-path=./FreeRTOS-Plus/Source/corePKCS11/ --source-path=./FreeRTOS-Plus/Source/corePKCS11
$ cat sbom.spdx

This then shows the ExternalRef info for mbedtls:

PackageName: mbedtls
SPDXID: SPDXRef-Package-mbedtls
PackageVersion: v2.28.0
ExternalRef: PACKAGE_MANAGER purl pkg:https://github.com/ARMmbed/mbedtls.git
ExternalRef: SECURITY cpe23Type cpe:2.3:a:arm:mbed_tls:2.28.0:*:*:*:*:*:*:*
PackageDownloadLocation: https://github.com/ARMmbed/mbedtls.git
PackageLicenseDeclared: Apache-2.0
PackageLicenseConcluded: Apache-2.0
PackageLicenseInfoFromFiles: NOASSERTION
FilesAnalyzed: True
PackageVerificationCode: a44f4412510e59d7fafbf2d4fb078c6744ec802d
PackageCopyrightText: NOASSERTION
PackageSummary: NOASSERTION
PackageDescription: NOASSERTION

Running this through cve-bin-tool:

$ cve-bin-tool --sbom spdx --sbom-file sbom.spdx

Produces:

image

  1. Testing for llhttp
$ export GITHUB_REPOSITORY="FreeRTOS/coreHTTP"
$ python3 CI-CD-Github-Actions/sbom-generator/scan_dir.py --repo-root-path=./FreeRTOS-Plus/Source/Application-Protocols/coreHTTP --source-path=./FreeRTOS-Plus/Source/Application-Protocols/coreHTTP/source
$ cat sbom.spdx 

This then shows the proper ExternalRef info again:

PackageName: llhttp
SPDXID: SPDXRef-Package-llhttp
PackageVersion: release/v6.0.5
ExternalRef: PACKAGE_MANAGER purl pkg:https://github.com/nodejs/llhttp.git
ExternalRef: SECURITY cpe23Type cpe:2.3:a:llhttp:llhttp:6.0.5:*:*:*:*:*:*:*
PackageDownloadLocation: https://github.com/nodejs/llhttp.git
PackageLicenseDeclared: MIT
PackageLicenseConcluded: MIT
PackageLicenseInfoFromFiles: NOASSERTION
FilesAnalyzed: True
PackageVerificationCode: bfac4ff9c42417c7badf60c15e2f1d2e9a104f03
PackageCopyrightText: NOASSERTION
PackageSummary: NOASSERTION
PackageDescription: NOASSERTION

Feeding this through cve-bin-tool again:

$ cve-bin-tool --sbom spdx --sbom-file sbom.spdx

Produces:
image

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@ActoryOu
Copy link
Member

ActoryOu commented Mar 22, 2024

Thank you for creating this PR. We will look into this PR and discuss with you here.

@archigup
Copy link
Member

Hi, thanks for the PR! I'd like some more information.

Reading through the documentation, it seems that is not a valid way to set PURL? Looking at https://github.com/package-url/purl-spec seems it needs to a from a package manager. Do we need to set the PURL? It seems most docs suggest setting one of the identification options, so setting just CPE should be correct?

Also found these docs for CPE:
https://cpe.mitre.org/files/cpe-specification_2.2.pdf
https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir7695.pdf

Seems CPE is marked legacy? Not sure what is meant by that; is this a still supported thing?

Also I see the PR for that tool is still open? Is it going to be merged? Are there tools currently deployed that use this?

Is there somewhere where I can see what CPEs exist and query them online?

@timesys-nathan
Copy link
Contributor Author

@archigup

Removed PURL from the commit, as it is indeed not entirely necessary [see force push above].

We'll respond to other questions later today.

@timesys-nathan timesys-nathan changed the title SBOM/SPDX Generation: Add CPE and purl information for CVE security s… SBOM/SPDX Generation: Add CPE information for CVE security s… Mar 25, 2024
@nodeax
Copy link
Contributor

nodeax commented Mar 25, 2024

Reading through the documentation, it seems that is not a valid way to set PURL? Looking at https://github.com/package-url/purl-spec seems it needs to a from a package manager. Do we need to set the PURL? It seems most docs suggest setting one of the identification options, so setting just CPE should be correct?

Agree PURL does not make sense here. CPE is sufficient.

Also found these docs for CPE: https://cpe.mitre.org/files/cpe-specification_2.2.pdf https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir7695.pdf

Seems CPE is marked legacy? Not sure what is meant by that; is this a still supported thing?

Yes, CPE is actively maintained by NIST as part of NVD. Any tool using NVD to report CVE's pretty much relies on the CPE information to map CVE's to packages in a SBOM.
https://nvd.nist.gov/products/cpe

Also I see the PR for that tool is still open? Is it going to be merged?

The community is actively working on it. I don't see any reason for this to not get merged. That said the intel cve-bin-tool was only an example.

Are there tools currently deployed that use this?

Yes, pretty much any tool that relies on NVD to report vulnerabilities should support it.
Taking grype as an example with the corePKCS11 SBOM:

$ cat sbom.spdx |grep -i cpe
ExternalRef: SECURITY cpe23Type cpe:2.3:a:arm:mbed_tls:2.28.0:*:*:*:*:*:*:*
$ grype sbom:sbom.spdx
 ✔ Vulnerability DB                [no update available]  
 ✔ Scanned for vulnerabilities     [10 vulnerability matches]  
   ├── by severity: 2 critical, 5 high, 3 medium, 0 low, 0 negligible
   └── by status:   0 fixed, 10 not-fixed, 0 ignored 
[0000]  WARN attempted CPE search on corePKCS11, which has no CPEs. Consider re-running with --add-cpes-if-none
[0000]  WARN attempted CPE search on pkcs11, which has no CPEs. Consider re-running with --add-cpes-if-none
NAME     INSTALLED  FIXED-IN  TYPE  VULNERABILITY   SEVERITY 
mbedtls  v2.28.0                    CVE-2022-46393  Critical  
mbedtls  v2.28.0                    CVE-2022-35409  Critical  
mbedtls  v2.28.0                    CVE-2024-23775  High      
mbedtls  v2.28.0                    CVE-2023-52353  High      
mbedtls  v2.28.0                    CVE-2023-43615  High      
mbedtls  v2.28.0                    CVE-2021-45451  High      
mbedtls  v2.28.0                    CVE-2021-43666  High      
mbedtls  v2.28.0                    CVE-2024-23170  Medium    
mbedtls  v2.28.0                    CVE-2022-46392  Medium    
mbedtls  v2.28.0                    CVE-2021-36647  Medium

There are many commercial tools as well. Timesys Vigiles being one.

image

Synopsys BlackDuck is a popular commercial tool that supports CPEs as stated here.

Is there somewhere where I can see what CPEs exist and query them online?

https://nvd.nist.gov/products/cpe/search
https://nvd.nist.gov/products/cpe

mbedtls cpe, freertos cpe

Copy link
Member

@archigup archigup left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the info! LGTM

@Skptak Skptak mentioned this pull request Apr 4, 2024
@Skptak Skptak merged commit d3e8d69 into FreeRTOS:main Apr 8, 2024
50 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants