The National Telecommunications and Information Administration (NTIA) recently asked for wide-ranging feedback to define a minimum Software Bill of Materials (SBOM). It was framed with a single, simple question (“What is an SBOM?”), and constituted an incredibly important step towards software security and a significant moment for open standards.

From NTIA’s SBOM FAQ  “A Software Bill of Materials (SBOM) is a complete, formally structured list of components, libraries, and modules that are required to build (i.e. compile and link) a given piece of software and the supply chain relationships between them. These components can be open source or proprietary, free or paid, and widely available or restricted access.”  SBOMs that can be shared without friction between teams and companies are a core part of software management for critical industries and digital infrastructure in the coming decades.

The ISO International Standard for open source license compliance (ISO/IEC 5230:2020 – Information technology — OpenChain Specification) requires a process for managing a bill of materials for supplied software. This aligns with the NTIA goals for increased software transparency and illustrates how the global industry is addressing challenges in this space. For example, it has become a best practice to include an SBOM for all components in supplied software, rather than isolating these materials to open source.

The open source community identified the need for and began to address the challenge of SBOM “list of ingredients” over a decade ago. The de-facto industry standard, and most widely used approach today, is called Software Package Data Exchange (SPDX). All of the elements in the NTIA proposed minimum SBOM definition can be addressed by SPDX today, as well as broader use-cases.

SPDX evolved organically over the last decade to suit the software industry, covering issues like license compliance, security, and more. The community consists of hundreds of people from hundreds of companies, and the standard itself is the most robust, mature, and adopted SBOM in the market today. 

The full SPDX specification is only one part of the picture. Optional components such as SPDX Lite, developed by Pioneer, Sony, Hitachi, Renesas, and Fujitsu, among others, provide a focused SBOM subset for smaller supplier use. The nature of the community approach behind SPDX allows practical use-cases to be addressed as they arose.

In 2020, SPDX was submitted to ISO via the PAS Transposition process of Joint Technical Committee 1 (JTC1) in collaboration with the Joint Development Foundation. It is currently in the approval phase of the transposition process and can be reviewed on the ISO website as ISO/IEC PRF 5962.

The Linux Foundation has prepared a submission for NTIA highlighting knowledge and experience gained from practical deployment and usage of SBOM in the SPDX and OpenChain communities. These include isolating the utility of specific actions such as tracking timestamps and including data licenses in metadata. With the backing of many parties across the worldwide technology industry, the SPDX and OpenChain specifications are constantly evolving to support all stakeholders.

Industry Comments

The Sony team uses various approaches to managing open source compliance and governance… An example is using an OSS management template sheet based on SPDX Lite, a compact subset of the SPDX standard. Teams need to be able to review the type, version, and requirements of software quickly, and using a clear standard is a key part of this process.

Hisashi Tamai, SVP, Sony Group Corporation, Representative of the Software Strategy Committee

“Intel has been an early participant in the development of the SPDX specification and utilizes SPDX, as well as other approaches, both internally and externally for a number of open source software use-cases.”

Melissa Evers, Vice President – Intel Architecture, Graphics, Software / General Manager – Software Business Strategy

Scania corporate standard 4589 (STD 4589) was just made available to our suppliers and defines the expectations we have when Open Source is part of a delivery to Scania. So what is it we ask for in a relationship with our suppliers when it comes to Open Source? 

1) That suppliers conform to ISO/IEC 5230:2020 (OpenChain). If a supplier conforms to this specification, we feel confident that they have a professional management program for Open Source.  

2) If in the process of developing a solution for Scania, a supplier makes modifications to Open Source components, we would like to see those modifications contributed to the Open Source project. 

3) Supply a Bill of materials in ISO/IEC DIS 5962 (SPDX) format, plus the source code where there’s an obligation to offer the source code directly, so we don’t need to ask for it.

Jonas Öberg, Open Source Officer – Scania (Volkswagen Group)

The SPDX format greatly facilitates the sharing of software component data across the supply chain. Wind River has provided a Software Bill of Materials (SBOM) to its customers using the SPDX format for the past eight years. Often customers will request SBOM data in a custom format. Standardizing on SPDX has enabled us to deliver a higher quality SBOM at a lower cost.

Mark Gisi, Wind River Open Source Program Office Director and OpenChain Specification Chair

The Black Duck team from Synopsys has been involved with SPDX since its inception, and I had the pleasure of coordinating the activities of the project’s leadership for more than a decade. In addition, representatives from scores of companies have contributed to the important work of developing a standard way of describing and communicating the content of a software package.

Phil Odence, General Manager, Black Duck Audits, Synopsys

With the rapidly increasing interest in the types of supply chain risk that a Software Bill of Materials helps address, SPDX is gaining broader attention and urgency. FossID (now part of Snyk) has been using SPDX from the start as part of both software component analysis and for open source license audits. Snyk is stepping up its involvement too, already contributing to efforts to expand the use cases for SPDX by building tools to test out the draft work on vulnerability profiles in SPDX v3.0.

Gareth Rushgrove, Vice President of Products, Snyk

For more information on OpenChain: https://www.openchainproject.org/

For more information on SPDX: https://spdx.dev/

References:

Jason Perlow, Director of Project Insights and Editorial Content, spoke with Stephen Hendrick about Linux Foundation Research and how it will promote a greater understanding of the work being done by open source projects, their communities, and the Linux Foundation.

JP: It’s great to have you here today, and also, welcome to the Linux Foundation. First, can you tell me a bit about yourself, where you are from, and your interests outside work?

SH: I’m from the northeastern US.  I started as a kid in upstate NY and then came to the greater Boston area when I was 8.  I grew up in the Boston area, went to college back in upstate NY, and got a graduate degree in Boston.  I’ve worked in the greater Boston area since I was out of school and have really had two careers.  My first career was as a programmer, which evolved into project and product management doing global cash management for JPMC.  When I was in banking, IT was approached very conservatively, with a tagline like yesterday’s technology, tomorrow.  The best thing about JPMC was that it was where I met my wife.  Yes, I know, you’re never supposed to date anybody from work.  But it was the best decision I ever made.  After JPMC, my second career began as an industry analyst working for IDC, specializing in application development and deployment tools and technologies.  This was a long-lived 25+ year career followed by time with a couple of boutique analyst firms and cut short by my transition to the Linux Foundation.

