The new “Executive Order on Improving the Nation’s Cybersecurity” details concrete actions your Open Source Program Office (OSPO) can perform in order to strengthen your organization’s cybersecurity posture, while allowing for better compliance. As such, I will be focusing on what the new Executive Order will mean for those in an OSPO, or in a different type of Open Source Compliance role.
The Executive Order (EO) “Executive Order on Improving the Nation’s Cybersecurity” deals with new software security standards, tooling, and guidance on best practices. There are also many aspects of the EO, including refined guidance, and minimum elements of an SBOM that will be released over time, according to the milestones specified in the Order.
The EO applies directly to U.S. federal departments, and their technology partners and suppliers, while encouraging the broader commercial technology industry, including their purchasing practices and supply chains, to adopt the same strategy and practices. If you don’t meet these standards, you won’t be permitted to sell software to the U.S. government.
Section 4 of the Executive Order is titled “Enhancing Software Supply Chain Security”, and is where the bulk of the guidance and overlap resides regarding management of Open Source. Open Source Software is specifically called out in the Order, and for good reason – we know the vast majority of today’s software applications are made up of Open Source Software. Put another way, very little of today’s software is fully custom-built from scratch.
SBOM’s (Software Bill of Materials), or sometimes also called an OSS BoM (Open Source Software Bill of Materials) are already part of procurement processes in many industries and organizations. The EO will, as one of the deliverable milestones, define what the minimum elements of that SBOM are, but expect those to act as a common framework for documenting use of Open Source Software. SBOM’s inherently bring transparency into how much and what kind of Open Source was used within a given software product or application, which allows those upstream to be able to make better security and compliance decisions.
What Role can the Open Source Program Office Play?
Your OSPO (or similar internal organization) has the background and resources to initiate or expand the creation and management of an SBOM for your products or applications.
In general, when this inventory of Open Source is documented for a given product or application, it is done so on an SBOM (or OSS BoM). In my consulting practice, I often advise my clients to first focus on inventory of Open Source for the same reason mentioned earlier – you can’t fix the software you aren’t aware you have. This is often one of the first lines of defense for determining risk. It also happens to be the starting point that SBOM’s can be built from, which makes this effort low-hanging fruit.
Having and maintaining an accurate inventory of your Open Source usage gives you the opportunity to quickly identify vulnerable components, and to prioritize remediation activities. If you are looking to start somewhere, a manual inventory of your Open Source usage in a spreadsheet can be a good starting point, but is not scalable long-term. Ideally, a Software Composition Analysis (SCA) solution that is integrated with your Software Development Life Cycle (SDLC) will allow you to automatically inventory your usage, and help you keep on top of it.
What’s in it for you?
Most of what you will read regarding the recent supply chain attacks have addressed the vulnerabilities in the supply chain, which is clearly important. Another, perhaps less talked about view, would be to look at what an available, and accurate inventory might be able to do for your organization following a similar attack or even disclosure of known vulnerability.
Following the SolarWinds attack, I heard from a large, well-known software company that they were able to determine in just a couple hours that none of their products were affected. This was because they had an accurate inventory of their software, which included Open Source and other third-party software.
If they determined they were impacted, they could have taken immediate action to reduce potential damage by shutting down products and services quickly, as opposed to the extended delays determining where any impacted components might have been. That said, an SBOM is not a silver bullet for security – an SBOM would not have stopped that kind of attack, but it does give you the ability to react quickly to any threats.
How We Can Help
Whether you are just starting out, or you are further along in your maturity of managing your Open Source usage, we’re here to help. If you need to create a Bill of Materials, our team can work with you in order to create one for you. We are also well versed in helping organizations understand the impact of the findings, and setting up the policies and processes to manage future Open Source compliance and security responses.
If you’re not sure how much Open Source you are using, or are wondering if a Bill of Materials process is appropriate for you, our team can perform a scan and audit of your codebase for you. In some cases, we can perform a high-level, no-cost scan of your codebase – contact us to find out more.
Additionally, if you are looking to bring the process of creating and managing Bills of Materials in-house, but are not sure which SCA tool is right for you, we have experience using the most popular SCA solutions on the market. We can help you identify the right tool that will meet the specific needs of your company.
Want to get started? Give us a call at 313-730-4677 to discuss, or request more info here.