Digital Lock

Finding what's missing in your security processes using OpenChain's Security Assurance Standard

by Van Lindberg

One of the keys to success as an OSPO is balance: making sure that you have done enough, but do not have so many procedures and processes that they become counterproductive. But how do you know what is "enough"? One way is to use the OpenChain standards as a guide. This article focuses on the recent OpenChain Security Assurance Standard.

In our last article about OpenChain we provided a general introduction to the OpenChain 2.1 / ISO/IEC 5230 standard and how it fits into OSPO practices. But the OpenChain project hasn't been sitting still. A natural next step in support of the broader mission was to develop a guide to identify and present the minimum core set of requirements every Security Assurance program should satisfy with respect to the use of Open Source software.

What is helpful about the OpenChain Security Assurance Standard is that it helps organizations understand where they need processes and policies that they do not yet have. It is a valuable way to find what is missing in your open source security processes, just as the main OpenChain specification is useful for understanding what is missing from your general open source program.

The connection between this specification and the OpenChain ISO/IEC 5230:2020 standard is that identifying and tracking what software used and deployed is an inherent part of getting open source right - which makes it natural to use the same approach and information for security or export control.

This specification is intended to identify and describe the key requirements of a quality Security Assurance Program in the context of using Open Source Software. It focuses on a narrow subset of primary concern: checking Open Source Software against publicly known security vulnerabilities like CVEs, GitHub/GitLab vulnerability reports, and so on.

The OpenChain security assurance specification focuses on the “what” and “why” aspects of a quality Security Assurance Program rather than delving into to “how” and “when.” This is a conscious decision to ensure flexibility for organizations of any size and in any market to use this reference specification. This approach, along with the types of processes identified, is built on more than half a decade of practical global feedback around the creation and management of such programs. The result is that a company can frame a program that precisely fits their supply chain requirements, scoped to a single product or a complete legal entity, and take this solution to market quickly and effectively.