Until recently, interests outside of work mainly included vertical pursuits — rock climbing during the warm months and ice climbing in the winter.  The day I got engaged, my wife (to be) and I had been climbing in the morning, and she jokes that if she didn’t make it up that last 5.10, I wouldn’t have offered her the ring.  However, having just moved to a house overlooking Mt. Hope bay in Rhode Island, our outdoor pursuits will become more nautically focused.

JP: And from what organization are you joining us?

SH: I was lead analyst at Enterprise Management Associates, a boutique industry analyst firm.  I initially focused my practice area on DevOps, but in reality, since I was the only person with application development and deployment experience, I also covered adjacent markets that included primary research into NoSQL, Software Quality, PaaS, and decisioning.  

JP: Tell me a bit more about your academic and quantitative analysis background; I see you went to Boston University, which was my mom’s alma mater as well. 

SH:  I went to BU for an MBA.  In the process, I concentrated in quantitative methods, including decisioning, Bayesian methods, and mathematical optimization.  This built on my undergraduate math and economics focus and was a kind of predecessor to today’s data science focus.  The regression work that I did served me well as an analyst and was the foundation for much of the forecasting work I did and industry models that I built.  My qualitative and quantitative empirical experience was primarily gained through experience in the more than 100 surveys and in-depth interviews I have fielded.  

JP: What disciplines do you feel most influence your analytic methodology? 

SH: We now live in a data-driven world, and math enables us to gain insight into the data.  So math and statistics are the foundation that analysis is built on.  So, math is most important, but so is the ability to ask the right questions.  Asking the right questions provides you with the data (raw materials) shaped into insights using math.  So analysis ends up being a combination of both art and science.

JP: What are some of the most enlightening research projects you’ve worked on in your career? 

SH:  One of the most exciting projects I cooked up was to figure out how many professional developers there were in the world, by country, with five years of history and a 5-year forecast.  I developed a parameterized logistics curve tuned to each country using the CIA, WHO, UN, and selected country-level data.  It was a landmark project at the time and used by the world’s leading software and hardware manufacturers. I was flattered to find out six years later that another analyst firm had copied it (since I provided the generalized equation in the report).

I was also interested in finding that an up-and-coming SaaS company had used some of my published matrix data on language use, which showed huge growth in Ruby.  This company used my findings and other evidence to help drive its acquisition of a successful Ruby cloud application platform.

JP: I see that you have a lot of experience working at enterprise research firms, such as IDC, covering enterprise software development. What lessons do you think we can learn from the enterprise and how to approach FOSS in organizations adopting open source technologies?

SH: The analyst community has struggled at times to understand the impact of OSS. Part of this stems from the economic foundation of the supply side research that gets done.  However, this has changed radically over the past eight years due to the success of Linux and the availability of a wide variety of curated open source products that have helped transform and accelerate the IT industry.  Enterprises today are less concerned about whether a product/service is open or closed source.  Primarily they want tools that are best able to address their needs. I think of this as a huge win for OSS because it validates the open innovation model that is characteristic of OSS. 

JP: So you are joining the Linux Foundation at a time when we have just gotten our research division off the ground. What are the kind of methodologies and practices that you would like to take from your years at firms like IDC and EMA and see applied to our new LF Research?

SH: LF is in the enviable position of having close relationships with IT luminaries, academics, hundreds of OSS projects, and a significant portion of the IT community.  The LF has an excellent opportunity to develop world-class research that helps the IT community, industry, and governments better understand OSS’s pivotal role in shaping IT going forward.

I anticipate that we will use a combination of quantitative and qualitative research to tell this story.  Quantitative research can deliver statistically significant findings, but qualitative interview-based research can provide examples, sound bites, and perspectives that help communicate a far more nuanced understanding of OSS’s relationship with IT.

JP: How might these approaches contrast with other forms of primary research, specifically human interviews? What are the strengths and weaknesses of the interview process?

SH: Interviews help fill in the gaps around discrete survey questions in ways that can be insightful, personal, entertaining, and unexpected.  Interviews can also provide context for understanding the detailed findings from surveys and provide confirmation or adjustments to models based on underlying data.

JP: What are you most looking forward to learning through the research process into open source ecosystems?

SH: The transformative impact that OSS is having on the digital economy and helping enterprises better understand when to collaborate and when to compete.

JP: What insights do you feel we can uncover with the quantitative analysis we will perform in our upcoming surveys? Are there things that we can learn about the use of FOSS in organizations?

SH: A key capability of empirical research is that it can be structured to highlight how enterprises are leveraging people, policy, processes, and products to address market needs.  Since enterprises are widely distributed in their approach and best/worst practices to a particular market, data can help us build maturity models that provide advice on how enterprises can shape strategy and decision based on the experience and best practices of others.

JP: Trust in technology (and other facets of society) is arguably at an all-time low right now. Do you see a role for LF Research to help improve levels of trust in not only software but in open source as an approach to building secure technologies? What are the opportunities for this department?

SH: I’m reminded by the old saying that there are “lies, damned lies, and then there are statistics.” If trust in technology is at an all-time low, it’s because there are people in this world with a certain moral flexibility, and the IT industry has not yet found effective ways to prevent the few from exploiting the many.  LF Research is in the unique position to help educate and persuade through factual data and analysis on accelerating improvements in IT security.

JP: Thanks, Steve. It’s been great talking to you today!

The TODO Group, together with Linux Foundation Research and The New Stack, is conducting a survey as part of a research project on the prevalence and outcomes of open source programs among different organizations across the globe. 

Open source program offices (OSPOs) help set open source strategies and improve an organization’s software development practices. Since 2018, the TODO Group has conducted surveys to assess the state of open source programs across the industry. Today, we are pleased to announce the launch of the 2021 edition featuring additional questions to add value to the community.

