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/wps/portal/products/versionvault and consider requesting a product demo. 

For Further Reading 

Comment wrap
Further Reading
article-img
Secure DevOps | May 25, 2021
Principles and Techniques for HCL VersionVault Performance Analysis
This article on principles and techniques for improving HCL VersionVault performance, provides an overview of the principles of performance assessment and advice on how to apply them in an HCL VersionVault environment.
article-img
Secure DevOps | April 28, 2021
Choosing a Software Configuration System Part 3
Explore the characteristics of development projects to consider when choosing a Software Configuration Management system.
article-img
Secure DevOps | April 7, 2021
Choosing a Software Configuration Management System
This is the first in a series of blog posts exploring characteristics of development projects to consider when choosing a Software Configuration Management system. A Software Configuration Management (SCM) system is an essential part of almost any effective software development project. It can provide solutions to different challenges faced by the many roles in a development team. These roles include software engineers/developers, project leaders, release engineers, process engineers, engineering managers, and even engineering executives.    Although all software development projects share many common characteristics, the differences between the projects often dictate the degree of sophistication needed in the underlying development tools. Characteristics that drive the need for a highly sophisticated SCM system can include projects with numerous developers, project teams spread across many different physical locations, projects dealing with a huge software system, projects needing tightly controlled security, projects with complex process automation and enforcement requirements, and projects subject to critical regulatory requirements. If you think of increasing sophistication represented by a series of layers, or strata, each of the aforementioned characteristics can push a project into higher strata. Many SCM systems can satisfy the needs in the lower strata.  Few are powerful enough and flexible enough to handle the higher strata. HCL VersionVault is without doubt, the most flexible SCM system in the world. It supports a wide variety of deployment models for local or globally distributed teams; provides a simple process model as well a highly customizable option; includes a wide variety of powerful graphical user interfaces (GUIs) in addition to a comprehensive command line interface (CLI); provides unique build tools that generate a detailed audit trail and enable high-speed parallel builds; and integrates with a wide variety of other tools including Eclipse, Microsoft Visual Studio, Cadence Virtuoso, workflow and lifecycle management/engineering tools, etc. POSSIBLE PROJECT NEEDS TO CONSIDER An SCM...
Close