informa
/
Vulnerabilities/Threats
Commentary

Cybersecurity Executive Order: Securing the Software Supply Chain

The new executive order will help foster a more collaborative and unified approach to cybersecurity, an approach that highlights the importance of securing software by design.

As details of the new executive order on cybersecurity became known, the software industry suddenly found itself on notice. While the order deals specifically with software sold to government agencies, it's just a matter of time before commercial organizations follow the government's example. Software companies — whether they currently sell to the government or not — need to understand what the order means for them, and how they can apply, and ultimately comply with, its requirements.

Securing the Software Supply Chain
Section four of the executive order is significant, both in its ambition and its predominance, comprising 25% of the overall order. While the final details will take months to define, the National Institute of Standards and Technology (NIST) has already begun the process to develop initial guidelines, beginning with its definition of critical software and list of critical software categories. Most recently, NIST outlined security measures for critical software, including minimal standards for automated testing of software code.

As NIST continues to develop guidance on best practices for securing the software supply chain, software vendors should consider how the following requirements impact their business, and what changes they may need to implement in the months to come.

  • Development environment security: This guidance underscores the realization that the environment in which software is developed must have equal or greater security controls than the environment in which the software operates. This will require significant and ongoing security processes, from establishing degrees of authentication and access to employing data encryption and auditing trust relationships.
  • Conformity and disclosure: A key element of this section is the call for vendors to demonstrate conformance to the secure coding guidelines outlined in the order. This means development environments must be auditable by the government or other customers. This will likely usher in the development of standardized third-party audits like SOC 2, which will enable vendors to save time during the sales process.

    The order also requires that software makers participate in a vulnerability disclosure program that includes a reporting and disclosure process. This will create a big push for coordinated vulnerability disclosure and will likely become standard for all software vendors.
  • Software bill of materials: Among the most discussed requirements is the software bill of materials, or SBOM. The government is now mandating transparency about what is included in software as awareness of the security risks has increased. Consider that modern software is primarily made up of existing code, much of it from open source libraries. Since most open source code contains vulnerabilities (our research found 70% of applications contain a vulnerability in an open source library), it's impossible for an organization to claim its software is secure without assessing the security of the open source components of its applications. The SBOM forces organizations to analyze the source code they use and take responsibility for the security of their software, including any open source components.

    That said, a single vulnerability in a component used by a product does not necessarily make that product vulnerable. It is likely vendors will prefer an online, continuously updated SBOM that can inform customers whether or not a public vulnerability in a component affects the security of that product.
  • Automated application testing: The order specifically requires that automated tools (or comparable processes) be used to check for both known and potential vulnerabilities and remediate them. It also notes that the tools should operate regularly, or at least before product, version, or update releases. For those in the as-a-service business, these tools will need to be integrated into the development process.

    Of note, NIST's recent guidance on critical software security recommends threat modeling using automated testing, both static and dynamic analysis, and the use of secure coding techniques. The guidance also enforces remediation of "must fix" bugs — noteworthy, as too many companies stop just short of that critical next step.
  • Compliance and remediation: Section 4 requires agencies that procured software prior to the order to comply with the regulations set forth through remediation, if necessary. This is actually one of the biggest hurdles for software providers since it is difficult and time consuming to remediate old software that includes "security debt" — untested code or unaddressed flaws. Vendors will often rewrite software from scratch rather than mitigate issues. I expect this one will require many waivers.

Security by Design
Software is the heart and engine of the modern world. Everything is code, which means everything is at risk. Recent cyberattacks on the Colonial Pipeline and SolarWinds demonstrate not only the weakness of the software supply chain, but also how far and wide a single breach can reach. Many of the requirements included in the executive order are aimed at hardening the supply chain by securing software during the development process. The new executive order will help to usher in a more collaborative and unified approach to cybersecurity, an approach that highlights the critical importance of securing software by design.

Recommended Reading:
Editors' Choice
Kirsten Powell, Senior Manager for Security & Risk Management at Adobe
Joshua Goldfarb, Director of Product Management at F5