[Congressional Record Volume 160, Number 147 (Thursday, December 4, 2014)]
[Extensions of Remarks]
[Pages E1743-E1745]
From the Congressional Record Online through the Government Publishing Office [www.gpo.gov]




INTRODUCTION OF THE CYBER SUPPLY CHAIN MANAGEMENT AND TRANSPARENCY ACT 
                                OF 2014

                                 ______
                                 

                          HON. EDWARD R. ROYCE

                             of california

                    in the house of representatives

                       Thursday, December 4, 2014

  Mr. ROYCE. Mr. Speaker, I rise today to introduce the Cyber Supply 
Chain Management and Transparency Act of 2014, which is designed to 
address part of the matrix of ongoing vulnerabilities in our nation's 
government and cyber-infrastructure. This elegant approach emulates 
proven industry supply chain

[[Page E1744]]

methods to stimulate the greatest cyber security impact with the least 
cost or disruption.
  Mr. Speaker, with around ninety percent of a modern software 
application made up of open source components, the problem of deployed 
software containing open source components with known vulnerabilities 
is one of great concern.
  One report showed seventy-one percent of all software applications 
built today contain an open source component with at least one known, 
critical vulnerability--and some in the government contain hundreds. 
Exploits against vulnerable applications bypass firewalls in place. 
Worse, in most cases, exploiting them is as easy as pointing and 
clicking on a free, downloadable attack tool that does all the work for 
even unskilled adversaries.
  Mr. Speaker, the nation's economy needs open source software 
development and applications built with it. We could not survive in our 
modern economy without it.
  It is precisely because of the importance of open source components 
to modern software development, that we need to insure integrity in the 
open source supply chain, so vulnerabilities are not populated 
throughout the hundreds of thousands of software applications that use 
open source components.
  If a building contained a similar critical flaw, it could collapse, 
or if a car contained a known defective part, it could be lead to 
fatalities and need to be recalled.
  Given both widely known and less public (but quite damaging) open 
source supply chain attacks that have been in the news over the last 
year, it is essential that the U.S. government begin to protect its 
cyber infrastructure, the data, and safety of its citizens from 
defective open source code containing known vulnerabilities.
  Here is a short list of some of the recent cyber attacks based on 
open source vulnerabilities:
  In July of 2013, vulnerable open source Struts 2 components allowed 
most major U.S. banks to be breached.
  In addition to the highly publicized Heartbleed, 30 additional 
vulnerabilities in OpenSSL have been reported in 2014 alone. Several of 
these flawed components found their way into even critical 
infrastructure industrial controls (e.g. SIEMENS).
   The ``ShellShock''/``BashBug'' attacks against bash leveraged 
mistakes in ``bash'' not noticed for over two decades, but is now 
affecting applications and embedded devices--some incapable of being 
updated.
   In December 2013, 6,916 different organizations downloaded a version 
of httpclient with a broken ssl validation (CVE-2012-5783)--66,824 
times, more than one year after the NIST NVD alert.
   Bouncy Castle is an open source cryptography library used for 
applications requiring encryption. In 2013, 4,000 organizations 
downloaded a version of Bouncy Castle with a CVSS level 10 
vulnerability 20,000 times--despite a fix being available for the last 
seven years.
  Over the last year, the most often downloaded open source components 
with severity 10 (CVSS) NIST security defects, were downloaded by an 
average of 28 thousand organizations worldwide including all of the top 
ten Federal service providers (integrators). This means, these 28,000 
downloaded components by the top ten U.S. government software 
contractors are now in software being run by the Federal government 
(and this does not even include commercial software also leveraging 
known vulnerable third party and open source components). Some of these 
defective components are as old as 7 years, but they are still being 
leveraged.
  The CVE's in question are: CVE-2007-4575, CVE-2007-6721, CVE-2008-
5518, CVE-2010-2272, CVE-2010-2276, CVE-2012-0391, CVE-2012-0392, CVE-
2012-0838, CVE-2012-2379, CVE-2013-1777, CVE-2013-1965, CVE-2013-1966, 
CVE-2013-2115, CVE-2013-2134, CVE-2013-2135, CVE-2013-2251, CVE-2013-
4316 and CVE-2014-1202.
  Even one of the first founders of the open source movement was quoted 
in Wired Magazine, in an article titled, ``The Internet is Broken,'' 
under a section subtitled ``The Lie of Many Eyes'' putting some 
historic and practical perspective on the assertion that ``many eyes'' 
of open source component construction prevents vulnerabilities being 
introduced:

       ``For Robert Graham, the CEO of consultancy Errata 
     Security, Shellshock gives lie to a major tenet of open-
     source software: that open-source code permits ``many eyes'' 
     to view and then fix bugs more quickly than proprietary 
     software, where the code is kept out of view from most of the 
     world. It's an idea known as Linus's Law. ``If many eyes had 
     been looking at bash over the past 25 years, these bugs 
     would've been found a long time ago,'' Graham wrote on his 
     blog last week.
       Linus Torvalds--the guy that Linus's Law is named after and 
     the guy who created the Linux operating system--says that the 
     idea still stands. But the fallacy is the idea that all open-
     source projects have many eyes. ``[There's a lot of code that 
     doesn't actually get very many eyes at all,'' he says. ``And 
     a lot of open-source projects don't actually have all that 
     many developers involved, even when they are fairly core.''

  Mr. Speaker, the purpose of the Cyber Chain Integrity Act of 2014 is 
to help defend the U.S. government cyber infrastructure, and for DHS to 
carry out its mandate. On a going-forward basis we need all contractors 
of software, firmware or products to the U.S. Government to:
  1) provide the procuring agency with a bill of materials of all third 
party and open source components used--along with their version 
numbers;
  2) demonstrate that those component versions have no known 
vulnerabilities (NIST CVEs) for which less vulnerable alternatives are 
available and where exceptions are required, a written justification 
must be provided and risk accepted by the agency granting the 
exception;
  3) provide secure update mechanisms affording a prompt and agile 
response when new vulnerabilities are discovered in those products; 
and,
  4) supply said fixes and remediation updates within a reasonable 
specified time frame.
  Put plainly: Tell us the ingredients, they can't be known to be bad, 
and they need to be updateable (as they may prove to be vulnerable in 
the future).
  Further, the bill calls for each U.S. government agency to create an 
internal process for reducing exposure in existing infrastructure and 
to support operational security in DHS, to:
  1) assess and inventory all third party and open source components 
(with version numbers) in any critical software, firmware or products 
now in use;
  2) develop a risk based plan to remediate known vulnerabilities in 
third party and open source components now in use;
  3) identify un-patchable products to provide compensating controls or 
migration to patchable replacements;
  4) maintain and report lists of components and versions in use for 
inclusion in a centralized DHS inventory for the purposes of 
operational risk assessment and incident response:
  a) Tactical Uses: Such a resource can more immediately answer ``Am I 
affected?'' and ``Where is remediation required?''
  b) Strategic Uses: A central inventory would also support actionable 
metrics about projects & suppliers with regards to project & supplier 
integrity, defect rates, Mean Time To Remediate (MTTR), etc. to support 
future acquisition and supply chain choices.
  Mr. Speaker, physical building codes require a certain quality of 
steel be used for support beams, and dictate other requirements to 
ensure substandard building materials are not used in new construction. 
Similarly, cars must be recalled if they have defective parts (e.g. 
airbags). Restaurants must pass health code standards, and have 
specific hygiene and produce requirements so they do not make their 
customers sick.
  This bill requires suppliers to provide a confidential bill of 
materials (to the procuring agency) of open source components used in 
their products--just like an ingredients list on the food we buy at the 
grocery store (not the secret recipes).
  This bill does not ask for the source code or how the open source 
components work together, merely that the bill of materials be supplied 
to the agency procuring the products, and just like we demand of our 
cars, that these open source components contain no known defects or 
vulnerabilities to hackers.
  The bill also takes into account future discoveries of open source 
components with vulnerabilities, like the infamous ``Heartbleed'' 
vulnerability, and mandates that software applications be patchable, 
that is, these vulnerable components can be replaced with non-
vulnerable components.
  Just like when you find out your car's brake lines need to be 
replaced, when an open source components are found to have a 
vulnerability or defect, it needs to be replaced. This bill will allow 
those patches to be applied. Unfortunately, the Heartbleed 
vulnerability revealed that many uses were not patchable in embedded 
devices (e.g.).
  Mr. Speaker, the scale of the number of open source components being 
downloaded and used in software applications has grown at an 
exponential rate. This year, it is expected that open source components 
will be downloaded more than 21 billion times, for use in software 
applications. Half a dozen years ago, roughly one billion were 
downloaded. The scope of the issue of open source component supply 
chain integrity is becoming more important as open source component use 
in software development explodes.
  Here is a quick summary of what the Cyber Supply Chain Management and 
Transparency Act of 2014 does:
  Ingredients: Anything sold to the federal government must provide a 
Bill of Materials of 3rd Party and Open Source Components (along with 
their versions) to the procuring agency.

[[Page E1745]]

  Hygiene & Avoidable Risk: Software cannot use vulnerable components 
for which a less vulnerable component is available (without a written 
and compelling justification accepted by procuring agency).
  Remediation: Software must be patchable/updateable--as new 
vulnerabilities will inevitably be revealed.
  Mr. Speaker, I look forward to working with my colleagues on the 
committees of jurisdiction and leadership to move forward on this 
proposal.

                          ____________________