The cybersecurity landscape for federal agencies is in a perpetual state of evolution, driven by both escalating threats and shifting policy directives. The recent Executive Order from the Trump administration, while modifying some prior requirements, underscores a crucial truth: agencies still bear the unchanged responsibility of safeguarding mission and data.
With over 25 years in the world of open source and software in the federal space, I’ve witnessed firsthand the constant push and pull between compliance and practical security. This new EO, which notably backs off some of the more stringent attestation and artifact requirements from previous administrations, appears to signal a shift. It’s less about a compliance-first mindset and more about a practice-first approach — one that emphasizes mastering the fundamentals of secure software development, a core principle of the NIST Secure Software Development Framework (SSDF).
The Unchanging Core: Quality and Transparency
Even with these changes, the core principles of robust cybersecurity are unwavering. The smartest federal leaders will continue to demand a high standard of quality from their software partners, prioritizing transparency. This means continuing to ask for Software Bills of Materials (SBOMs) and requiring vendors to attest to their secure development practices. Responsible vendors will readily provide this information.
SBOMs and SSDF processes remain vital tools for agencies to achieve Authorizations to Operate (ATOs) for everything from Commercial Off-The-Shelf (COTS) proprietary software to third-party open source components and internally developed application code. They are foundational to a robust secure software development lifecycle, helping to identify and mitigate vulnerabilities continuously.
From “Shift Left” to “Start Left”: Embedding Security in Development
A key tenet I advocate for is moving beyond “shift left” to “start left” — integrating code quality and security directly into the hands of developers from the very beginning. True security of software is not a one-time audit or an afterthought; it’s a continuous practice. While artifacts and compliance requirements may change, the main goal should be to embed security as a normal part of the development process. This aligns with the SSDF’s emphasis on “security by design” and “continuous improvement” principles. Key here is the approach of quality and security together; you simply cannot have security without quality.
The previous administration’s emphasis on attestation and artifacts, while perhaps cumbersome in its implementation, highlighted the critical need to understand your entire software stack. An SBOM, in short, is simply a comprehensive list of all components within a software application. Knowing what third-party components you have is paramount for effective remediation and risk management. Ideally, the consortium that’s called for in the new EO will help standardize and automate the delivery and consumption of this critical information, moving beyond just “paperwork” to more high-tech validation.
Navigating the Future: AI and Continuous Practices
The new EO also touches upon the use of AI in cybersecurity. While it pulls back on various initiatives to explore the use of AI for cyber defenses and prioritization of AI research by federal agencies, it simultaneously encourages responsible innovation with the maintaining of several directives from EO 14144. Furthermore, recent policies (25.21 and 25.22) address agencies using AI-assisted coding to accelerate development, stressing quality and security.
Looking at the bigger picture, agencies must proceed with caution but also leverage AI effectively where it can enhance code inspection and accelerate secure development. However, AI in software development doesn’t negate the foundational practices of the SSDF or SBOMs; it amplifies them. It particularly increases the need for independent verification of code contents, especially with potentially opaque AI-generated output.
To truly harness AI’s potential while mitigating its risks, agencies should adhere to several key guidelines:
- Put the supporting structure in place: Establish the necessary infrastructure and governance to manage AI risk, particularly related to information security and privacy.
- Manage AI accountability and risk: Implement comprehensive AI impact assessments, continuous monitoring, and human oversight.
- Test and validate the models — regularly: Conduct pre-deployment testing and ongoing validation of AI model performance, especially in real-world environments.
- Monitor and measure usage: Track how AI applications and tools are being used to identify risks, missed opportunities, or misalignments.
- Policy refresh: Update internal policies across IT infrastructure, data, cybersecurity, and privacy to effectively integrate AI.
- Curate well-documented use cases: Support consistent AI tool usage and proper prompting for faster adoption, plus follow mandates as outlined in EO 13960 and further clarified by OMB Memorandum M-24-10.
- Skill the workforce: Prioritize recruiting, hiring, training, and retaining technical talent in AI roles, and foster AI literacy across teams.
Ultimately, regardless of the specific policy directives, federal agencies must prioritize continuous code analysis and review. Whether through SBOMs or other capabilities, maintaining an up-to-date understanding of the pieces that make up your software is crucial for responsiveness and resilience. The DevSecOps mentality, supported by the right tools, remains the guiding star. The fundamental NIST SSDF principles endure; the question now is how agencies will implement the processes and tools to meet future audits and demonstrate a high bar for cyber integrity in an increasingly automated and interconnected world.
While the path to achieving a truly robust cyber posture may have a few new turns with this Executive Order, the destination remains the same. Agencies must continue to focus inward, cultivating a strong development culture that embeds security from the start, and demand the highest standards from their software partners. The threat landscape won’t wait for policy debates, and neither should our commitment to secure software.
Source: Security Magazine