[SPONSORED ARTICLE]

The recent update of the White House’s National Cybersecurity Strategy noted malicious packages and critical vulnerabilities–amongst other cyberthreat tactics -- as official threats to national security and holds tech firms responsible for building software that can withstand such malicious actors and their antics in the future amid rising cyber threats. This move by the Biden administration is another example in a long line of recent regulations that have brought open-source software (OSS) security into the spotlight. For context, open source software is currently used within mission-critical applications by 95% of IT organizations worldwide.

New security requirements and regulations impacting enterprises and government organizations are drafted almost monthly. Examples include the Executive Order from May 2021, the H.R. 7900 bill, the White House Office of Management and Budget memorandum on enhancing software supply chain security through secure software development practices, and the September 2022 bipartisan Securing OSS Act proposed to the House by the Cybersecurity Infrastructure and Security Agency. Let’s dig into a few of these here.

Common Vulnerabilities Exposure

In mid-2022, the US House of Representatives passed H.R. 7900, which forbids the Department of Defense (DoD) from procuring software applications containing common vulnerabilities exposures (CVE), a list of publicly disclosed software security flaws. According to H.R. 7900, software must be “free from all known vulnerabilities or defects affecting the security, end product, or service.” The important phrase here is, “affecting security.” If the CVE isn’t affecting the security of the software it’s OK to release. Vendors -- and the companies that use their solutions -- may change the configuration of the software to prevent themselves from being at risk and as long as the vendor discloses that risk to their customers, all will be well.One good resource for vendors to use on this front is the Vulnerability Exploitability eXchange (VEX), which is designed to communicate the exploitability of components with known vulnerabilities in the context of the product in which they are used. VEX allows software vendors and other parties to communicate the exploitability status of vulnerabilities, providing clarity on the vulnerabilities that pose risk and the ones that do not. VEX is a critical capability necessary to operationalize a software bill of materials (SBOM).

Similar to how the H.R. 7900 bill points to vendors doing business with the DoD, the OMB’s memo applies the same pressures to vendors doing business with any federal agency. The office’s memo refers to supply chain cybersecurity best practices established by the National Institute of Standards and Technology. These practices recommend a complete software inventory assessment, collecting statements from each outside software vendor that creates any products used by federal agencies -- otherwise known as a SBOM. As the world continues to deliver new and ever more complex technologies as part of wider interdependent systems, SBOMs are no longer nice to have, but rather a must-have for vendors and customers alike.

SBOM Explained

For those unfamiliar with SBOM, let me elaborate. Much like a car, software consists of many smaller parts all designed to work interdependently and the complete package (the car) can only operate properly if every piece is functioning correctly. In a software supply chain attack -- such as Log4j or SolarWinds -- the “car” had components that were compromised before arriving on the assembly line, which could cause the car to malfunction when someone is driving it. The government-issued orders listed above will require companies to sell the best “car” to the government and provide details on all the contained components (like spark plugs and light bulbs) plus their interdependencies.

Thus, rather than wringing their hands about new government compliance requirements, software vendors and customers should be celebrating the fact the US government has accepted secure agile software development, i.e., DevSecOps, as the new industry standard. Sen. Gary Peters (D-MI), co-sponsor of the OSS Software Act, called OSS “the bedrock of the digital world”, and we agree. JFrog can help vendors thrive in this new compliance environment.

To better serve the government mission, I urge vendors to embrace the need for secure OSS rather than just new ways to “check the box.” You should always practice good cyber hygiene that will help your organization comply with all new federal legislation, so you can continue selling stronger and more secure software that keeps the nation’s critical infrastructure, and the citizens that use it, safe.

Nati Davidi, Senior Vice President of JFrog Security, leads the global go-to-market strategy for JFrog’s security products and research. Previously he served as CEO of Vdoo, which delivered an integrated security platform and was acquired by JFrog in June 2021. Before Vdoo, Nati co-founded and led product management, sales, and marketing efforts for Cyvera, which was later acquired by Palo Alto Networks. He also served as an independent consultant for several startups and as a Captain in the Israeli Defense Forces.

JFrog Ltd. (Nasdaq: FROG), is on a mission to create a world of software delivered without friction from developer to device. Driven by a “Liquid Software” vision, the JFrog Software Supply Chain Platform is a single system of record that powers organizations to build, manage, and distribute software quickly and securely, ensuring it is available, traceable, and tamper-proof. The integrated security features also help identify, protect, and remediate against threats and vulnerabilities. JFrog’s hybrid, universal, multi-cloud platform is available as both self-hosted and SaaS services across major cloud service providers. Millions of users and 7K+ customers worldwide, including a majority of the FORTUNE 100, depend on JFrog solutions to securely embrace digital transformation. Learn more at www.jfrog.com or follow us @JfrogSecurity.