This group brings together the best thinkers on energy and climate. Join us for smart, insightful posts and conversations about where the energy industry is and where it is going.

Post

We cannot secure the software supply chain without SBOM

image credit: Authors logo
Richard Brooks's picture
Co-Founder and Lead Software Engineer, Reliable Energy Analytics LLC

Dick Brooks is the inventor of patent 11,374,961: METHODS FOR VERIFICATION OF SOFTWARE OBJECT AUTHENTICITY AND INTEGRITY and the Software Assurance Guardian™ (SAG ™) Point Man™ (SAG-PM™) software...

  • Member since 2018
  • 1,540 items added with 672,957 views
  • May 24, 2021
  • 1670 views

A Software Bill of Materials (SBOM) has received considerable attention since the Cybersecurity Executive order was released on May 12, 2021 calling on government agencies to require SBOM’s from software vendors, “(vii)   providing a purchaser a Software Bill of Materials (SBOM) for each product directly or by publishing it on a public website

The Executive Order goes on to describe an SBOM, with an emphasis on it’s component inventory capabilities, “Software Bill of Materials” or “SBOM” means a formal record containing the details and supply chain relationships of various components used in building software”, “It is analogous to a list of ingredients on food packaging.

All of these claims are indeed accurate, however there is another essential and critically important element that SBOM’s provide, which is essential to secure the software supply chain; The identity of the software source supplier that produced and licensed the software, which can be verified using digital signing keys issued by trustworthy Certificate Authorities.

Current practices used in the software supply chain do not require identification of the actual software supplier and licensor of a software package. Some practices require that software packages be digitally signed, however there is no verification or validation that the signer of a software package and the supplier/licensor are related, or that the supplier/licensor has authorized a given party to sign a software object on their behalf. This creates a false sense of security when parties rely on tools such as Microsoft’s signtool to validate a digital signature. Signtool does not validate that a digital signature belongs to a party authorized to sign a software product on behalf of the original source supplier/licensor – it has no way of verifying that a given signer is authorized to digitally sign a software package. Signtool will report a valid signature if the cryptographic verifications and trust chain reports produce successful results, which do not verify the authorization of a signing party and supplier arrangement. This issue is similar to a past scenario where Certificate Authorities were issuing SSL certificates to domains without authorization to do so, which resulted in the implementation of DNS CAA (IETF RFC 6844) records to identify authorized parties to issue SSL certificates. A similar authorization scheme may be appropriate to authorize the issuance of digital certificates and signing keys to parties that have been authorized by a software supplier/licensor to sign software objects on their behalf.

The ability to determine trustworthiness is the key to securing the software supply chain. SBOM is the foundation for establishing this trust by specifying the identification of the actual source supplier/licensor of a software product. This supplier information can then be used to validate a digital signature applied to a software object by verifying the relationship of the software supplier and software signer using a trusted method to verify this relationship. A solution similar to DNS CAA, ref: “DNS Certification Authority Authorization (CAA) Resource Record”, IETF RFC 6844 may be worth exploring to address this need.

There is no doubt that securing the software supply chain requires a software consumer to verify the identity of a software source supplier and licensor of a software object. SBOM is a critical requirement in this process due to its standard method for identifying a software supplier/licensor of a software object. Having this SBOM supplier identifier will enable a software consumer to verify this party using digital signatures based on digital certificates issued by trusted Certificate Authorities.  What is missing today is a means to verify the authorization of a signing party by the software source supplier/licensor using trusted mechanisms, similar to RFC 6844. Perhaps, one day, we may see a DNS Digital Signature Authorization (DSA) record to meet this need.

Everyone in the Energy industry really needs to follow this wise guidance provided by NIST:

SP 800-161 R1: https://doi.org/10.6028/NIST.SP.800-161r1-draft  

SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY | CODE AUTHENTICATION

Supplemental C-SCRM Guidance: The organization should ensure that code authentication mechanisms such as digital signatures are implemented to assure the integrity of software, firmware, and information.

This NIST guidance, combined with Software Supplier Identification information contained in a digitally signed SBOM will go a long way to addressing software supply chain issues.

People interested in knowing the technical details showing an actual case where this Signer/Supplier mismatch was detected, and the risk this presents, can access the on-demand PowerTalk from 5/6 using the buttons below:

Access On-Demand Recording

   Access On-Demand Slides    

Never trust software, always verify and report!

Discussions

No discussions yet. Start a discussion below.

Richard Brooks's picture
Thank Richard for the Post!
Energy Central contributors share their experience and insights for the benefit of other Members (like you). Please show them your appreciation by leaving a comment, 'liking' this post, or following this Member.
More posts from this member

Get Published - Build a Following

The Energy Central Power Industry Network is based on one core idea - power industry professionals helping each other and advancing the industry by sharing and learning from each other.

If you have an experience or insight to share or have learned something from a conference or seminar, your peers and colleagues on Energy Central want to hear about it. It's also easy to share a link to an article you've liked or an industry resource that you think would be helpful.

                 Learn more about posting on Energy Central »