I had a discussion with Dick Brooks about government regulations and open source software security. The conversation covered the frameworks that affect enterprise software, users of open source, and open source developers. At the moment, all these regulations don’t mean a ton for open source developers, which is good news.
Dick is the co-founder of Business Cyber Guardian and former enterprise architect at ISO New England. He’s a self proclaimed old school software engineer who worked at Digital Equipment Corporation. These days Dick is involved in working on secure development programs with governments around the world.
The U.S. government’s approach to software security has changed quite a bit in recent years. Multiple executive orders now define secure software development as well as procurement. The latest executive order from January 2025 builds upon frameworks established in 2019 and even before, we see a focus on secure by design and secure by default practices for federal agencies.
Dick has helped develop is CISA’s Software Acquisition Guide (SAG). This guide establishes specific requirements for software vendors selling to federal agencies. The guide helps define the process where a vendor will end up submitting documentation like Software Bills of Materials (SBOMs) and security attestations aligned with NIST’s Secure Software Development Framework (SSDF) to a portal CISA is running, Repository for Software Attestations and Artifacts (RSAA). If vendors can’t meet all the attestation requirements, they can submit what’s called a POAM - Plan of Action and Milestones - to address the gaps. CISA is actively pushing this beyond federal agencies too - Dick is hosting a webinar for state procurement officers to help states adopt these practices. Dick was kind enough to give me the link to a SSDF webinar he did with NASA.
We also touch on topics beyond U.S. borders. The EU’s Cyber Resilience Act (CRA) introduces requirements for secure software development with implementation that’s set to be required in 2027. Dick is involved with similar standards in Japan and Australia, no doubt we’ll see similar security standards in nearly every country soon.
For open source projects how a project is affected isn’t completely clear. It depends on how the software is distributed and commercialized. Pure open source projects distributing software freely through platforms like GitHub generally fall outside the scope of the requirements. However, companies incorporating open source components into commercial products are on the hook, they don’t get a free pass because “open source”. We also touched on some of the challenges for open source projects around incidents like Log4Shell. While enterprises aren’t off the hook for compliance requirements, they also can’t be asking the open source projects to do their homework. We’ll see how that all shakes out in the coming years.
We also touched on an open source project Dick is working on to help with some of this. CISA has a Software Acquisition Guide that’s quite a lot of paperwork for anyone to fill out. The current system heavily relies on Excel spreadsheets, so Dick wrote something called SAG reader, a Python program that automates the processing of the CISA SAG spreadsheets.
Dick Explains a new Federal Acquisition Regulation (FAR) rule is expected to provide more specific requirements for vendors. Dick expects the Office of the National Cyber Director (ONCD) may establish a trust registry to make software security evaluations publicly accessible, probably affecting software purchasing just the federal government.
It was a fun chat with Dick about all these topics. Understanding the nuances of the government, particularly the distinctions between commercial and open source, is going to be a wild ride in the next few years.