The survey will generate insights into the following areas, including:

  • The extent of adoption of open source programs and initiatives 
  • Concerns around the hiring of open source developers 
  • Perceived benefits and challenges of open source programs
  • The impact of open source on organizational strategy

We hope to expand the pool of respondents by translating the survey into Chinese and Japanese. Please participate now; we intend to close the survey in early July. Privacy and confidentiality are important to us. Neither participant names, nor their company names, will be published in the final results.

To take the 2021 OSPO Survey, click the button below:

BONUS

As a thank you for completing this survey, you will receive a 75% discount code on enrollment in The Linux Foundation’s Open Source Management & Strategy training program, a $375 savings. This seven-course online training series is designed to help executives, managers, and software developers understand and articulate the basic concepts for building effective open source practices within their organization.


PRIVACY

Your name and company name will not be published. Reviews are attributed to your role, company size, and industry. Responses will be subject to the Linux Foundation’s Privacy Policy, available at https://linuxfoundation.org/privacy. Please note that survey partners who are not Linux Foundation employees will be involved in reviewing the survey results. If you do not want them to have access to your name or email address, please do not provide this information.

VISIBILITY

We will summarize the survey data and share the findings during OSPOCon 2021. The summary report will be published on the TODO Group and Linux Foundation websites. 

QUESTIONS

If you have questions regarding this survey, please email us at info@todogroup.org

FINOS, the fintech open source foundation, and its research partners, Linux Foundation Research, Scott Logic, WIPRO, and GitHub, are conducting a survey as part of a research project on the state of open source adoption, contribution, and readiness in the financial services industry. 

The increased prevalence, importance, and value of open source is well understood and widely reported by many industry surveys and studies. However, the rate at which different industries are acknowledging this shift and adapting their own working practices to capitalize on the new world of open source-first differs considerably.

The financial services industry has been a long-time consumer of open source software, however many are struggling in contributing to, and publishing, open source software and standards, and adopting open source methodologies. A lack of understanding of how to build and deploy efficient tooling and governance models are often seen as a limiting factor.

This survey and report seeks to explore open source within the context of financial services organizations; including banks, asset managers, and hedge funds but will be designed as a resource to be used by all financial services organizations, with the goal to make this an annual survey with a year-on-year tracing of metrics. 

Please participate now; we intend to close the survey in early July. Privacy and confidentiality are important to us. Neither participant names, nor their company names, will be published in the final results.

To take the 2021 FINOS Survey, click the button below:

BONUS

As a thank-you for completing this survey, you will receive a 75% discount code on enrollment in the Linux Foundation’s Open Source Management & Strategy training program, a $375 savings. This seven-course online training series is designed to help executives, managers, and software developers understand and articulate the basic concepts for building effective open source practices within their organization.


PRIVACY

Your name and company name will not be published. Reviews are attributed to your role, company size, and industry. Responses will be subject to the Linux Foundation’s Privacy Policy, available at https://linuxfoundation.org/privacy. Please note that survey partners who are not Linux Foundation employees will be involved in reviewing the survey results. If you do not want them to have access to your name or email address, please do not provide this information.

VISIBILITY

We will summarize the survey data and share the findings during Open Source Strategy Forum, 2021. The summary report will be published on the FINOS and Linux Foundation websites. 

QUESTIONS

If you have questions regarding this survey, please email us at info@finos.org

Jason Perlow, Director of Project Insights and Editorial Content at the Linux Foundation, spoke with Daniel Scales about the importance of protecting trademarks in open source projects.

JP: It’s great to have you here today, and also, welcome to the Linux Foundation. First, can you tell me a bit about yourself, where you are from, and your interests outside work?

DS: Thanks, Jason! It is great to be here. I grew up in Upstate New York, lived in Washington and London for a few years after college, and have been in Boston for the last 20+ years. Outside of work, I coach my daughter’s soccer team, I like to cook and play my bass guitar, and I am really looking forward to getting back to some live music and sporting events. 

JP: And from what organization are you joining us?

DS: I have been with the Boston law firm Choate, Hall & Stewart since 2011. In addition to advising The Linux Foundation and other clients on trademark matters, I helped clients with open source license questions, technology licenses, and IP-focused transactions.  Before Choate, I worked as IP Counsel at Avid Technology, where I managed their trademark portfolio through a global rebranding and supported the engineering team on technology licenses. 

JP: So, how did you get into Intellectual Property law?

DS: Great question.  I studied economics in college and took a fantastic senior seminar on the economics of intellectual property.  After graduation, I worked in the economics consulting group at Ernst & Young.  A big part of my job there was determining the value of a company’s intangible property, which in many cases were its brands. I went to law school intending to study trademarks and the new field of “internet law” (this term probably dates me) and started my legal career at Testa, Hurwitz & Thibeault, which had a cutting-edge trademark and open source group.

JP: We typically think of IP and Trademark law as it applies to consumer products and commercial entities. What is the difference between those and when open source projects and organizations use brands?

DS:  On one level, there really isn’t a difference.  A trademark signifies the unique source of a good or service. Trademarks help consumers, developers, and users distinguish various offerings, and they communicate the specific source and quality of those offerings.  Software developers and users need to understand what code they have and where it came from. Trademarks help communicate that information.  Of course, the specific issues that every brand and brand owner faces and how they address them are different, but many of the core principles are the same.

JP: What are some of the trademark issues you’ve seen come up in open source communities?

DS: While it happens in every industry, I see many “helpful” people apply to register projects’ trademarks when they are not the rightful owner.  Sometimes they have good intentions, sometimes not, but it can be a lot of work to sort it out either way.  I’ve also had the opportunity to work with many different people and companies on project branding. It is amazing how many different philosophies there are regarding branding, even within the software industry.  Much of what we do is to bring these folks together to determine the best approach for the specific project.  I also spend a lot of time debating the scope of trademark rights with opposing counsel, but that isn’t really unique to open source:  one lawyer tried to convince me that his client had the exclusive right to use a picture of a hop flower on a beer label. 

