What happened
On June 6, President Trump signed an Executive Order (EO) “Sustaining Select Efforts to Strengthen the Nation’s Cybersecurity.” The EO sustains efforts to strengthen the Cybersecurity and Infrastructure Security Agency’s (CISA) role in defending civilian Federal networks, bolsters protections against foreign cyber threats and advances secure technology practices in critical sectors. The EO also amends two prior Executive Orders, EO 13694 (Blocking the Property of Certain Persons Engaging in Significant Malicious Cyber-Enabled Activities), and EO 14144 (Strengthening and Promoting Innovation in the Nation’s Cybersecurity).
The EO updates requirements for Federal contractors to attest to the security of their software through the Secure Software Development Attestation Common Form. While the original EO 14028 attestation provision remains in place, submission expectations and protocols are evolving. In addition, the EO removes the directive to update the Federal Acquisition Regulation (“FAR”) to require secure software attestations. The order directs the Secretary of Commerce to establish a consortium with industry to develop guidance for demonstrating alignment to NIST Special Publication 800–218 (Secure Software Development Framework (SSDF)) by August 1, 2025.
The EO highlights the cyber risk posed by foreign nations and criminals targeting the U.S., prioritizing China as the most active and persistent cyber threat. The EO also explicitly names Russia, Iran and North Korea as significant threats.
The Order rescinds provisions on U.S. government support for digital IDs that it contends could facilitate entitlement fraud and other abuse. It promotes the use of Artificial intelligence (AI) to transform cyber defense by rapidly identifying vulnerabilities, increasing the scale of threat detection techniques and automating cyber defense. Finally, the EO calls for a “rules-as-code” pilot program to enable machine-readable versions of cybersecurity policy and guidance.
Why it matters
Reducing regulatory burden.
Consistent with the Administration’s effort to reduce compliance and regulatory requirements, the EO targets previous mandates which it states were “unproven and burdensome software accounting processes” and seeks to empower departments and agencies with technical cybersecurity decision-making.
Emphasis on countries of concern.
Despite significant changes, the EO explicitly references priority countries of concern for cyber threats (China, Russia, Iran, North Korea). It limits the application of cyber sanctions only to foreign malicious actors, preventing what it references as “misuse against domestic political opponents.”
Evolving software security reporting protocols.
The EO leaves a significant reporting requirement for software producers selling to the Federal government in limbo. The existing Common Form provisions had already been softened from the original 2024 version with the withdrawl of the mandate to submit Software Bill of Materials artifacts, among other things. The new EO’s removal of artifact and validation requirements for Federal software providers, as well as elimination of future FAR requirements, leaves key aspects of self-attestation compliance uncertain.
The updates would ideally address anticipated, challenges with storing, processing and actioning industry-submitted data to CISA’s Repository for Software Attestation and Artifacts (RSAA). As stated above, the Administration has called for a public-private consortium to resolve these issues, and is evaluating other mechanisms for USG procurement of secure software including DOD’s Software Fast Track Initiative (SWFT).
Software supply chain security remains a priority.
The SSDF will continue to be the government’s authoritative source for secure software best practices. The Order directs the Federal government to advance secure software development through continued use of the SSDF, despite moving away from SSDF-derived self- attestation. The private sector, especially within critical infrastructure, will continue to focus on software supply chain risk management and incorporate risk-reducing requirements into third party requirements. This Open Letter to Third-Party Suppliers, authored by JP Morgan’s CISO, demonstrates critical infrastructure’s focus on software security.
Automated controls assessment.
The “rules as code” pilot recognizes that an opportunity exists to modernize both security and compliance through open, machine-readable formats that streamline control-based risk assessments, such as NIST’s Open Source Controls Assessment Language (OSCAL). Benefits include establishing machine-readable control baselines, using those to maintain and share up-to-date implementation information, and automate the monitoring and assessment of control effectiveness. Indeed, as organizations migrate workloads to hyperscale and other cloud environments, aspects of this functionality already exist.
The Path Forward
To help your organization adapt to these changes and strengthen your cybersecurity posture, we recommend the following actionable steps:
Align your Software Development Lifecycle (SDL) to best practice.
Software producers should apply security assurance across the software development lifecycle (SDL) from initial design to distribution. Producers should align their SDL to the NIST SSDF and conduct routine internal and independent SSDF assessments and testing. Producers should also confirm that external validators are not associated with designated countries of concern.
The Chertoff Group’s Product Assurance Playbook offers additional guidance on embedding security into the software development lifecycle, complementing standards like NIST’s SSDF.
Automate and document where possible.
Future software security reporting mandates are unclear but emerging initiatives like SWFT will likely seek to leverage machine-speed submission/attestation. Where possible, software producers should apply software testing, validation and chain of custody controls that are highly integrated into the SDL. Tools should generate immutable artifacts that can be shared securely with business partners and the government, for example via the Supply Chain Levels for Software Artifacts (SLSA) Version 1.0 framework. Suppliers may also consider approaches that inspect the final software package for risk such as software vulnerabilities, malware, tampering and hard-coded secrets.
Generate (or demand!) the ingredients.
Although the EO does not reference Software Bill of Materials (SBOM), it remains an essential inventory of software components and dependencies. Producers should implement tools and processes that generate a high-confidence SBOM to establish software supply chain visibility. Consumers should require SBOMs, especially for critical software, to validate the security and hygiene of installed applications. Emerging technology platforms can assist in automated SBOM generation, enrichment and sharing.
Stay Informed on Policy Changes.
The government’s expectations on cybersecurity are evolving and both producers and consumers need to monitor policy directives on key issues contemplated in the EO (i.e., software security reporting, post-quantum cryptography, use of AI, etc.)
David London is a cybersecurity expert and a managing director at The Chertoff Group
This blog was mentioned in a story on the Federal News Network.
