New Regulations, New Opportunities for Developers

On May 12, 2021 the White House delivered its Executive Order on Improving the Nation’s Cybersecurity.

It specifies future guidelines for software providers who sell software products to the federal government. Briefly, the document details its plans to issue guidance on qualifying for government sales:

Our work is going to get a lot harder.

By the authority vested in me as President by the Constitution and the laws of the United States of America, it is hereby ordered as follows:

Executive Order on Improving the Nation’s Cybersecurity

Section 4b states:

…the Secretary of Commerce acting through the Director of NIST, in consultation with the heads of such agencies as the Director of NIST deems appropriate, shall issue guidance identifying practices that enhance the security of the software supply chain.  Such guidance may incorporate the guidelines published pursuant to subsections (c) and (i) of this section.  Such guidance shall include standards, procedures, or criteria regarding:

            (i)     secure software development environments, including such actions as:

            (A)  using administratively separate build environments;

            (B)  auditing trust relationships;

            (C)  establishing multi-factor, risk-based authentication and conditional access across the enterprise;

            (D)  documenting and minimizing dependencies on enterprise products that are part of the environments used to develop, build, and edit software;

            (E)  employing encryption for data; and

            (F)  monitoring operations and alerts and responding to attempted and actual cyber incidents;

            (ii)    generating and, when requested by a purchaser, providing artifacts that demonstrate conformance to the processes set forth in subsection (e)(i) of this section;

            (iii)   employing automated tools, or comparable processes, to maintain trusted source code supply chains, thereby ensuring the integrity of the code;

            (iv)    employing automated tools, or comparable processes, that check for known and potential vulnerabilities and remediate them, which shall operate regularly, or at a minimum prior to product, version, or update release;

            (v)     providing, when requested by a purchaser, artifacts of the execution of the tools and processes described in subsection (e)(iii) and (iv) of this section, and making publicly available summary information on completion of these actions, to include a summary description of the risks assessed and mitigated;

            (vi)    maintaining accurate and up-to-date data, provenance (i.e., origin) of software code or components, and controls on internal and third-party software components, tools, and services present in software development processes, and performing audits and enforcement of these controls on a recurring basis;

            (vii)   providing a purchaser a Software Bill of Materials (SBOM) for each product directly or by publishing it on a public website;

            (viii)  participating in a vulnerability disclosure program that includes a reporting and disclosure process;

At present, the software supply chain is highly interdependent. Specifically, there is a great dependency between the different elements of software. Understanding these interdependencies could go a long way in exposing any risk levels attached to the use of specific software. Moving forward, by listing out the different components of your software, it’s increasingly possible to maintain transparency as it pertains to licensing and procurement.

Notably, the federal government’s new cybersecurity executive order leaves a lot to unpack. Part of the executive order is a call for more transparency in government software. The rule has always been “secrecy,” not “transparency.” Its focus is, the ability of this software to resist attack and thus prevent tampering by cybercriminals – who will definitely try.

This executive order necessitates creating a rigorous and predictable mechanism that can be used to ensure that the software sold to the federal government by private parties runs not only as intended but also securely. The result was the requirement that companies selling their software or products to the federal government will need to provide a complete software bill of material (SBOM).

Software Bill of Materials (SBOM) Explained

An SBOM can be created for any type of software, which might include open source, proprietary, deeply embedded, or fully open software.

Generating your SBOM as you develop your project for most is a manual task, but having this information on hand can help with understanding any vulnerabilities, especially important as related to your cybersecurity.

Note that while understanding your software’s components is essential, going further to understand how these are built, configured, and interrelated could give you a much greater understanding of ways in which the software could be used to manipulate your IT infrastructure, even without you knowing.

By linking your SBOM to federal cybersecurity, with instructions from the government, and to other customers, we will all be improving our cybersecurity protections and delivering transparency critical to exposing known vulnerabilities, especially when the supplier might have used components that are either old, obsolete, or have shown previous vulnerabilities. Oops.

The SBOM should be reviewed by someone working within the program office of the software recipient. Better yet, tools have been developed that can quickly check through the SBOM file, which will also provide essential information before running the software within your IT system.

Notably, the Software Package Data Exchange (SPDX) is currently mandated with providing the National Telecommunications and Information Administration (NTIA) guidelines on what the minimum SBOM should consist of. Additionally, the SPDX outlines how each of the components and their relationships need to be described.

Expected Regulations as They Pertain to SBOMs

At present, the relationship between tool vendors and those acquiring software for their projects is largely collaborative, yet in some instances vendors do not have an SBOM. This means that the end-user must compile their own list of components and assumptions about how they are interdependent, which is risky, as a number of assumptions have to be made. This is even worse while there are no best practices that align the creation of SBOMs and their consequent communication.

