On January 16, the White House released an Executive Order (EO) covering multiple cybersecurity domains, such as software security, Artificial Intelligence (AI), and post-quantum cryptography. This is a continuation built on the foundation of Executive Order 14028 of May 12, 2021 – Improving the Nation’s Cybersecurity.
The latest EO “is designed to strengthen America’s digital foundations and also put the new administration and the country on a path to continued success,” Anne Neuberger, Biden’s deputy national security adviser for cyber and emerging technology, told reporters earlier this week.
Some of the key enhancements from this new EO include:
- Expanded coverage into emerging threats such as AI, and quantum computing
- Insights into advancing software security standards and practices
- More specific guidance on actions and timelines, creating an immediate sense of urgency and accountability
- Promotion of of new AI-based tools for cyber defense and “post-quantum cryptographic” algorithms to resist attacks leveraging quantum computing capabilities
The EO states that, “Adversarial countries and criminals continue to conduct cyber campaigns targeting the United States and Americans, with the People’s Republic of China presenting the most active and persistent cyber threat to the United States Government, private sector, and critical infrastructure networks. These campaigns disrupt the delivery of critical services across the Nation, cost billions of dollars, and undermine Americans’ security and privacy. More must be done to improve the Nation’s cybersecurity against these threats.”
The White House’s message to both the public and private sector is clear: that the threats from foreign adversaries are more dire than ever.
Malicious criminals continue to target the United States Government, corporations, and individual Americans with cyberattacks. They disrupt critical services, businesses and individual lives, costing billions of dollars and harming national security. This capstone executive order is the result of a review of how these attacks occurred, and was released to help us understand how to better protect and secure these systems and stay ahead of threats. As a result, it will be riskier, costlier, and harder for bad actors to conduct future attacks.
The EO contains 9 sections requiring actions from 52 agencies over the next few years in the following areas:
- Policy
- Operationalizing Transparency and Security in Third-Party Software Supply Chains
- Improving the Cybersecurity of Federal systems
- Securing Federal Communications
- Solutions to Combat Cybercrime and Fraud
- Promoting Security with and in Artificial Intelligence
- Aligning Policy to Practice
- National Security Systems and Debilitating Impact Systems
- Additional Steps to Combat Significant Malicious Cyber-Enabled Activities
Two of the specific initiatives in the EO to highlight are software security and AI.
Initiative 1: Making Software More Secure – for Americans, Companies, and the Federal Government
Russia and China conduct cyber attacks by exploiting numerous vulnerabilities in the software Americans use every day. This EO will put $100 billion of annual government IT procurement to work and drive companies to build more secure software for all Americans. The following are stipulated:
- Software vendors to the U.S. Government must provide proof that they are using secure development practices to develop software
- These proofs will be validated and validation results will be published to allow private sector buyers of technology to also benefit from knowing which vendors use secure software development practices
- The National Institute for Standards and Technology (NIST) will develop guidance for how to securely and reliably deploy software updates to better prevent future cyber incidents
- The General Services Administration (GSA) will develop policy driving cloud companies to clearly spell out how customers can secure their use of cloud products, making it easier for agencies and companies to safely use the cloud
Two of my major takeaways from this EO on software security are:
- The special emphasis on software supply chain securityThis is likely due to some of the recent, infamous examples of attacks, including the SolarWinds attack in 2020, the MOVEit attack in June 2023, and most recently the Treasury Department breach in December 2024 involving BeyondTrust. This new EO mandates the Federal Acquisition Regulatory (FAR) Council update its contract language to require software providers to submit the following to CISA through their Repository for Software Attestation and Artifacts (RSAA):
-
- Machine-readable secure software development attestations
- High-level artifacts to validate those attestations
- A list of the providers’ Federal Civilian Executive Branch (FCEB) agency software customers
The Secretary of Homeland Security, acting through the Director of CISA, shall evaluate emerging methods of generating, receiving, and verifying machine-readable secure software development attestations and artifacts. They must also provide guidance for software providers on submitting them to CISA’s RSAA website, including a common data schema and format. Likewise, the Secretary of Homeland Security is also expected to develop a program to centrally verify the completeness of all attestation forms.
Another key new addition outlined in the EO is the non-compliant consequences. If CISA finds that attestations are incomplete or artifacts are insufficient for validating the attestations, the Director of CISA shall notify the software provider and the contracting agency. For attestations that undergo validation, the Director of CISA shall inform the National Cyber Director, who shall publicly post the results, identifying the software providers and software version. The National Cyber Director is also now encouraged to refer attestations that fail validation to the
Attorney General for action as appropriate.The EO also acknowledged that open-source software plays a critical role in Federal information systems and the need to better manage their use of open-source software. The order expects the Secretary of Homeland Security and a few other agencies to jointly issue recommendations in the next 120 days on the use of security assessments and patching of open-source software and best practices for contributing to open-source software projects.
-
- The expanded definition and coverage of secure software development
The EO now recognizes that secure software development practices are not sufficient to address the potential for cyber incidents from resourced and determined nation-state actors. To mitigate the risk of such incidents occurring, software providers must also address how software is delivered and the security of the software itself. This means that secure software development should now include the practice of securing software
development and securing the entire software delivery process and systems (aka software factory) and securing the software artifact itself.The Federal Government must identify a coordinated set of practical and effective security practices to require when it procures software.To operationalize this guidance, the major tangible action is making updates to NIST SP 800-218 (Secure Software Development Framework – SSDF) and NIST SP 800-53.
Initiative 2: Promoting Security with and in AI
The EO directed research in AI use cases for both cyber defense (AI for security) and protection against AI software and systems (security for AI).
AI for security
The EO launches innovative agency efforts to accelerate development and use of AI for cyber defense through the following actions:
- A public/private partnership to use AI for cyber defense of critical infrastructure in the energy sector, one of the sectors where cyber attacks could affect Americans’ day-to-day lives
- The research and development of AI-based cybersecurity tools and techniques, including in vulnerability discovery, threat detection, patch management, and incident and vulnerability reporting
The EO mandates, within 150 days, agencies must prioritize their AI research in the following topics:
- Human-AI interaction methods to assist defensive cyber analysis
- Security of AI coding assistance, including security of AI-generated code
- Methods for designing secure AI systems
- Methods for prevention, response, remediation, and recovery of cyber incidents involving AI systems
Security for AI
The EO requires, within 150 days, “the Secretary of Defense, the Secretary of Homeland Security, and the Director of National Intelligence, in coordination with the Director of OMB, to incorporate management of AI software vulnerabilities and compromises into their respective agencies’ existing processes and interagency coordination mechanisms for vulnerability management, including through incident tracking, response, and reporting, and by sharing indicators of compromise for AI systems.”
My key takeaways for the AI portion of the EO are:
- While AI research and innovation will continue to accelerate, we are still in very early stages of harnessing AI the right way with enough maturity. Partnership is the key. Public & private sectors as well as vendors and customers (early adopters).
- When evaluating cybersecurity solutions that leverage AI, set proper expectations on the maturity of their AI features. They will likely need real data to train on. It is more important to partner with vendors who are transparent about their current AI capabilities and gaps, and their vision and product roadmap (realistic based on their current product DNA). There is a fine line between true commitment to innovate to solve industry challenges and rushing to “me too”.
What Will Be the Implications of this EO on Software Security?
While EO 14028 created the foundation and awareness for software security, it was more focused on providing guidance and direction. Some of the checklist items in the EO became part of NIST SP 800-218 (SSDF). The new EO offers additional guidance with specific details on actions to take for verification such as the attestation process, and consequences of non-compliance. Given recent and current events, the government is now more serious about taking specific actions in software security and holding software suppliers accountable for adherence to software security practices through attestations.
Some of my optimistic predictions:
- NIST will make considerable enhancements to NIST 800-218: the current version is fairly high level with some ambiguity and duplicated controls leaving the readers wonder “how would I start, and how do I measure progress
- NIST 800-218 adoption will grow rapidly and it will be a requirement for software security vendors to support the review and attestation of NIST 800-218: this provides opportunity for the industry to contribute to refining the SSDF and how to operationalize it)
- A growth of policy-as-code and compliance-as-code adoption among organizations to modernize their existing security compliance and assurance processes and to keep up with rapid pace of software delivery with the ability to demonstrate continuous compliance with verifiable machine-readable secure software development attestation artifacts
- Accelerated platformization of Software Security vendors with AI built into their platform: we have already seen a rapid acquisition of Application Security Posture Management (ASPM) from application security and infrastructure security vendor, growing emergence in next generation Software Composition Analysis with new SBOM features and Software Supply Chain Security vendors (usually part of an ASPM platform), and the explosion of AI features from all these vendors. As the EO has pointed out, the new definition of secure software development should include both securing the code artifact as well as the entire software factory (the software delivery tools and processes). The future of software security platforms should include Application Security Testing (AST), Software Supply Chain Security (SSCS), and ASPM with built-in AI and governance layer that allows the orchestration of centralized policy-as-code and self-attestation via compliance-as-code.
How Cycode’s Capabilities Map to the EO
Cycode is well positioned to meet and exceed the expanded requirements of software security outlined by this EO. Cycode’s complete ASPM platform with AI built-in provides end-to-end software security visibility across the entire SDLC processes, including tool chain and ownership layers. This includes securing application and infrastructure artifacts, identifying active Non-Human-Identities (NHIs) such as secrets embedded across source code and collaboration platforms, fine-grained access tokens, and assessing the security posture of software delivery pipelines within the broader software factory. Cycode also offers aggregated risk context across all these layers with the ability to generate machine-readable artifacts, self-attest compliance against NIST 800-218, and automate remediation.
EO’s Mandate on Software Supply Chain Security
How Cycode can help:
- Complete inventory and visibility of tools, technology, software assets, configurations, and their ownership across all stages of SDLC:Cycode’s Technology Inventory identifies and monitors SDLC technologies across development and deployment stages using AI and hundreds of unique rules, and then maps those technologies to specific development stages and owners. It answers critical questions such as what tools are in use and who uses the tools and when. This capability reduces the risk of both shadow IT and identify the presence of rogue and malicious actors and assets.
- Assess and attest software supply chain security of the software delivery pipeline:Cycode checks your software artifact repositories and CI/CD pipelines against CIS software supply chain compliance benchmarks and has the ability to build custom policies, provide in-platform attestation and evidence collection, and the ability to export via machine-readable format.
- Open-source software risk management:Cycode provides a native and modern Software Composition Analysis (SCA) capability to assess, prioritize, and remediate in-use open-source software libraries across both direct and transitive dependencies. This includes built-in business impact and exploitability analysis through Exploity maturity, EPSS, CISA-KEV, and code reachability analysis. Cycode SCA also has built-in SBOM generation and compliance verification capabilities compatible with popular formats such as SPDX and Cyclone DX. Finally, Cycode’s AI-assisted remediation feature helps suggest the most appropriate library upgrades to developers via their favorite IDEs during pull request or via a custom remediation workflow.
- Real-time CI/CD Pipeline monitoring and Threat Mitigation:Cycode’s Cimon leverages eBPF to monitor and protect your CI/CD pipelines against sophisticated cyber attacks. Cimon takes a proactive approach to pipeline security by focusing on preventing attackers from performing malicious actions rather than solely trying to prevent their entry into the build environment. By monitoring and mitigating attacks at the kernel level, Cimon ensures that even if your build environment is compromised, attackers cannot exfiltrate or tamper with your sensitive data.
- Automate software artifact integrity compliance:Cycode’s Cimon also provides an end-to-end solution that enhances software artifact integrity by enabling keyless artifact signing via Sigstore and automating Supply Chain Levels for Software Artifacts (SLSA) attestation.
EO’s expanded Definition of Secure Software Development Practices
How Cycode can help:
- Automated compliance against NIST 800-218 SSDF:Cycode offers built-in compliance assessment, audit-ready evidence collection, and self-attestation against NIST SSDF.
- Instant-on and developer-focused software security risk detection:Cycode’s quality proprietary application security testing capabilities assess full stack software risks across NHIs, pipeline configurations, custom code, open-source libraries, container images, and cloud Infrastructure-as-Code (IaC) aligned with developer workflows across IDE, source-code management, pull request, and in-platform navigations by development projects or business units.
- Unified software security vulnerability management:Cycode’s open platform also provides the ability to ingest, aggregate, deduplicate, and prioritize issues from third- party application security platforms, API security platforms, and cloud security platforms. This unifies, contextualizes, and remediates software risks, from source code to running application workloads.
- Contextual, just-in-time, and hands-on secure development training:Cycode’s partnership with Secure Code Warrior (SCW) combines powerful vulnerability detection with contextual, just-in-time developer risk management. As Cycode’s native scanning tools identify vulnerabilities across codebases, SCW delivers agile learning materials tailored to the specific issues flagged. For example, if a developer encounters a cross-site scripting vulnerability, SCW provides immediate guidance, such as an interactive tutorial, explaining the issue, its risks, and how to fix it. By aligning developer risk management with real-world scenarios, the integration not only accelerates remediation, but also builds developers’ secure coding skills over time.
EO’s Focus on AI Security
How Cycode can help:
- Inventory and risk assessments of AI in use across the SDLC:Cycode provides full visibility of AI in use across the SDLC and related risks utilizing Cycode’s Risk Intelligence Graph (RIG).
- AI-assisted remediation of software code artifacts:Cycode provides AI-assisted remediation guidance and automates the generation of code fixes directly inside of developer’s IDE, during pull request, or on-demand in the Cycode platform.
- Natural language query of complex risk and vulnerability intelligence:Cycode’s RIG has always been a powerful tool that connects and correlates alerts across your entire SDLC. It allows you to filter the noise so that you can focus on the vulnerabilities that matter the most. That is, the vulnerabilities that represent true risk to your organization. Now the RIG is enhanced via LLM. Cycode RIG with AI inside is the world’s first neural network purpose-built for complete ASPM, seamlessly integrating your code, builds, vulnerabilities, teams, organizations, artifacts, developers, and your company’s extensive security knowledge through the ease of everyday natural language. It functions like a human brain, using deep context and security insights to transform the way security teams manage application security and collaborate with developers.
Where do I start?
NIST and CISA publications are generally high level without specific guidance on the “how”. While SSDF will undergo another revision per this EO, there are things that could be done now. If you are already aligned with other software security frameworks such as OWASP SAMM or BSIMM, it is easy to start cross reference the controls. There are already public resources that contain cross mapping of controls.
I have included a few things you could do that align with some of the foundational SSDF controls and practices from my years of experience implementing application security programs and leading DevSecOps transformations. Whether you are just formalizing your software security program or looking to assess mature current program and ensure you are ready to be in compliance with this EO, below are a few foundational things you should do or update:
Define and adopt Culture Values
Culture values are essential in building a functional Operating Model (below). Measuring and changing culture is hard. Siloed operations and lack of trust are the two most common challenges stalling organization’s transformation efforts. Good culture creates a shared understanding of what is important to the organization and how people should behave. This can lead to improved communication, collaboration, and decision-making. Additionally, cultural values help to enhance developers’ trust of security, which is essential for integrating security into the product development lifecycle. At a minimum, consider define and adopt the following culture values in your software security & DevSecOps journey:
- Accountability: Everyone takes ownership of their security responsibilities.
- Agility & Automation: Able to quickly adapt to new threats and vulnerabilities and automate security tasks to improve efficiency and consistency.
- Collaboration & Inclusivity: Work together to identify, resolve, and prevent security risks; thinking beyond oneself as an individual contributor and beyond one’s immediate team.
- Continuous Learning: Constantly learning about new security threats / vulnerabilities, how to mitigate them, and sharing knowledge with others.
People
Create a cross-functional operating model that clearly defines the roles and responsibilities of key stakeholders inside and outside of the organization involved in any parts of SDLC span across Development, IT Operations, and Security. (NIST SSDF PO 2.1)
At a minimum, the roles should include:
- Defining security requirements and governance
- Perform threat modeling and risk assessments
- Implement and maintain security tooling capabilities
- Define and enforce software security standards
- Perform software defect (include security defects) triage and remediation
The typical stakeholders involved in the operating model should include: Developers, Product Owners, DevOps/Platform Engineering/SRE, Security Architecture, Security Engineering, Application Security/Product Security, Vulnerability Management, and GRC.
Process
Identify and document all security requirements for organization-developed software and organization’s software development infrastructures and processes, and maintain the requirements over time. This includes defining policies for securing software development processes throughout the SDLC and maintaining that security, including for open-source and other third-party software components utilized by software being developed. Communicate requirements to all third parties who will provide commercial software components to the organization for reuse by the organization’s own software. (NIST SSDF PO 1.1, 1.2, and 1.3).
At a minimum:
- Define and document policies to conduct risk assessments and secure applications based on applicable technology stacks composed of languages/frameworks, environments, and deployment models.
- Define policies for securing software development processes throughout the SDLC and maintaining that security, including for open-source and other third-party software components utilized by software being developed.
- Require third parties to attest that their software complies with the organization’s security requirements.
- Require third parties to provide provenance data and integrity verification mechanisms for all components of their software.
Technology
Conduct an inventory and rationalization of existing SDLC technology stack and software security tools to identify areas of overlap and points of gap. (NIST SSDF PO 3.1) Determine:
- what capabilities could be consolidated
- what capabilities is needed to cover critical blind spots
- how should the capabilities integrate into both developer and security team’s workflows
- what information is to be passed between tools and what data formats are to be used
At a minimum, core SDLC security capabilities should cover:
- source code
- third-party libraries / registries
- secrets and NHIs
- build & deployment processes (CI/CD pipelines)
- production environment
Selecting the right combination of software security vendors is challenging in today’s market. DevOps Platforms, Cloud Providers, Application Security Platforms, Cloud Security Platforms, and other security platforms all have overlapping features. Additionally, organizations must determine the platform vs best of breed vs home grown tradeoffs and make the right decisions. At a minimum, the following factors should be considered before making a decision:
- tools efficacy
- vendor and/or cloud provider lock-in
- cost
- organizational politics
- Vendor customer support
While there is no single tool that is best at all the required capabilities in software security, some sectors of the market are converging. Application Security Testing, Software Supply Chain Security, and Application Security Orchestration and Correlation are converging into Application Security Posture Management. ASPMs have a set of native capabilities you could consolidate into, while having the ability to ingest, correlate, and enrich other tools you may decide to keep. It is an excellent choice for consolidation and cost saving.
