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:// oe-core
git clone git://
git clone git://
git clone git:// 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
Generated: (null)
Version: 1.3
		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:


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.