Organizations of every shape, size, and sector have embraced open-source software (OSS). The financial, medical, and manufacturing industries – and even national security – now use OSS to power their most critical applications and activities. However, this widespread adoption comes with pitfalls: a corresponding increase of almost 800% in software supply chain attacks according to the State of the Software Supply Chain from Sonatype.

With the rapid growth of OSS adoption, organizations have begun to stand up Open Source Program Offices (OSPOs) to help codify strategies around OSS use and contribution and to foster collaboration with the broader OSS community. These OSPO’s often have key responsibilities such as cultivating an OSS strategy, leading its execution, and facilitating the use of OSS products and services across an enterprise.

The OSPO as key strategic security element

The OSPO’s unique position in leading OSS management and strategy makes it a key player in an organization’s approach to security and governance of OSS, an increasingly critical role.

OSS requires careful management. Studies show that modern applications include more than 500 OSS components. With such widespread use, it’s important to recognize some alarming statistics concerning OSS components. According to a 2022 Synopsis survey, 81% include at least one vulnerability, 88% haven’t had new development in the past two years, and 88% of those used were not the latest version. All these metrics culminate in one alarming reality: Organizations are making extensive use of outdated and insecure components. This means we have a massive attack surface in modern enterprise environments that are poorly governed and rich in pathways for malicious actors.

By now, everyone is familiar with the US Cybersecurity Executive Order (EO), including Section 4, “Enhancing Software Supply Chain Security.” As a result of the EO, the National Institute of Standards and Technology (NIST) has produced comprehensive software supply chain guidance, including Open Source Software Controls, which we will discuss here, as well as how OSPO’s can advocate for their implementation.

NIST lays out its suite of OSS controls in three maturity tiers: foundational, sustaining, and enhancing capabilities. Among those controls are things such as using aspects of the NIST Secure Software Development Framework (SSDF) and ensuring OSS components are acquired via secure channels from trustworthy sources. The reality of the modern enterprise environment is that most organizations don’t have full visibility and governance of their organization’s OSS use, let alone ongoing monitoring of the vulnerabilities associated with it.

The OSPO as evangelist for effective, safe use of OSS

This is a perfect example of where the OSPO shines: as an evangelist for the effective use of commercial OSS products and services, advocating vigilance for the vulnerabilities associated with OSS, and ensuring that these security practices are codified into organizational policies and processes.

NIST’s recommended OSS security controls also include establishing internal repositories of known and vetted OSS components that developers can use to reduce organizational risk. Rather than allowing an environment in which developers are free to pull and use any and all OSS components without insight into their vulnerabilities and risk, internal repositories create a robust library of OSS components that enable developer velocity while also driving down organizational risk due to vulnerable OSS component usage.

Another key recommendation of the NIST SSDF is to implement supporting toolchains, including specifying which tools must be included in the CI/CD pipelines to mitigate risks. Examples could include integrating things such as software composition analysis (SCA) and software bill of materials (SBOM) tooling into modern CI/CD toolchains to ensure the enterprise gets full visibility of vulnerable OSS components moving through toolchains and into production environments.

This also facilitates the push to “shift security left,” ensuring security scans occur earlier in the software development lifecycle and vulnerabilities are identified and remediated prior to introducing them into production where they can be exploited by malicious actors. Policies and processes that OSPO’s can evangelize and codify in this area include not only vulnerability scanning and SBOM’s but also enabling signing capabilities that help create immutable records and logs to support both integrity and auditability of software development activities.

Moving on to the most mature tier laid out by NIST – enhancing capabilities – includes prioritizing the use of secure programming languages and ultimately automating the collection, storage, and scanning of OSS components into the previously mentioned hardened internal repositories. This is perhaps the most critical step to help drive down risk while also not impeding the velocity of development teams, which if hindered would certainly just work around organizational policies and processes to accomplish their tasks.

OSPO roles: developer relations, advocacy, and evangelism

Among the commonly filled roles in an OSPO are developer relations, advocacy, and evangelism. While these groups often build enthusiasm and interest among the company’s development teams, they’re also often about forging critical relationships. Those relationships can be leveraged to encourage buy-in to emerging OSS security best practices, which many organizations simply haven’t implemented yet despite broad OSS usage in their applications, software, and products. This creates multiple benefits, such as ensuring the organization minimizes use of insecure dependencies and produces more secure applications, whether for internal or external purposes.

Another thing worth mentioning is that the US federal government recently released a memo that will require all third-party software vendors selling software to the government to self-attest they are aligned with the NIST SSDF and other NIST software supply chain guidance. Many of the activities and practices outlined in SSDF revolve around the development team naturally as part of the software development process. The OSPO can use developer relationships to ensure the shift to align with this requirement for vendors working with the government isn’t too disruptive.

Research, such as that from Chinmayi Sharma, also suggests that software vendors are the primary beneficiaries of OSS, and are therefore in the best position to help address OSS supply chain risk. This places software vendors in a great position to become more involved in OSS communities, scan for vulnerabilities, and contribute to OSS projects to mitigate them. This would be a shift from the current model in which the OSS community largely shoulders this burden themselves with a lack of equal participation and contribution from the software vendor community.

This places OSPOs in a perfect position to lead a paradigm shift and ultimately bolster the security of the broader OSS supply chain. OSS has led to innovations and capabilities in nearly every industry. OSPOs are now positioned to lead the charge of those industries and associated organizations becoming more involved in the OSS community while also addressing the current system risk that OSS poses due to disjointed involvement and investment.

Copyright © 2022 IDG Communications, Inc.