Other common issues are helping companies register a mark for their company or product and then used the same mark for an open source project. The neutrality of those situations is imbalanced, and the Linux Foundation has worked with organizations making this transition. Sometimes it involves rebranding the open source project, and we assist in finding and clearing a new name for the community to use independent of the company that started it.

JP: Why is the Linux Foundation a good place for open source projects to protect their brands?

DS: We have worked with many open source projects on their trademarks, and we learn something with every new experience.  We can help them name the project at the beginning, take steps to protect their trademarks across the globe, and show them how trademarks can be a tool to build their communities and increase participation and adoption.  We also recognize the importance of our neutral position in the industries we serve and how that is fundamental to open governance.

Also Read: Open Source Communities and Trademarks: A Reprise

JP: Trademark conformance can also protect a project from technical drift. How can a trademark conformance program be used to encourage conformance with a project’s code base or interfaces? 

DS: Great point. As in most areas of trademarks, clarity and consistency are key. Trademarks used in a conformance program can be a great tool to communicate quickly and accurately to the target community.  Projects can develop specific and transparent criteria so that users understand exactly what the conformance trademark symbolizes.  This can be much more effective and efficient for projects and users alike than everyone deciding for themselves what a term like “compatible” might mean.  

Also Read: Driving Compatibility with Code and Specifications through Conformance Trademark Programs

JP: Do projects at the Linux Foundation give up all control of their trademark? How do you decide what enforcement to pursue or not pursue?

DS: On the contrary — we work very closely with project leadership throughout the lifecycle of their trademarks.  This includes trademark enforcement.  Typically, the first step is to figure out whether the situation requires enforcement (in the traditional legal sense) or if it is simply a matter of educating another party.  More often than not, we can reach out to the other party, discuss our project and our trademarks, discuss our concerns, and work out a solution that works for everyone and strengthens our brands.  But like any brand owner, we do sometimes have to take other action to protect our projects’ trademarks, and we work closely with our projects in those situations, too.

JP: Thanks, Daniel. It’s been great talking to you today!

There is an exciting convergence in the networking industry around open source, and the energy is palpable. At LF Networking, we have a unique perspective as the largest open source initiative in the networking space with the broadest set of projects that make up the diverse and evolving open source networking stack. LF Networking provides platforms and building blocks across the networking industry that enable rapid interoperability, deployment, and adoption and is the nexus for 5G innovation and integration. 

LF Networking has now tapped confluence on industry efforts to structure a new initiative to develop 5G Super Blueprints for the ecosystem. Major integrations between the building blocks are now underway–between ONAP and ORAN, Akraino and Magma, Anuket and Kubernetes, and more. 

“Super” means that we’re integrating multiple projects, umbrellas (such as LF Edge, Magma, CNCF, O-RAN Alliance, LF Energy, and more) with an end-to-end framework for the underlying infrastructure and application layers across edge, access, and core. This end-to-end integration enables top industry use cases, such as fixed wireless, mobile broadband, private 5G, multi-access, IoT, voice services, network slicing, and more. In short, 5G Super Blueprints are a vehicle to collaborate and create end-to-end 5G solutions.

Major industry verticals banking on this convergence and roadmap include the global telcos that you’d expect, but 5G knows no boundaries, and we’re seeing deep engagement from cloud service providers, enterprise IT, governments, and even energy.

5G is poised to modernize today’s energy grid with awareness monitoring across Distribution Systems and more.

This will roll out in 3 phases, the first encompassing 5G Core + Multi-access Edge Computing (MEC) using emulators. The second phase introduces commercial RANs to end-to-end 5G, and the third phase will integrate Open Radio Access Network (O-RAN). 

The 5G Super Blueprint is an open initiative, and participation is open to anyone. To learn more, please see the 5G Super Blueprint FAQ and watch the video, What is the 5G Super Blueprint? from Next Gen Infra

Participation in this group has tripled over the last few weeks! If you’re ready to join us, please indicate your interest in participation on the 5G Super Blueprint webpage, and follow the onboarding steps on the 5G Super Blueprint Wiki. Send any questions to superblueprint@lfnetworking.org

As we think about the future of the software industry, we believe we have a responsibility to help build a better future – a more sustainable future – both internally at our organizations and in partnership with industry leaders around the globe. With data centers around the world accounting for 1% of global electricity demand, and projections to consume 3-8% in the next decade, it’s imperative we address this as an industry.


To help in that endeavor, we’re excited to announce the formation of The Green Software Foundation – a nonprofit founded by Accenture, GitHub, Microsoft, and ThoughtWorks established with the Linux Foundation and the Joint Development Foundation Projects LLC to build a trusted ecosystem of people, standards, tooling, and leading practices for building green software.

Read more at The Microsoft Blog

Author: Kate Stewart, VP of Dependable Systems, The Linux Foundation

In a previous Linux Foundation blog, David A. Wheeler, director of LF Supply Chain Security, discussed how capabilities built by Linux Foundation communities can be used to address the software supply chain security requirements set by the US Executive Order on Cybersecurity. 

One of those capabilities, SPDX, completely addresses the Executive Order 4(e) and 4(f) and 10(j) requirements for a Software Bill of Materials (SBOM). The SPDX specification is implemented as a file format that identifies the software components within a larger piece of computer software and metadata such as the licenses of those components. 

SPDX is an open standard for communicating software bill of material (SBOM) information, including components, licenses, copyrights, and security references. It has a rich ecosystem of existing tools that provides a common format for companies and communities to share important data to streamline and improve the identification and monitoring of software.

SBOMs have numerous use cases. They have frequently been used in areas such as license compliance but are equally useful in security, export control, and broader processes such as mergers and acquisitions (M&A) processes or venture capital investments. SDPX maintains an active community to support various uses, modeling its governance and activity on the same format that has successfully supported open source software projects over the past three decades.

