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.