Software Bill of Materials: VersionVault Auditing

On May 12, 2021, the White House issued an executive order, ”Executive Order on Improving the Nation’s Cybersecurity”.  It extends many policies and best practices required by security-sensitive agencies (ex. Department of Defense) broadly across the Federal Government.  The focus of this post is Section 4(e) (part of “Enhancing Software Supply Chain Security”), in particular, collecting/generating information to create a Software Bill of Materials (SBOM) and providing traceability to prove provenance (origin/pedigree).  This will soon affect all commercial suppliers of software to Federal Agencies. 

Software Bill of Materials 

A Software Bill of Materials (SBOM) is “a formal record containing the details and supply chain relationships of various components used in building software.”  At a high level, any software system must be able to answer the key questions about any component included.  What, where, who, when, and how? 

• What is the component? 
• What is the version of the component? 

• What versions of source code (and other dependencies) were used to build the component (if not obtained externally)? 
• Where was the component obtained from? 
• Who developed/built/obtained the component? 
• When was the component built/obtained? 
• How was the component built/obtained? 

Although a documented process for collecting, securing, and structuring this information is important, automation of as much as possible eases the burden, increases consistency, and provides evidence that the process was faithfully followed. 

VersionVault Authoritative Build Auditing 

VersionVault has a unique capability that creates an authoritative audit record (called a “configuration record”, or “config rec”) for any artifacts (called “derived objects”) created during a build. These config recs provide detailed traceability back to exact versions of any files from a VOB (VersionVault repository) involved with the build and answers to the questions noted above.  This is only possible because of the VersionVault MVFS (Multi Version File System), a kernel file system that monitors all file system operations during a build and records which files were accessed and/or modified.  Because the MVFS is an integral part of the both the kernel and the version control subsystem of VersionVault, it not only knows which files were accessed and/or modified, it knows the precise version(s) of controlled files that were involved.  Thus, VersionVault config recs provide an authoritative audit record of what file versions were actually involved with a build.  The best other systems can do is report what file versions should have been involved with a build.  This unique capability is used heavily in regulated industries (often including non-software artifacts, too) and provides high value to almost any product targeting a Federal Agency in the future. 

Example Build Audit Report 

Here is a subset of the report generated from a config rec created during a VersionVault audited build: 

Derived object: /vobs/atria/lib/cm/sun5/cfs_parse.o@@15-May-01.423710 
Target cfs_parse.o built by hack.user 
Host “picloram” running SunOS 5.6 (sun4u) 
Reference Time 15-May-01.18:08:22, this audit started 15-May-01.18:08:23 
View was picloram:/export/home/hack/views/hack_v5.0.bl1 
Initial working directory was /vobs/atria/lib/cm/sun5 
 

/vobs/atria/lib/cm/cfs.h@@/main/ucm_main/1           <15-Jan-00.16:46:18> 
/vobs/atria/lib/cm/cfs_parse.c@@/main/ucm_main/18           <15-May-01.18:07:12> 
/vobs/atria/lib/cm/sun5/cfs.ugh@@13-Oct-2000.200095 
/vobs/sys/SOLARIS/sun5.5.1/usr/include/stdio.h@@/main/1 <02-May-96.23:18:04> 
/vobs/sys/SOLARIS/sun5.5.1/usr/ccs/bin/yacc@@/main/2 <31-Jan-00.16:35:26> 
. 
. 
. 
—————————- 
Variables and Options: 
—————————- 
SRC=.. 
YACC=/vobs/sys/SOLARIS/sun5.5.1/usr/ccs/bin/yacc 
—————————- 
Build Script: 
—————————- 
@echo making cfs_parse.o 
rm -f y.tab.c y.tab.h cfs_parse.c cfs_parse.h cfs_parse.o y.output cfs_parse.y.output 
/vobs/sys/SOLARIS/sun5.5.1/usr/ccs/bin/yacc -dvt ../cfs_parse.y 

Using this report generated from the audited build, we can directly answer the following: 

