Login   |   1.866.392.4897 |   sales@timesys.com English Japanese German French Korean Chinese (Simplified) Chinese (Traditional)
VigiShield Secure By Design for Yocto

VigiShield Secure By Design for Yocto


The Yocto Project is a popular choice for creating custom Linux distributions for IoT devices. When creating a custom Linux distribution one of the key challenges faced by device manufacturers is the time and expertise required to secure the distribution. Having helped multiple device manufacturers through this journey, Timesys now offers a standard product called “VigiShield Secure by Design.”  This is available as a yocto layer (meta-vigishield) that delivers out-of-the box security to your Yocto-based Linux distribution. VigiShield implements the OS security features covering various security standards such as NISTIR 8259A, ETSI EN 303 and has obtained a PSA Level 1 certification through an independent security lab evaluation. By leveraging VigiShield, device manufacturers can now focus on their value-added applications instead of worrying about security.


Security Features Implemented by VigiShield


Secure boot and chain of trust

A key aspect of security is ensuring only authentic software runs on the device (i.e. malicious software is prevented from running). To achieve this, each piece of software is digitally signed at the time of building the software and the signature is verified on the device before executing that piece of software. If the signature check fails, the software is not allowed to run. The authentication of the first piece of user software i.e. bootloader is referred to as “Secure boot” and extending the authentication to all other software including user space applications is referred to as “Chain of Trust.”
Note: To achieve secure boot, there is a dependency on the hardware needing to support it.

VigiShield supports secure boot and chain of trust on various hardware platforms. Taking the NXP i.MX8 processor series as an example, VigiShield integrates and configures the code signing tools provided by NXP to create signed bootloader images as part of the build. All pieces of software that are loaded after the bootloader are signed and verified using open source technologies. For example, the kernel, device tree and initramfs (optional) are all bundled in as a signed fitImage and verified by the bootloader. Similarly a signed read-only root filesystem is authenticated using the Linux kernel dm-verity mechanism.

Resources: Secure boot and chain of trust blog, Faster secure boot blog. Webinar


Secure Storage

Secure storage ensures data confidentiality (e.g: keeps customer/application data private), prevents IP-theft, and prevents cloning/counterfeiting of the device. Data is secured by means of encryption and the encryption key is typically protected by a hardware specific mechanism.

VigiShield provides full disk encryption using the Linux dm-crypt mechanism and the encryption key is kept confidential by a hardware/processor root of trust (hardware unique key). For example, the VigiShield implementation on the i.MX8 processors achieves this by creating an encrypted blob which is protected by a unique master key residing in the one-time programmable fuses of the processor. Only authorized software can request that the processor perform decryption through the hardware cryptography engine.

Resources: Encrypted Data storage blog


Secure updates

Software/firmware updates are required in order to provide security or feature updates to devices. Secure Updates ensures that only authentic and legitimate firmware is  updated on the device.

