Third Party Code and Components
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
deptool
Node
npm list
Python
pip freeze
Ruby
gem dependency
Lua
See the
rockspec file
Java
mvn dependency:treegradle app:dependencies
Yocto
buildhistory
Buildroot (free)
make legal-info
Package Managers (free)
dpkg --listrpm -qayum listapt list --installed
RetireJS for Javascript projects (free)
A sample BOM is shown below:
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:
Find your installed-packages.txt from your yocto build. For information on that see: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#understanding-what-the-build-history-contains
As of Yocto 2.2 Morty, a built-in cve-check BitBake class was added to help automate checking of recipes against public CVEs at build time. See the following Yocto page for additional details: https://docs.yoctoproject.org/dev/dev-manual/vulnerabilities.html
Considerations (Disclaimer: The List below is non-exhaustive):
Use of retire.js for JavaScript Libraries
Utilize
npm auditfor NodeJS packages
Use OWASP DependencyCheck for detecting publicly disclosed vulnerabilities in application dependencies and file types.
Use
safety checkfor scanning python related packages for known vulnerabilitiesUse of OWASP ZAP for web application testing
Utilize tools such as Lynis for basic Kernel hardening auditing and suggestions.
wget --no-check-certificate https://github.com/CISOfy/lynis/archive/master.zip && unzip master.zip && cd lynis-master/ && bash lynis audit systemReview the report in:
/var/log/lynis.logNote: 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.)
Utilize free library scanners such as LibScanner which searches through a project's dependencies and cross references them with the NVD looking for known CVEs for a yocto build environment.
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.
Additional References
Last updated