The LF has been developing and refining SPDX for over ten years and has seen extensive uptake by companies and projects in the software industry.  Notable recent examples are the contributions by companies such as Hitachi, Fujitsu, and Toshiba in furthering the standard via optional profiles like “SPDX Lite” in the SPDX 2.2 specification release and in support of the SPDX SBOMs in proprietary and open source automation solutions. 

This de facto standard has been submitted to ISO via the Joint Development Foundation using the PAS Transposition process of Joint Technical Committee 1 (JTC1). It is currently in the enquiry phase of the process and can be reviewed on the ISO website as ISO/IEC DIS 5962.

There is a wide range of open source tooling, as well as commercial tool options emerging as well as options available today.  Companies such as FOSSID and Synopsys have been working with the SPDX format for several years. Open Source tools like FOSSology (source code Analysis),  OSS Review Toolkit (Generation from CI & Build infrastructure), Tern (container content analysis), Quartermaster (build extensions), ScanCode (source code analysis) in addition to the SPDX-tools project have also standardized on using SPDX for the interchange are also participating in Automated Compliance Tooling (ACT) Project Umbrella.  ACT has been discussed as community-driven solutions for software supply chain security remediation as part of our synopsis of the findings in the Vulnerabilities in the Core study, which was published by the Linux Foundation and Harvard University LISH in February of 2020.   

One thing is clear: A software bill of materials that can be shared without friction between different teams and companies will be a core part of software development and deployment in this coming decade. The sharing of software metadata will take different forms, including manual and automated reviews, but the core structures will remain the same. 

Standardization in this field, as in others, is the key to success. This domain has an advantage in that we are benefiting from an entire decade of prior work in SPDX. Therefore the process becomes the implementation of this standard to the various domains rather than the creation, expansion, or additional refinement of new or budding approaches to the matter.

Start using the SPDX specification here:https://spdx.github.io/spdx-spec/. Development of the next revision is underway, so If there’s a use case you can’t represent with the current specification, open an issue, this is the right window for input.   

To learn more about the many facets of the SPDX project see: https://spdx.dev/

Our communities take security seriously and have been instrumental in creating the tools and standards that every organization needs to comply with the recent US Executive Order

Overview

The US White House recently released its Executive Order (EO) on Improving the Nation’s Cybersecurity (along with a press call) to counter “persistent and increasingly sophisticated malicious cyber campaigns that threaten the public sector, the private sector, and ultimately the American people’s security and privacy.”

In this post, we’ll show what the Linux Foundation’s communities have already built that support this EO and note some other ways to assist in the future. But first, let’s put things in context.

The Linux Foundation’s Open Source Security Initiatives In Context

We deeply care about security, including supply chain (SC) security. The Linux Foundation is home to some of the most important and widely-used OSS, including the Linux kernel and Kubernetes. The LF’s previous Core Infrastructure Initiative (CII) and its current Open Source Security Foundation (OpenSSF) have been working to secure OSS, both in general and in widely-used components. The OpenSSF, in particular, is a broad industry coalition “collaborating to secure the open source ecosystem.”

The Software Package Data Exchange (SPDX) project has been working for the last ten years to enable software transparency and the exchange of software bill of materials (SBOM) data necessary for security analysis. SPDX, recognized and implemented as ISO/IEC standard 5962:2021, is supported by global companies with massive supply chains, and has a large open and closed source tooling support ecosystem. SPDX already meets the requirements of the executive order for SBOMs.

Finally, several LF foundations have focused on the security of various verticals. For example,  LF Public Health and LF Energy have worked on security in their respective sectors. Our cloud computing industry collaborating within CNCF has also produced a guide for supporting software supply chain best practices for cloud systems and applications.

Given that context, let’s look at some of the EO statements (in the order they are written) and how our communities have invested years in open collaboration to address these challenges.

Best Practices

The EO 4(b) and 4(c) says that

The “Secretary of Commerce [acting through NIST] shall solicit input from the Federal Government, private sector, academia, and other appropriate actors to identify existing or develop new standards, tools, and best practices for complying with the standards, procedures, or criteria [including] criteria that can be used to evaluate software security, include criteria to evaluate the security practices of the developers and suppliers themselves, and identify innovative tools or methods to demonstrate conformance with secure practices [and guidelines] for enhancing software supply chain security.” Later in EO 4(e)(ix) it discusses “attesting to conformity with secure software development practices.”

The OpenSSF’s CII Best Practices badge project specifically identifies best practices for OSS, focusing on security and including criteria to evaluate the security practices of developers and suppliers (it has over 3,800 participating projects). LF is also working with SLSA (currently in development) as potential additional guidance focused on addressing supply chain issues further.

Best practices are only useful if developers understand them, yet most software developers have never received education or training in developing secure software. The LF has developed and released its Secure Software Development Fundamentals set of courses available on edX to anyone at no cost. The OpenSSF Best Practices Working Group (WG) actively works to identify and promulgate best practices. We also provide a number of specific standards, tools, and best practices, as discussed below.

Encryption and Data Confidentiality

