Conformity. Attestation. Artifacts.\n\nIf you want to sell products powered by software to the federal government, you need to get familiar with those terms. You\u2019d also better be prepared to comply with what they require.\n\nBecause if you don\u2019t, federal agencies will eventually be banned from buying from you, by executive order (EO) of President Biden.\n\nDon\u2019t panic. You will have some time \u2014 likely years \u2014 to get ready. More on that later.\n\nBut don\u2019t delay either. Those three words are at the core of the section of Biden\u2019s May 2021 EO on improving cybersecurity that is devoted to the software supply chain.\n\nIn brief, its goal is to ban U.S. government agencies from buying any software product that doesn\u2019t include detailed, credible information on who made the components, where they came from, whether they were built and tested in conformance with specified quality and security standards, and how updates and patches for any exploitable defects will be provided and for how long.\n\nYes, that\u2019s in brief. The National Institute of Standards and Technology (NIST) goes into much more detail in response to Biden\u2019s EO with Software Supply Chain Security Guidance, issued Feb. 4, 2022.\n\nAnd for anyone who cares about the risks to government, business, and individuals from software that is not secure \u2014 which should be everybody \u2014 the directives should be welcome.\n\nIndeed, virtually every private and public sector organization depends on software. A lot of software. And if it\u2019s not secure, your organization is at risk. Unpatched vulnerabilities can lead to trouble ranging from annoyance to disaster \u2014 hijacking of systems, data leaks (and therefore theft of sensitive data), denial-of-service attacks, system crashes, theft of everything from identity to financial data and intellectual property, millions in ransomware payments, critical infrastructure damaged or shut down, and more.\n\nAnd the threat of such disasters is increasing. The research firm Gartner, in a report titled \u201cTop Trends in Cybersecurity 2022,\u201d called the digital supply chain one of the top two current attack vectors. \u201cVulnerabilities that are deeply embedded in the digital supply chain are often extremely difficult to detect, and thousands of applications or devices may be simultaneously impacted,\u201d the report said.\n\nTo minimize the risk of those disasters, which is the intent of the Biden EO, organizations need to use software components that meet rigorous security standards, keep track of them, and keep them up to date.\n\nThe ways to do this are no great mystery \u2014 they\u2019re well established. To keep track of it requires a software Bill of Materials (SBOM). As has been said thousands of times at security conferences, you can\u2019t protect something you don\u2019t know you have. And if you don\u2019t protect it, you can\u2019t trust it to protect you.\n\nSupply chain tracking is not a revolutionary concept either. For generations we have taken for granted that supply chain information for just about every product in the physical world is accessible when necessary.\n\nIf contaminated lettuce shows up in grocery stores, we soon hear on the news which farms it came from and to throw it out if you bought lettuce between certain dates from certain stores.\n\nSame for malfunctioning airbags, brakes, seatbelts, or any other component in cars. If there\u2019s a problem, the auto manufacturer knows which vehicles to recall, and which vendor made the flawed product.\n\nThe same ought to be true of software products. In a connected world, software is behind just about everything, from factory operations to bookkeeping, human resources, communication, finance, critical infrastructure, home security, appliances, and yes, government. The list could go on and on.\n\nWhy isn\u2019t it already mainstream?\n\nBecause it\u2019s complicated. Very complicated. Creating and maintaining an SBOM for an organization of any size can be a massive undertaking, since the software components used to build applications, customer interfaces, networks, and other digital infrastructure in most cases rely on other components, called dependencies.\n\nThat means the stuff you know you\u2019re using is relying on other stuff you may not know you\u2019re using. Those dependencies can go multiple levels deep and exponentially increase the number of components that need to be tracked so they can be updated when necessary.\n\nTim Mackey, principal security strategist within the Synopsys Cybersecurity Research Center, has used a simple Slack application with an Instagram interface as an example.\n\nIn a recent webinar, he noted that the app included eight declared dependencies, one of which originated from Slack itself, called Bolt.\n\nBut Bolt has 15 dependencies of its own. And one of those, called Express, has another 30. \u201cWhen you peel back the onion on this, Slack\/Bolt actually has 133 separate components in it,\u201d Mackey said.\n\nThat\u2019s 16 times the eight declared or \u201cvisible\u201d dependencies of just one component of one app. And given that most organizations have hundreds to thousands of apps, it\u2019s clear how complex and unwieldy tracking a software supply chain can be.\n\nFortunately, there are numerous resources available to help create and maintain what would be an impossible manual task. They include automated tools and detailed advice from government and private sector associations.\n\nAmong them, the National Telecommunications and Information Administration within the Department of Commerce has a section of its website devoted to everything an organization needs to understand an SBOM, including an extensive Q&A.\n\nAnd the federal Cyber Information Security Agency hosted a virtual conference titled SBOM-a-Rama on Dec. 15 and 16, 2021, in which SBOMs were described as \u201ca key building block in software security and software supply chain risk management.\u201d\n\nBut besides keeping track of software, the EO calls for federal agencies to buy only quality software products, or in other words, products that comply with those three key words mentioned earlier \u2013 conformity, attestation, and artifact.\n\nAccording to the NIST definitions:\n\nConformity is a \u201cdemonstration that specified requirements are fulfilled,\u201d including \u201ca demonstration that the software producer has followed secure software development practices.\u201d\n\nAttestation is the \u201cissue of a statement, based on a decision, that fulfillment of specified requirements has been demonstrated.\u201d\n\nArtifact is \u201ca piece of evidence (that provides) grounds for belief or disbelief; data on which to base proof or to establish truth or falsehood. Artifacts provide records of secure software development practices.\u201d\n\nThose requirements amount to a very tall order for any organization that isn\u2019t already building security into its software with secure software development practices and maintaining an SBOM.\n\nSo how much time, realistically, will both federal agencies and vendors have to get ready?\n\nDon\u2019t hold your breath, even though EO deadlines are looming. The federal Office of Management and Budget (OMB), if it meets its deadline, will be issuing guidance within a week or two on requirements for federal agencies to comply with the EO\u2019s software procurement requirements.\n\nBut Emile Monette, director of government contracts and value chain security at Synopsys, said that guidance, even if it\u2019s issued on time, won\u2019t result in anything enforceable until a Federal Acquisition Regulation (FAR) rule is issued.\n\nIndeed, the EO itself says the deadline for OMB to make recommendations to the FAR Council (which will issue the rule) on \u201ccontract language\u201d for government procurement of software products isn\u2019t until a year after the EO \u2014 May 12, 2022.\n\nAnd after that, there is no deadline for the FAR Council to act. The EO simply says that the council \u201cshall review the recommendations and, as appropriate and consistent with applicable law, amend the FAR\u201d to create a \u201cfinal rule.\u201d\n\nThat, Monette said, can take years. Besides the fact that every proposed \u201cfinal rule\u201d requires a comment period of at least 60 days, \u201clots of other variables can also affect the process \u2014 political pressure from either end of Pennsylvania Avenue, new statutes, new EOs, small-p political pressure from OMB or the other agencies, the volume and content of public comments received, a \u2018reopening\u2019 of the comment period, and just the passage of time between original publication date and the occurrence of some superseding event in the world,\u201d he said.\n\n\u201cIn general, the FAR rulemaking process is assumed to be 24 months if there are no hiccups. But realistically, it\u2019s rare that a substantive rule gets through that quickly and unscathed.\u201d\n\n\u201cOMB has not communicated anything publicly on the topic,\u201d he added. \u201cAnd the OMB guidance will most likely only be directives to the agencies as to how they implement the NIST requirements \u2014 which contracts, waiver process, timelines, etc. Without a FAR rule in place, the government has no way to require contractors to meet the conformance and attestation requirements, or any others.\u201d\n\nBeyond all that, the law of unintended consequences could come into play. What if, after the rule is established, a government agency can\u2019t get software products it needs because there aren\u2019t qualified vendors available?\n\nMonette said that possibility will likely be addressed in OMB recommendations, which would allow waivers or a Plan of Actions and Milestones process.\n\nIt could still create a problem, though, \u201cbecause it might cause certain software developers to exit the federal market if the cost to make their products compliant is too high,\u201d he said.\n\nFinally, there is no way to conduct an overhaul of this magnitude to the biggest and most complicated organization in the country quickly.\n\n\u201cJust think about the software used by the VA [Veterans Administration],\u201d Mackey said. \u201cYou\u2019ve got everything from medical devices, implantable devices, and EMR [electronic medical records] software to fleet management software for transport vans and the software in the vans themselves. All of those are under some form of government contract, so just imagine trying to apply this to the VA and then the rest of our government infrastructure.\u201d\n\nStill, while it may be a slow train, it\u2019s moving. Any company that wants to sell to the feds needs to prepare for its arrival. Now would be a good time to start.\n\n Click\u00a0here\u00a0to find more Synopsys content about securing your software supply chain.