VigiShield provides a secure and robust over-the-air (OTA) solution. This includes OTA server authentication using certificates, secure downloads over TLS1.3, installation of signed / authenticated images using Public-key cryptography (PKCS #1.5 signature validation, using 2048 bits RSA key with SHA256) and prevention of unauthorized rollback (anti-rollback) of images. Apart from authenticating the firmware update bundle, the individual images (e.g: bootloader, kernel etc.) are authenticated as part of secure boot as described in the previous section.

VigiShield uses the SWUpdate open source solution for OTA updates with an A/B update scheme. However, through our VigiShield professional services team, we can customize OTA updates to use other solutions such as OS-Tree, Mender and RAUC; all with the same set of security features.

Resources: Designing OTA Updates webinar


Secure communication

Secure communication protects the data-in-transit when the device communicates with external devices (e.g: cloud servers, remote sensors, etc). Secure communication is achieved using authentication between all involved parties and encrypting the data transmitted between them.

VigiShield secures external communication to/from the device by using secure protocols such as TLS1.3, which are implemented as part of open source libraries such as openSSL. The certificates/keys used to authenticate any external communication are stored in the encrypted and authenticated secure storage, to avoid any potential tampering. VigiShield further reduces the attack surface by disabling many known weak/insecure ciphers in openSSL.


Security audit logs

Security audit logs record any runtime security violations/breaches on the target system. Security events such as unauthorized access to sensitive files, opening of network connections, failed login etc. are typically logged to an access controlled, integrity protected log file for further investigation.

VigiShield supports logging security violations on the target system using the Linux audit framework and open source auditd user space utility. The log file access is restricted to root users and any unauthorized access to the logs are also recorded. VigiShield comes with baseline logging capability and can be customized to monitor specific security events based on end user requirements.

Resources: Logging with auditd blog


Secured ports

Incorporating hardware security is critical to mitigate physical attacks on the device. VigiShield can be easily configured to disable and/or password protect interfaces such as serial port and JTAG.



Security hardening is the act of reducing the attack surface of the device and making the device more difficult to hack. VigiShield implements a variety of system hardening techniques.

  • Toolchain hardening: The toolchain used to build the target device binaries has security flags to make exploiting vulnerabilities difficult. VigiShield enables toolchain options such as stack protection, buffer overflow checks, position independent executables etc. 
  • Kernel hardening: The Linux kernel hardening is a broad topic since there are a myriad of security features, hardening options, and mitigations for known exploits that can be enabled via the Linux kernel configuration. VigiShield provides a detailed kernel hardening report of the recommended hardening options based on your hardware architecture and kernel version; along with a base set of options pre-enabled.
    Resources: Kernel hardening blog, webinar
  • U-boot hardening: VigiShield can help mitigate a wide range of threats such as tampering u-boot environment variables, overriding boot commands, access of serial console, etc.
    Resources: Securing U-Boot blog
  • Userspace hardening: If software such as dropbear/openssh are included on the target device, VigiShield hardens the software by disabling root access, enforces key based authentication instead of passwords, etc.
  • Best practice cryptography: VigiShield disables a wide range of legacy / insecure OpenSSL ciphers by default.
  • Access control: Vigishield is configured to have no root login or default hardcoded passwords. As part of VigiShield, a discretionary access control report is generated detailing the permissions of each file in the filesystem. For example, details on the actions that users and groups can perform on a file: read, write, execute.
    Resources: Discretionary Access Control blog


SBOM and vulnerability report

Software Bill of Materials (SBOM) is an essential component for performing vulnerability or license analysis, both of which play an important role in software supply chain risk management.

VigiShield includes SBOM generation (SPDX), vulnerability (CVE) monitoring and management as part of Timesys Vigiles free tier offering.

Resources: Vigiles SBOM and vulnerability management


VigiShield Add-ons

Yocto/BSP and Security Customizations
Apart from the standard PSA certified VigiShield offering, we provide customizations as part of our Professional Services which covers hardware enablement, Yocto customizations, custom security feature implementations, integration with device management / IoT cloud services, and more!

Security Training
Whether you are new to security, looking for consultation to refine your security requirements or help integrating our solutions into your processes; we can help with our customized security training offerings.

Secure manufacturing assistance
We have expertise in developing the manufacturing tooling required for secure software programming and provisioning. We can help integrate your custom or 3rd party solutions for securely storing device certificates.

Trusted Applications for Secure OS
For customers seeking enhanced security, we have expertise in implementing “trusted applications” that can be deployed on a secure OS (e.g: OP-TEE, Trusty, etc) running on a trusted execution environment.
Resources: Trusted Software with OP-TEE blog, webinar

Long Term Linux OS security and maintenance
Timesys Linux OS/BSP Maintenance subscription service provides long-term security updates and maintenance of your Linux OS. Using this service, device manufacturers can rely on timely security updates that can be deployed to devices in the field with the secure and robust OTA update mechanism included in VigiShield.



The DIY route of securing a Yocto-based distribution is a tedious process and adversely affects the time-to-market for device manufacturers. Worse yet, without the right expertise and independent 3rd-party evaluation, devices might still be at risk. By leveraging off-the-shelf, security certified products such as VigiShield, device manufacturers can now bring more secure devices to the market faster and at a lower cost. To learn more, schedule a free security consultation.

Yocto Security: Automating compliance using OpenSCAP

Yocto Security: Automating compliance using OpenSCAP

The Security Content Automation Protocol (SCAP) is a method of using certain interoperable security standards to automate evaluating policy compliance of deployed systems.

In order to scan a system for compliance or vulnerabilities, there are two components involved:

  • SCAP content, typically consists of a list of rules to audit
  • SCAP scanning tool that can interpret the SCAP content to perform the check on the system and optionally remediate

To illustrate using a practical example, a security requirement can mandate not storing any plain text passwords in a file. This requirement can be encoded as a rule using one of the specifications under SCAP, for example Open Vulnerability and Assessment Language (OVAL). Then to perform a scan of the system to assess compliance, a SCAP compatible tool such as OpenSCAP scanner can be used to read the SCAP content (e.g. OVAL file) and report the assessment in a standardized format.

The SCAP content is generally developed by software vendors and/or device manufacturers, sometimes in conjunction with authorities such as Center for Internet Security (CIS), Defense Information Systems Agency (DISA), National Institute of Standards and Technology (NIST) etc. There is a publicly available repository of pre-existing compliance checks and profiles based on industry standards such as PCI-DSS, HIPAA, DISA STIG, NIST SP 800-53 etc. This can be used as a baseline and any additional security requirements can be layered on top of the existing checks and/or profiles. While there are a lot of guides available on how to leverage SCAP on commercial / open source Linux distributions, the information regarding usage with custom Linux distributions is sparse. The next section is intended as a getting started guide for SCAP on embedded / IoT Linux devices using Yocto project as an example.

Getting started with OpenSCAP on Yocto

Yocto has a meta-security-compliance layer under meta-security that packages both SCAP scanner (OpenSCAP) and SCAP content (SCAP Security Guide). Using these packages a security audit of the target device (QEMU in this case) can be performed. 

To begin, follow the setup instructions on the OE-Core wiki page. Note: If you are using Poky or any other reference distro, there are some variables that need to be tweaked which will be covered later in this article.

Step 1: Get source code

git clone git://git.openembedded.org/openembedded-core oe-core
git clone git://git.yoctoproject.org/meta-security
git clone git://git.openembedded.org/meta-openembedded
git clone git://git.openembedded.org/bitbake oe-core/bitbake

Step 2: Build setup

source ./oe-core/oe-init-build-env
//Add the below lines to bblayers.conf
BBLAYERS += "${TOPDIR}/../meta-openembedded/meta-oe"
BBLAYERS += "${TOPDIR}/../meta-openembedded/meta-python"
BBLAYERS += "${TOPDIR}/../meta-security/meta-security-compliance"
//Add the below line to local.conf
IMAGE_INSTALL:append = " os-release openembedded-release oe-scap scap-security-guide "
bitbake core-image-minimal

SCAP for configuration checks

The scap-security-guide package includes a basic security profile which can be used to audit the system. This is a very minimal security rule set and is to be used for illustrative purposes only. Follow the below instructions to run the scan with the basic profile. 

Step 3: Run openscap scanner

//Start a qemu instance of the built image
//Run oscap on the qemu target console
# oscap xccdf eval --report basic-embedded.html --profile xccdf_org.ssgproject.content_profile_basic-embedded /usr/share/xml/scap/ssg/content/ssg-openembedded-ds.xml
Title   Verify All Account Password Hashes are Shadowed
Rule    xccdf_org.ssgproject.content_rule_accounts_password_all_shadowed
Result  pass
Title   Limit the Number of Concurrent Login Sessions Allowed Per User
Rule    xccdf_org.ssgproject.content_rule_accounts_max_concurrent_login_sessions
Result  notapplicable

Interpreting the report

The tool generates reports in multiple formats including a human friendly html file which can be viewed directly on the device or copied over to a host PC for viewing. Below is a screenshot of the sample report and if you want to play around with the actual report visit this link. 

The summary section gives a big picture view of the compliance results along with the severity of any failed checks. The rules overview section lets you filter based on the result status and search for specific rules. The other nice part is to filter based on a profile group, for example if you are trying to achieve a particular compliance e.g. HIPAA, you can pick that group and the results will be rearranged to automatically map the rules to the relevant section of the security standard. 

The “Result Details” section provides detailed information on each rule along with any applicable references to various compliance requirements mapping. The results section also provides details on what exactly was checked for and/or if a check was skipped.


SCAP for vulnerabilities assessment

Apart from using SCAP for configuration compliance checks, OpenSCAP can also be used to check if the software installed on the system is patched for known vulnerabilities (typically CVEs). Distributions such as Ubuntu provide an OVAL feed containing data about patched versions of software which can be used to audit the system. In case of “build your own distro” such as Yocto, BuildRoot, OpenWRT the team responsible for creating the distro would have to create such a feed. It is a cumbersome process and hence not widely used. However if one wishes to create such a feed, for Yocto users, the oe-scap package in the meta-security-compliance layer provides a reference example. Below is an illustration where the oscap tool is used to check if CVE-2017-7502 is patched in the nss package on the system. This can be further automated using the openscap daemon which can run on a periodic schedule.

# oscap xccdf eval /usr/share/oe-scap/OpenEmbedded_nodistro_0.xccdf.xml
Title   CPE-2017:1365: nss security and bug fix update (Important)
Rule    oval-com.redhat.rhsa-def-20171365
Ident   CVE-2017-7502
Result  pass

Customizing SCAP content

A good starting point for creating custom SCAP content is by leveraging the work already done by the community. The Compliance As Code project has pre-existing rules/checks/profiles available for Linux systems and a “new product” guide for creating custom content. The project already has profiles that map to various security standards that can be inherited for the new product being created as illustrated in this patch. Another place to look for public SCAP content is the NIST National Checklist Program.


Debugging failures

A commonly faced issue when running oscap is checks return as “notapplicable”. The most likely reason for this is because of a VERSION_ID mismatch. The default expected VERSION_ID is nodistro.0 as specified in the /etc/os-release file. The best way to debug such scenarios is to pass in the “–verbose DEVEL” argument when calling an oscap application on the target device. Depending on your Yocto version you might need this patch for correctly mapping the VERSION_ID. 

# cat /etc/os-release 
PRETTY_NAME="OpenEmbedded nodistro.0"

 The SCAP content can link multiple different specs within each other, hence it is useful to understand the linkage/dependencies. To inspect SCAP content, use the oscap info command and then trace the linked checklists/checks/dictionaries for any possible errors. The below example inspects a SCAP source data stream (DS) which encapsulates links to rule checklists (XCCDF), compliance check definitions (OVAL) and dictionaries to identify software (CPE).

# oscap info /usr/share/xml/scap/ssg/content/ssg-openembedded-ds-1.3.xml
Document type: Source Data Stream
Imported: 2018-03-09T12:34:56
Stream: scap_org.open-scap_datastream_from_xccdf_ssg-openembedded-xccdf-1.2.xml
Generated: (null)
Version: 1.3
	Ref-Id: scap_org.open-scap_cref_ssg-openembedded-xccdf-1.2.xml
		Status: draft
		Generated: 2019-07-06
		Resolved: true
	           Title: Basic Profile for Embedded Systems
			Id: xccdf_org.ssgproject.content_profile_basic-embedded
		Referenced check files:
			system: http://oval.mitre.org/XMLSchema/oval-definitions-5
			system: http://scap.nist.gov/schema/ocil/2
	Ref-Id: scap_org.open-scap_cref_ssg-openembedded-oval.xml
	Ref-Id: scap_org.open-scap_cref_ssg-openembedded-ocil.xml
	Ref-Id: scap_org.open-scap_cref_ssg-openembedded-cpe-oval.xml
	Ref-Id: scap_org.open-scap_cref_ssg-openembedded-cpe-dictionary.xml


Whether you are looking to embrace security automation or trying to meet regulatory compliance requirements, SCAP can play an important part of your security toolbox. Leveraging the OpenSCAP project, one can get a jumpstart in building secure devices that can be easily audited in an automated fashion. 

Learn more about Timesys security solutions for out of the box hardened OS profiles and vulnerability monitoring to automate your DevSecOps and meet compliance.

Akshay Bhat is CTO, Embedded Products and Services at Timesys. He oversees the strategic direction of Timesys’ technology roadmap. With more than 16 years of industry experience with embedded systems software development and security, Akshay’s focus is on Timesys solutions that transform the software development lifecycle for embedded and enable the development of embedded system products with stronger security. Akshay has authored numerous embedded Linux and industry articles and delivered several embedded systems security presentations. He received his MS in Electrical Engineering from NYU Polytechnic University.
The many challenges of Linux OS / BSP security maintenance

The many challenges of Linux OS / BSP security maintenance

Subscribe to our RSS
Share this on Facebook
Share this on Twitter
Share this on LinkedIn



The “upstream first” strategy is only half of the story for embedded devices

A recent blog post by Kees Cook, a Linux security expert and Google security engineer, illustrates the challenges in maintaining the security of the Linux kernel. One of the main takeaways from the blog is: “If you’re not using the latest kernel, you don’t have the most recently added security defenses (including bug fixes).”

Going the “upstream first” route is the absolute best way of keeping the kernel secure. However, it is only part of the story. The challenges faced by device manufacturers running on Linux on embedded devices is vastly different.


Evaluating vulnerability tools for embedded Linux devices

Evaluating vulnerability tools for embedded Linux devices

Subscribe to our RSS
Share this on Facebook
Share this on Twitter
Share this on LinkedIn



Monitoring and managing vulnerabilities in embedded Linux devices presents a unique set of needs that traditional IT vulnerability tools fail to address and result in wasted efforts chasing false positives and inefficiencies due to cumbersome workflows. After evaluating multiple IT cybersecurity tools, we at Timesys ended up creating a vulnerability management tool called Vigiles, which is optimized for embedded devices. This blog aims to share the lessons learned and how the right tool can bring your security maintenance cost down while improving the security posture of the device.


Best practices for triaging Common Vulnerabilities & Exposures (CVEs) in embedded systems: Top Three Questions Answered

Best practices for triaging Common Vulnerabilities & Exposures (CVEs) in embedded systems: Top Three Questions Answered

Subscribe to our RSS
Share this on Facebook
Share this on Twitter
Share this on LinkedIn



Keeping embedded system products secure requires ongoing, constant monitoring and management of Common Vulnerabilities and Exposures (CVEs) throughout the production lifecycle.

With the constant flood of CVEs reported each week, you need to have a process for understanding the exposure of your embedded system devices to cybersecurity exploits. It is important to see how CVEs apply to your product so you can quickly address the vulnerabilities that pose the greatest risk.


Vulnerability management and triaging

Vulnerability management and triaging

Subscribe to our RSS
Share this on Facebook
Share this on Twitter
Share this on LinkedIn



With 300+ vulnerabilities being reported weekly in the US National Vulnerability Database (NVD), it is more challenging than ever to maintain the security of open source and third-party software used in embedded system products. One common approach to tackle the problem is to adopt a risk-based vulnerability management strategy in which vulnerabilities that pose the highest risk to your organization are remediated first. This blog outlines how to establish such an process as part of your software development lifecycle while keeping the maintenance cost and risk of exposure low.


Webinar with NXP: CVE triage best practices for efficient vulnerability mitigation

Webinar with NXP: CVE triage best practices for efficient vulnerability mitigation

Subscribe to our RSS
Share this on Facebook
Share this on Twitter
Share this on LinkedIn



Securing your embedded system devices is no longer just a final step in product development.

Security today must be a continuous process, a focus at every stage of your software development, release and maintenance cycles.

That’s because today’s vulnerability environment is radically different from the past. Hundreds of vulnerabilities that may or may not affect your products come to light every week.


Vigiles Quick Start … because securing your products doesn’t have to be hard

Vigiles Quick Start … because securing your products doesn’t have to be hard

Subscribe to our RSS
Share this on Facebook
Share this on Twitter
Share this on LinkedIn



There is an old saying among cybersecurity vulnerability management practitioners:

The “good guys” have to get it right every time.

The “bad guys” have to get it right only once.

That means that the “good guys” — the security professionals whose mission is to keep corporate data safe — need to monitor, analyze and respond to every vulnerability that puts their systems, users and data at risk.


BSP Lifecycle Maintenance: Top Three Questions Answered

BSP Lifecycle Maintenance: Top Three Questions Answered

Subscribe to our RSS
Share this on Facebook
Share this on Twitter
Share this on LinkedIn



Security is critical throughout the lifetime of an embedded system. Continually changing threat environments, new deployment modes and third-party software updates mean that the BSP software for an embedded system device can no longer remain static and “frozen.”


Vigiles Enhancements: Software Composition Analysis (SCA) & CVE Mitigation for Stronger Embedded System Security

Vigiles Enhancements: Software Composition Analysis (SCA) & CVE Mitigation for Stronger Embedded System Security

Subscribe to our RSS
Share this on Facebook
Share this on Twitter
Share this on LinkedIn



A giant list of vulnerabilities does little to help you bring more secure products to market.

What matters is how you filter the list, triage the vulnerabilities, and mitigate the ones that pose the greatest risk.

That’s why the new enhancements to our Timesys Vigiles Security Monitoring & Management Service will enable you to develop more secure embedded system products today and maintain stronger product security throughout their lifecycles.


Click to Hide Advanced Floating Content

Keep your IoT device secure throughout its lifecycle