The EO 3(d) requires agencies to adopt “encryption for data at rest and in transit.” Encryption in transit is implemented on the web using the TLS (“https://”) protocol, and Let’s Encrypt is the world’s largest certificate authority for TLS certificates.

In addition, the LF Confidential Computing Consortium is dedicated to defining and accelerating the adoption of confidential computing. Confidential computing protects data in use (not just at rest and in transit) by performing computation in a hardware-based Trusted Execution Environment. These secure and isolated environments prevent unauthorized access or modification of applications and data while in use.

Supply Chain Integrity

The EO 4(e)(iii) states a requirement for

 “employing automated tools, or comparable processes, to maintain trusted source code supply chains, thereby ensuring the integrity of the code.” 

The LF has many projects that support SC integrity, in particular:

  • in-toto is a framework specifically designed to secure the integrity of software supply chains.
  • The Update Framework (TUF) helps developers maintain the security of software update systems, and is used in production by various tech companies and open source organizations.  
  • Uptane is a variant of TUF; it’s an open and secure software update system design which protects software delivered over-the-air to the computerized units of automobiles.
  • sigstore is a project to provide a public good / non-profit service to improve the open source software supply chain by easing the adoption of cryptographic software signing (of artifacts such as release files and container images) backed by transparency log technologies (which provide a tamper-resistant public log). 
  • OpenChain (ISO 5230) is the International Standard for open source license compliance. Application of OpenChain requires identification of OSS components. While OpenChain by itself focuses more on licenses, that identification is easily reused to analyze other aspects of those components once they’re identified (for example, to look for known vulnerabilities).

Software Bill of Materials (SBOMs) support supply chain integrity; our SBOM work is so extensive that we’ll discuss that separately.

Software Bill of Materials (SBOMs)

Many cyber risks come from using components with known vulnerabilities. Known vulnerabilities are especially concerning in key infrastructure industries, such as the national fuel pipelines,  telecommunications networks, utilities, and energy grids. The exploitation of those vulnerabilities could lead to interruption of supply lines and service, and in some cases, loss of life due to a cyberattack.

One-time reviews don’t help since these vulnerabilities are typically found after the component has been developed and incorporated. Instead, what is needed is visibility into the components of the software environments that run these key infrastructure systems, similar to how food ingredients are made visible.

A Software Bill of Materials (SBOM) is a nested inventory or a list of ingredients that make up the software components used in creating a device or system. This is especially critical as it relates to a national digital infrastructure used within government agencies and in key industries that present national security risks if penetrated. The use of SBOMs would improve understanding of the operational and cyber risks of those software components from their originating supply chain.

The EO has extensive text about requiring a software bill of materials (SBOM) and tasks that depend on SBOMs:

  • EO 4(e) requires providing a purchaser an SBOM “for each product directly or by publishing it on a public website” and “ensuring and attesting… the integrity and provenance of open source software used within any portion of a product.” 
  • It also requires tasks that typically require SBOMs, e.g., “employing automated tools, or comparable processes, that check for known and potential vulnerabilities and remediate them, which shall operate regularly….” and “maintaining accurate and up-to-date data, provenance (i.e., origin) of software code or components, and controls on internal and third-party software components, tools, and services present in software development processes, and performing audits and enforcement of these controls on a recurring basis.” 
  • EO 4(f) requires publishing “minimum elements for an SBOM,” and EO 10(j) formally defines an SBOM as a “formal record containing the details and supply chain relationships of various components used in building software…  The SBOM enumerates [assembled] components in a product… analogous to a list of ingredients on food packaging.”

The LF has been developing and refining SPDX for over ten years; SPDX is used worldwide and is approved as ISO/IEC International Standard 5962:2021.  SPDX is a file format that identifies the software components within a larger piece of computer software and metadata such as the licenses of those components. SPDX 2.2 already supports the current guidance from the National Telecommunications and Information Administration (NTIA) for minimum SBOM elements. Some ecosystems have ecosystem-specific conventions for SBOM information, but SPDX can provide information across all arbitrary ecosystems.

SPDX is real and in use today, with increased adoption expected in the future. For example:

  • An NTIA “plugfest” demonstrated ten different producers generating SPDX. SPDX supports acquiring data from different sources (e.g., source code analysis, executables from producers, and analysis from third parties). 
  • A corpus of some LF projects with SPDX source SBOMs is available. 
  • Various LF projects are working to generate binary SBOMs as part of their builds, including yocto and Zephyr
  • To assist with further SPDX adoption, the LF is paying to write SPDX plugins for major package managers.

Vulnerability Disclosure

No matter what, some vulnerabilities will be found later and need to be fixed. EO 4(e)(viii) requires “participating in a vulnerability disclosure program that includes a reporting and disclosure process.” That way, vulnerabilities that are found can be reported to the organizations that can fix them. 

The CII Best Practices badge passing criteria requires that OSS projects specifically identify how to report vulnerabilities to them. More broadly, the OpenSSF Vulnerability Disclosures Working Group is working to help “mature and advocate well-managed vulnerability reporting and communication” for OSS. Most widely-used Linux distributions have a robust security response team, but the Alpine Linux distribution (widely used in container-based systems) did not. The Linux Foundation and Google funded various improvements to Alpine Linux, including a security response team.

We hope that the US will update its Vulnerabilities Equities Process (VEP) to work more cooperatively with commercial organizations, including OSS projects, to share more vulnerability information. Every vulnerability that the US fails to disclose is a vulnerability that can be found and exploited by attackers. We would welcome such discussions.

Critical Software

It’s especially important to focus on critical software — but what is critical software? EO 4(g) requires the executive branch to define “critical software,” and 4(h) requires the executive branch to “identify and make available to agencies a list of categories of software and software products… meeting the definition of critical software.”

Linux Foundation and the Laboratory for Innovation Science at Harvard (LISH) developed the report Vulnerabilities in the Core,’ a Preliminary Report and Census II of Open Source Software, which analyzed the use of OSS to help identify critical software. The LF and LISH are in the process of updating that report. The CII identified many important projects and assisted them, including OpenSSL (after Heartbleed), OpenSSH,  GnuPG, Frama-C, and the OWASP Zed Attack Proxy (ZAP). The OpenSSF Securing Critical Projects Working Group has been working to better identify critical OSS projects and to focus resources on critical OSS projects that need help. There is already a first-cut list of such projects, along with efforts to fund such aid.

Internet of Things (IoT)

Unfortunately, internet-of-things (IoT) devices often have notoriously bad security. It’s often been said that “the S in IoT stands for security.” 

EO 4(s) initiates a pilot program to “educate the public on the security capabilities of Internet-of-Things (IoT) devices and software development practices [based on existing consumer product labeling programs], and shall consider ways to incentivize manufacturers and developers to participate in these programs.” EO 4(t) states that such “IoT cybersecurity criteria” shall “reflect increasingly comprehensive levels of testing and assessment.”

The Linux Foundation develops and is home to many of the key components of IoT systems. These include:

  • The Linux kernel, used by many IoT devices. 
  • The yocto project, which creates custom Linux-based systems for IoT and embedded systems. Yocto supports full reproducible builds. 
  • EdgeX Foundry, which is a flexible OSS framework that facilitates interoperability between devices and applications at the IoT edge, and has been downloaded millions of times. 
  • The Zephyr project, which provides a real-time operating system (RTOS) used by many for resource-constrained IoT devices and is able to generate SBOM’s automatically during build. Zephyr is one of the few open source projects that is a CVE Numbering Authority.
  • The seL4 microkernel, which is the most assured operating system kernel in the world; it’s notable for its comprehensive formal verification.

Security Labeling

EO 4(u) focuses on identifying:

“secure software development practices or criteria for a consumer software labeling program [that reflects] a baseline level of secure practices, and if practicable, shall reflect increasingly comprehensive levels of testing and assessment that a product may have undergone [and] identify, modify, or develop a recommended label or, if practicable, a tiered software security rating system.”

The OpenSSF’s CII Best Practices badge project (noted earlier) specifically identifies best practices for OSS development, and is already tiered (passing, silver, and gold). Over 3,800 projects currently participate.

There are also a number of projects that relate to measuring security and/or broader quality:

Conclusion

The Linux Foundation (LF) has long been working to help improve the security of open source software (OSS), which powers systems worldwide. We couldn’t do this without the many contributions of time, money, and other resources from numerous companies and individuals; we gratefully thank them all.  We are always delighted to work with anyone to improve the development and deployment of open source software, which is important to us all.

David A. Wheeler, Director of Open Source Supply Chain Security at the Linux Foundation

Linux Foundation Editorial Director Jason Perlow had a chance to speak with Masato Endo, OpenChain Project Automotive Chair and Leader of the OpenChain Project Japan Work Group Promotion Sub Group, about the Japan Ministry of Economy, Trade and Industry’s (METI) recent study on open source software management.

JP: Greetings, Endo-san! It is my pleasure to speak with you today. Can you tell me a bit about yourself and how you got involved with the Japan Ministry of Economy, Trade, and Industry?

遠藤さん、こんにちは!本日はお話しできることをうれしく思います。あなた自身について、また経済産業省とどのように関わっていますか?

ME: Hi, Jason-san! Thank you for such a precious opportunity. I’m a manager and scrum master in the planning and development department of new services at a Japanese automotive company. We were also working on building the OSS governance structure of the company, including obtaining OpenChain certification.

As an open source community member, I participated in the OpenChain project and was involved in establishing the OpenChain Japan Working Group and Automotive Working Group. Recently, as a leader of the Promotion SG of the Japan Working Group, I am focusing on promoting OSS license compliance in Japan.

In this project, I contribute to it as a bridge between the Ministry of Economic, Trade, and Industry and the members of OSS community projects such as OpenChain.

For example, I recently gave a presentation of OpenChain at the meeting and introduced the companies that cooperate with the case study.

Jasonさん、こんにちは。このような貴重な機会をありがとうございます。

私は、自動車メーカーの新サービスの企画・開発部署でマネージャーやスクラムマスターを務めています。また、OpenChain認証取得等の会社のオープンソースガバナンス体制構築についても取り組んでいました。

一方、コミュニティメンバーとしてもOpenChainプロジェクトに参加し、OpenChain Japan WGやAutomotive WGの設立に関わりました。最近では、Japan WGのPromotion SGのリーダーとして日本におけるOSSライセンスコンプライアンスの啓発活動に注力しています。

今回のプロジェクトにおいては、経済産業省のタスクフォースとOpenChainとの懸け橋として、ミーティングにてOpenChainの活動を紹介させて頂いたり、ケーススタディへの協力企業を紹介させて頂いたりすることで、コントリビューションさせて頂きました。

JP: What does the Ministry of Economy, Trade, and Industry (METI) do?

経済産業省(METI)はどのような役割の政府機関ですか?

ME: METI has jurisdiction over the administration of the Japanese economy and industry. This case study was conducted by a task force that examines software management methods for ensuring cyber-physical security of the Commerce and Information Policy Bureau’s Cyber Security Division.

経済産業省は経済や産業に関する行政を所管しています。今回のケーススタディは商務情報政策局サイバーセキュリティ課によるサイバー・フィジカル・セキュリティ確保に向けたソフトウェア管理手法等検討タスクフォースにより実施されたものです。

JP: Why did METI commission a study on the management of open source program offices and open source software management at Japanese companies?

なぜ経済産業省は、日本企業のオープンソースプログラムオフィスの管理とオープンソースソフトウェアの管理に関する調査を実施したのですか?

ME: METI itself conducted this survey. The Task Force has been considering appropriate software management methods, vulnerability countermeasures, license countermeasures, and so on.

Meanwhile, as the importance of OSS utilization has increased in recent years, it concluded that sharing the knowledge of each company regarding OSS management methods helps solve each company’s problems.

今回の調査は、METIが主体的に行ったものです。タスクフォースは適切なソフトウェアの管理手法、脆弱性対応やライセンス対応などについて検討してきました。

そんな中、最近はOSS利活用の重要性がより高まっているため、OSSの管理手法に関する各企業の知見の共有が各社の課題解決に有効だという結論に至りました。

JP: How do Japanese corporations differ from western counterparts in open source culture? 

日本の企業は、オープンソース文化において欧米の企業とどのように違いますか?

ME: Like Western companies, Japanese companies also use OSS in various technical fields, and OSS has become indispensable. In addition, more than 80 companies have participated in the Japan Working Group of the OpenChain project. As a result, the momentum to promote the utilization of OSS is increasing in Japan.

On the other hand, some survey results show that Japanese companies’ contribution process and support system are delayed compared to Western companies. So, it is necessary to promote community activities in Japan.

欧米の企業と同様、日本の企業でもOSSは様々な技術領域で使われており、欠かせないものになっています。また、OpenChainプロジェクトのJPWGに80社以上の企業が参加するなど、企業としてOSSの利活用を推進する機運も高まってきています。

一方で、欧米企業と比較するとコントリビューションのプロセスやサポート体制の整備が遅れているという調査結果も出ているため、コミュニティ活動を促進する仕組みをより強化していく必要があると考えられます。

JP: What are the challenges that the open source community and METI have identified due to the study that Japanese companies face when adopting open source software within their organizations? 

日本企業が組織内でオープンソースソフトウェアを採用する際に直面する調査の結果、オープンソースコミュニティと経済産業省が特定した課題は何ですか?

ME: The challenges are:

課題は次のとおりです。

Challenge 1: License compliance

When developing software using OSS, it is necessary to comply with the license declared by each OSS. If companies don’t conduct in-house licensing education and management appropriately, OSS license violations will occur.

Challenge 2: Long term support

Since the development term of OSS depends on the community’s activities, the support term may be shorter than the product life cycle in some cases.

Challenge 3:OSS supply chain management

Recently, the software supply chain scale has expanded, and there are frequent cases where OSS is included in deliveries from suppliers. OSS information sharing in the supply chain has become important to implement appropriate vulnerability countermeasures and license countermeasures.

Challenge 1: ライセンスコンプライアンス

OSSを利用してソフトウエアを開発する場合は、各OSSが宣言しているライセンスを遵守する必要があります。社内におけるライセンスに関する教育や管理体制が不十分な場合、OSSライセンスに違反してしまう可能性があります。 

Challenge 2: ロングタームサポート

OSSの開発期間はコミュニティの活性度に依存するため、場合によっては製品のライフサイクルよりもサポート期間が短くなってしまう可能性があります。

Challenge 3: サプライチェーンにおけるOSSの使用

最近はソフトウエアサプライチェーンの規模が拡大しており、サプライヤからの納品物にOSSが含まれるケースも頻繁に起こっています。適切な脆弱性対応、ライセンス対応などを実施するため、サプライチェーンの中でのOSSの情報共有が重要になってきています。

JP:  Are there initiatives that are working to address these challenges?

これらの課題に取り組むための日本企業の取組の特徴などはありますか?

ME: In this case study, many companies mentioned license compliance. It was found that each company has established a company-wide system and rules to comply with the license and provides education to engineers. The best way to do this depends on the industry and size of the company, but I believe the information from this case study is very useful for each company of all over the world.

In addition, it was confirmed that Software Bill of Materials (SBOM) is becoming more critical for companies in the viewpoint of both vulnerability response and license compliance. Regardless of whether companies are using OSS internally or exchanging software with an external partner, it’s important to clarify which OSS they are using. I recognize that this issue is a hot topic as “Software transparency” in Western companies as well.

In this case study, several companies also mentioned OSS supply chain management. In addition to clarifying the rules between companies, it is characterized by working to raise the level of the entire supply chain through community activities such as OpenChain.

今回のケーススタディでは、多くの企業がライセンスコンプライアンスに言及していました。各企業はライセンスを遵守するために、全社的な体制やルールを整え、エンジニアに対してライセンス教育を実施していることがわかりました。ベストな方法は産業や企業の規模によっても異なりますが、各社の情報はこれからライセンスコンプライアンスに取り組もうとしている企業やプロセスの改善を進めている企業にとって非常に有益なものであると私は考えます。

また、脆弱性への対応、ライセンスコンプライアンスの両面から、企業にとってSBOMの重要性が高まっていることが確認できました。社内でOSSを利用する場合であっても、社外のパートナーとソフトウエアをやりとりする場合であっても、どのOSSを利用しているかを明確にすることが最重要だからです。この課題はソフトウエアの透過性といって欧米でも話題になっているものであると私は認識しています。

このケーススタディの中で複数の企業がOSSのサプライチェーンマネジメントについても言及していました。企業間でのルールを明確化する他、OpenChainなどのコミュニティ活動によって、サプライチェーン全体のレベルアップに取り組むことが特徴になっています。

JP: What are the benefits of Japanese companies adopting standards such as OpenChain and SPDX?

OpenChainやSPDXなどの標準を採用している日本企業のメリットは何ですか?

ME: Companies need to do a wide range of things to ensure proper OSS license compliance, so some guidance is needed. The OpenChain Specification, which has become an ISO as a guideline for that, is particularly useful. In fact, several companies that responded to this survey have built an OSS license compliance process based on the OpenChain Specification.

Also, from the perspective of supply chain management, it is thought that if each supply chain company obtains OpenChain certification, software transparency will increase, and appropriate OSS utilization will be promoted.

In addition, by participating in OpenChain’s Japan Working Group, companies can share the best practices of each company and work together to solve problems.

Since SPDX is a leading international standard for SBOM, it is very useful to use it when exchanging information about OSS in the supply chain from the viewpoint of compatibility.

Japanese companies use the SPDX standard and actively contribute to the formulation of SPDX specifications like SPDX Lite.

企業がOSSライセンスコンプライアンスを適切に行うために行うべきことは多岐に渡るために何かしらの指針が必要です。そのための指針としてISOになったOpenChain Specificationは非常に有用なものです。実際、今回の調査に回答した複数の企業がOpenChain Specificationに基づいてOSSライセンスコンプライアンスプロセスを構築し、認証を取得しています。

また、サプライチェーンマネジメントの観点からも、サプライチェーン各社がOpenChain認証を取得することで、ソフトウエアの透過性が高まり、適切なOSSの利活用を促進されると考えられます。

更にOpenChainのJPWGに参加することで、各社のベストプラクティスを共有したり、協力して課題解決をすることもできます。

SPDXは重要性の高まっているSBOMの有力な国際標準であるため、サプライチェーン内でOSSに関する情報を交換する場合に、SPDXを利用することは互換性等の観点から非常に有益です。

日本企業はSPDXの標準を利用するだけではなく、SPDX LiteのようにSPDXの仕様策定にも積極的にコントリビューションしています。

JP: Thank you, Endo-san! It has been great speaking with you today.

遠藤さん、ありがとうございました!本日は素晴らしい議論になりました。