• What is the component?   
  Answer:  Derived object: /vobs/atria/lib/cm/sun5/cfs_parse.o@@15-May-01.423710 
• What is the version of the component? 
  Answer:  15-May-01.423710 

• What versions of source code (and other dependencies) were used to build the component? 
  Answer:   
  /vobs/atria/lib/cm/cfs.h@@/main/ucm_main/1           <15-Jan-00.16:46:18> 
  /vobs/atria/lib/cm/cfs_parse.c@@/main/ucm_main/18           <15-May-01.18:07:12> 
  /vobs/atria/lib/cm/sun5/cfs.ugh@@13-Oct-2000.200095 
  /vobs/sys/SOLARIS/sun5.5.1/usr/include/stdio.h@@/main/1 <02-May-96.23:18:04> 
  /vobs/sys/SOLARIS/sun5.5.1/usr/ccs/bin/yacc@@/main/2 <31-Jan-00.16:35:26> 
• Where was the component obtained from? 
  Answer:  
  View was picloram:/export/home/hack/views/hack_v5.0.bl1 
  Initial working directory was /vobs/atria/lib/cm/sun5 
• Who developed/built/obtained the component? 
  Answer:  Target cfs_parse.o built by hack.user 
  (User ‘hack’ in group ’user’ built the component) 
• When was the component built/obtained? 
  Answer:  Reference Time 15-May-01.18:08:22, this audit started 15-May-01.18:08:23 
• How was the component built/obtained? 
  Answer: 
  —————————- 
  Build Script: 
  —————————- 
  @echo making cfs_parse.o 
  rm -f y.tab.c y.tab.h cfs_parse.c cfs_parse.h cfs_parse.o y.output cfs_parse.y.output 
  /vobs/sys/SOLARIS/sun5.5.1/usr/ccs/bin/yacc -dvt ../cfs_parse.y 

VersionVault automatically captured all this key information (plus more) during the build including the exact versions of ‘cfs.h’, ‘cfs_parse.c’, ‘stdio.h’, and ‘yacc’ that were used. 

Build Artifact Hierarchies 

A derived object (build artifact) might depend on another derived object.  In the example above, “/vobs/atria/lib/cm/sun5/cfs.ugh@@13-Oct-2000.200095” is another derived object built earlier.  In Java, a ‘.jar’ derived object would depend on all of the included ‘.class’ derived objects built earlier by the Java compiler.  VersionVault can generate an audit report for any individual derived object or traverse the entire hierarchy of derived objects. 

3rd-party Components 

It is frequently said, “Put everything in a VOB!”  From the example above, one of the reasons may be readily apparent.  Note the following from the config rec: 

/vobs/sys/SOLARIS/sun5.5.1/usr/include/stdio.h@@/main/1 <02-May-96.23:18:04> 
/vobs/sys/SOLARIS/sun5.5.1/usr/ccs/bin/yacc@@/main/2 <31-Jan-00.16:35:26> 

Even the system header files (ex. ‘stdio.h’) and build tools (ex. ‘yacc’) are in a VOB.  This practice provides authoritative traceability back to all 3rd-party dependencies. 

Provenance information should be captured and included as part of importing 3rd-party components into a VOB so all key information for an SBOM can be obtained from VersionVault build audit reports combined with the checked in provenance information. 

Management of 3rd-party components will be covered in a separate topic. 

Summary 

Cybersecurity will only continue to grow in importance.  As the guidelines for meeting Federal Agency requirements are published, will your product be ready?  VersionVault’s unique authoritative build auditing and reporting capabilities solve the data collection and traceability challenge to enable reliable generation of SBOMs. 

For more information, visit https://www.hcltechsw.com/versionvault and consider requesting a product demo. 

For Further Reading 

• NISTIR 8060 – “Guidelines for the Creation of Interoperable Software Identification (SWID) Tags” 
• NTIA (National Telecommunications and Information Administration) – “Software Identification Challenges and Guidance”