While the executive order only called for companies contracting with the federal government to provide SBOMs, we expect that the wide breadth of the government’s purchasing power will affect virtually all major companies dealing in software. We also expect that other companies, including those within the banking and health sectors, will need to adopt similar regulations.

A helpful expectation for SBOM regulation would be to standardize SBOMs. This will require creating an independent third-party management unit that is tasked with checking if the SBOM is both correct and up-to-date. Additionally, we hope for regulations to create an automated exchangeable information platform that would encourage the transparency and value of SBOMs.

Requirements of the Executive Order

In less than 60 days following the publishing of the executive order, vendors have had to test out their software source codes. Additionally, as part of the contract with the federal government, an SBOM will be required for acquisition.

Your SBOM is also expected to meet the ISO standards articulated by the SPDX. Finally, we believe there should be commercial tools that could go through the SBOMs provided by the vendor to ensure that they are not only compliant with industry standards, but also that can check on possible security vulnerabilities that could arise due to interdependencies.

The executive order further requires that the vendors identify and recommend the types of manual or automated testing that will be carried out as part of code review and both static and dynamic penetration testing.

Don’t stop yet. Additionally, software vendors will be required to:

●      Work within a secure software development environment which is consistently audited for trust relationships

●      Establish multi-factor, risk-based authentication platforms

●      Fully separate the administrative and build environments

The good news is that you’ll be taking a bold role in ensuring cybersecurity for your customers. Through transparency.

How Companies Can Prepare for These New Requirements

Every company developing a product using open-source code must manage the open-source risk. Especially for the federal government, as some of the software they acquire is used for military-grade projects.

Part of being prepared as a company would be seeking out verification tools that can help check if the SBOM you have provided meets the requirements of the SPDX. This could present a unique challenge for companies with multiple toolchains. Specifically, these companies are likely to experience greater fragility when it comes to integrating the different tools they have into a single analysis of vulnerabilities.

To prepare, companies should limit the scope of toolchains and tools to allow for greater focus when generating or going through the SBOMs. This should create a balance that would come in handy during the creation process. Specifically, other than having a complete inventory of all software components, companies should create an impact analysis of each of the components. This should include a detailed outline of the development environment and pipeline components. As part of the latter, companies should be able to attest to the security of each of the components within the pipeline.

A concern has been that the publication of the SBOMs will create a situation whereby competitors know what is within the different products they offer the government. In retrospect, this provides an opportunity for the different developers and software companies to chart their competition. In actuality, SBOMs should create a healthy tension that will be seen in product development and consequent strategic marketing.

Additionally, companies should embark on competitive staffing – especially in product marketing. That staff will help focus and articulate the selling features and benefits of the product, probably based on, or justified by, the SBOM.

Impact of SBOMs on Developers and DevOps Practitioners

For developers and other DevOps practitioners that supply software to the federal government, you’ll eventually need to adopt these, and more requirements. It will be worth it.

Altogether, developers and DevOps practitioners have a mandate greater than coming up with the SBOMs. They will need to create a globally scalable model that can contribute to overall cybersecurity. At present, the identification of the different software components is a big blob in which it is impossible to make sense of the different levels of knowledge. This significantly impedes the ability to scale up some of the projects as the metrics are, quite frankly, difficult to interpret. Yet, developers and DevOps practitioners have to grapple with the responsibility of filling in these gaps and any that might arise during the creation of SBOMs of their software products. Not good.

Join Us to Standardize Cybersecurity Standards

As part of developers and DevOps practitioners’ contribution to the SBOM model, we fully encourage these stakeholders to join us to create and maintain a vendor registry. On it, the suppliers should not only be identified, but also there should be a breakdown on the autonomy in component identification. This will require that they identify the direct cost of operating the registry, support all the different types of vendors and individual developers that contribute to the project, and create a model that is both resilient and has longevity.

Concisely, SBOM is like an ingredient list entailing all the different components that make up a software product. To remain cybersecure, it is paramount that some investment is made in identifying the components of a software product, mapping their dependencies, and testing whether these can be tampered with or not. Overall, meeting the needs of the development, the client, operations, and security can be taxing for developers and DevOps practitioners.

But once again, it will be worth it.

And we are here to help all of you get there.

At Guide-Rails_®, we provide you a self-service platform that simplifies maintaining and building software. We specialize in helping you be policy compliant as we manage open-source, plus generate your SBOM automatically. Talk to us today and be on your way to a development environment that is both productive and secure.