Third Party Code and Components
Last updated
Was this helpful?
Last updated
Was this helpful?
Following setup of the toolchain, it is important to ensure that the kernel, software packages, and third party libraries are updated to protect against publicly known vulnerabilities. Software such as Rompager or embedded build tools such as Buildroot should be checked against vulnerability databases as well as their ChangeLogs to determine when and if an update is needed. It is important to note this process should be tested by developers and/or QA teams prior to release builds as updates to embedded systems can cause issues with the operations of those systems.
Embedded projects should maintain a “Bill of Materials” of the third party and open source software included in its firmware images. This Bill of Materials should be checked to confirm that none of the third party software included has any unpatched vulnerabilities and also. Up to date vulnerability information may be found through the National Vulnerability Database or Open Hub.
Several solutions exist for cataloging and auditing third party software. Many solutions are built into your build environment such as:
C / C++
Makefile
Go
Use the official dep
Node
npm list
Python
pip freeze
Ruby
gem dependency
Lua
See the rockspec file
Java
mvn dependency:tree
gradle app:dependencies
Yocto
buildhistory
Buildroot (free)
make legal-info
Package Managers (free)
dpkg --list
rpm -qa
yum list
apt list --installed
RetireJS for Javascript projects (free)
A sample BOM is shown below:
Component
Version
Vulnerabilities - CVEs
Notes
jQuery
1.4.4
CVE-2011-4969
libxml2
2.9.4
CVE-2016-5131
To be fixed
Software BOM's also include licensing and contextual information relating to the function of the component or justification for using the specific version.
Retirejs in a JavaScript project directory Example:
Considerations (Disclaimer: The List below is non-exhaustive):
Utilize npm audit for NodeJS packages
wget --no-check-certificate https://github.com/CISOfy/lynis/archive/master.zip && unzip master.zip && cd lynis-master/ && bash lynis audit system
Review the report in: /var/log/lynis.log
Note: Lynis will bypass Kernel checks if a Linux kernel is not in use. The following error message will be in the logs: “Skipped test KRNL-5695 (Determine Linux kernel version and release number) Reason to skip: Incorrect guest OS (Linux only)”
Lynis should be modified accordingly if storage is limited (i.e. removing unnecessary plugins such as php etc.)
This tool outputs XML which enables teams to utilize such features for continuous integration testing.
Utilize package managers (opkg, ipkg, etc.. ) or custom update mechanisms for misc libraries within the toolchain.
Review changelogs of toolchains, software packages, and libraries to better determine if an update is needed.
Ensure the implementation of embedded build systems such as Yocto and Buildroot are set up in a way that allows for the update of all included packages.
Find your installed-packages.txt from your yocto build. For information on that see:
As of Yocto 2.2 Morty, a built-in cve-check was added to help automate checking of recipes against public CVEs at build time. See the following Yocto page for additional details:
Use of for JavaScript Libraries
Use for detecting publicly disclosed vulnerabilities in application .
Use for scanning python related packages for known vulnerabilities
Use of for web application testing
Utilize tools such as for basic Kernel hardening auditing and suggestions.
Utilize free library scanners such as which searches through a project's dependencies and cross references them with the NVD looking for known CVEs for a yocto build environment.