Third-Party Risk Management in the Executive Order on Improving the Nation’s Cybersecurity

4 (e) (i) (A)-(F)

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;

When assessing third party software security practices, take advantage of existing industry-accepted standardized risk assessment questionnaire templates including the Standard Information Gathering (SIG), NIST, CMMC, and related assessments. Utilizing a single standardized assessment across your supplier base ensures that agencies can more efficiently compare the software security practices of their suppliers.

Note: Agencies can also take advantage of exchange networks, which contain already completed security risk assessments to accelerate the risk identification process.

4 (e) (ii)

(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;

When assessing a third party’s secure software development practices, ensure that you have the capability to centralize supporting evidence with built-in task and acceptance management, plus mandatory upload features. A secure document repository ensures that relevant parties can review documentation and artifacts accordingly.

4 (e) (iii)

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

See 4 (e) (i) (A)-(F) above.

4 (e) (iv)

(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;

Third parties must scan, triage and remediate vulnerabilities in their software and code, and attest to it. But threats don’t end there. Security teams should also monitor the Internet and dark web for cyber threats, leaked credentials or other indicators of compromise that can open pathways into Federal systems if left undetected.

4 (e) (v)

(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;

Reporting is key here. Federal IT security teams should be able to reveal risk trends, status, remediations and exceptions to common behavior for individual suppliers or groups with embedded machine learning insights. This would enable teams to quickly identify outliers across assessments, tasks, risks, etc. that could warrant further investigation.

4 (e) (vi)

(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;

Federal IT teams should be able to automatically map information gathered from internal audits to standards or regulatory frameworks applicable in this EO – including NIST, CMMC and others – to quickly visualize and address important control deficiencies, and attest to practices.

4 (e) (vii)

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

See 4 (e) (i) (A)-(F) above.

4 (e) (viii)

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

See 4 (e) (i) (A)-(F) above.

4 (e) (ix)

(ix) attesting to conformity with secure software development practices; and

See 4 (e) (ii) above.

4 (e) (x)

(x) ensuring and attesting, to the extent practicable, to the integrity and provenance of open source software used within any portion of a product.

See 4 (e) (vi) above.