Sunday, March 21, 2021

extending software package data exchange into a bill of materials


In my, ahem, somewhat motley career in software development I recall the "Total Quality Management" (TQM) movement in the last millenium that evolved into ISO9000 and other horrors.  The recent trend in increasing successful and devastating cybercriminal attacks using software supply chains has resurrected a concept from TQM we called the bill of features (BOF) and bill of materials (BOM).  The BOF contained the customer-visible changes we were shipping to our software and the BOM was an exhaustive list of components in the software we shipped.  In our modern version control & configuration management systems, as well as their continuous integration and continuous deployment tools, we have most of the artifacts and tracking information;  we have automated away the tedium of BOF/BOM using tools and "git-ops" methods (oppa gitops style!).

In a recent medium post, Dr. Rispens suggests we use what he calls "blockchains" along with our package management and build systems to secure the bill of materials from supply chain attacks.  What he really means is that we should use a distributed ledger to store package component signatures to detect and prevent supply chain attacks.  Blockchains are overkill for this purpose.  I don't understand how this method would overcome source code submitted by bad actors that is merged into official component releases, complete with signatures, as was accomplished in the ssh1 open-ssl exploit or the recent node.js vulnerability.  BTW: some folks speculate the open-ssl exploit gave rise to boringssl.

Despite my criticisms, I think this idea does have some merit. Malicious source code submissions do provide a few forensics for the white hats to start characterizing the black hats and possibly identifying them.  The cost is low and the increase in transparency is desirable.

No comments: