Industry leaders from technology, financial services, telecom, and cybersecurity sectors respond to Biden’s Executive Order, commit to a more secure future for software; open source luminary Brian Behlendorf becomes general manager

LOS ANGELES, Calif – KubeCon – October 13, 2021 –  The Linux Foundation, the nonprofit organization enabling mass innovation through open source, today announced it has raised $10 million in new investments to expand and support the Open Source Security Foundation (OpenSSF), a cross-industry collaboration that brings together multiple open source software initiatives under one umbrella to identify and fix cybersecurity vulnerabilities in open source software and develop improved tooling, training, research, best practices, and vulnerability disclosure practices. Open source luminary Brian Behlendorf will serve the OpenSSF community as General Manager. 

Financial commitments from Premier members include Amazon, Cisco, Dell Technologies, Ericsson, Facebook, Fidelity, GitHub, Google, IBM, Intel, JPMorgan Chase, Microsoft, Morgan Stanley, Oracle, Red Hat, Snyk, and VMware. Additional commitments come from General members Aiven, Anchore, Apiiro, AuriStor, Codethink, Cybertrust Japan, Deepfence, Devgistics, DTCC, GitLab, Goldman Sachs, JFrog, Nutanix, StackHawk, Tencent, TideLift, and Wind River.

“This pan-industry commitment is answering the call from the White House to raise the baseline for our collective cybersecurity wellbeing, as well as ‘paying it forward’ to open source communities to help them create secure software from which we all benefit,” said Jim Zemlin, executive director at the Linux Foundation. “We’re pleased to have Brian Behlendorf’s leadership and extensive expertise on building and sustaining large communities and technical projects applied to this work. With the tremendous growth and pervasiveness of open source software, building cybersecurity practices and programs that scale is our biggest task at hand.”

According to industry reports (“2021 State of the Software Supply Chain,” by Sonatype), software supply chain attacks have increased 650 percent and are having a severe impact on business operations. In the wake of increasing security breaches, ransomware attacks, and other cybercrimes tied to open source software, government leaders worldwide are calling for private and public collaboration. Because open source software makes up at least 70 percent of all software (“2020 Open Source Security and Risk Analysis Report” by Synopsys), the OpenSSF offers the natural, neutral, and pan-industry forum to accelerate the security of the software supply chain. 

“There has never been a more exciting time to work in the open source community, and software supply chain security has never needed more of our attention,” said Brian Behlendorf, general manager, Open Source Security Foundation. “There is no single silver bullet for securing software supply chains.  Research, training, best practices, tooling and collaboration require the collective power of thousands of critical minds across our community. Funding for OpenSSF gives us the forum and resources to do this work.”

The OpenSSF is home to a variety of open source software, open standards, and other open content work for improving security. Examples include:

For more information about OpenSSF, please visit: https://openssf.org/

Premier Member Quotes

AWS

“Open source software plays an increasingly crucial role across the whole landscape of information security. Convening industry leaders to invest in developing policies, practices, tooling, and education around open source security benefits us all. AWS was a founding member of the Core Infrastructure Initiative in 2014, and we will now build on the relationships and investments that continue the mission by joining OpenSSF as a Premier Member. With our partners in this initiative, and as active participants in many open source communities, we will help raise the bar in the security of open source software,” said Mark Ryland, Director of the Office of the CISO at AWS.

Cisco

“OpenSSF will enable the community, across industries, to build tools and practices to secure the software supply chain for open source and beyond. This is crucial to the future of API and application security, which are fast becoming a primary attack vector for all business going forward,” says Vijoy Pandey, VP of Emerging Technologies & Incubation at Cisco. “At Cisco, we believe the application experience is the new brand, which demands better app velocity, trust, security, and availability. This belief drives our deep investment in application security and full-stack observability, which is why joining forces with this prestigious foundation and group as a trusted advisor and partner was a no-brainer for us.”

Dell Technologies 

“The Linux Foundation’s focus on security is fundamental to addressing the increasing risks associated with software,” said John Roese, Dell Technologies’ Global Chief Technology Officer. “The Open Source Security Foundation’s work will help us collectively make sure critical software programs and the end to end software delivery pipeline is secure and trustworthy.”

Ericsson

“As a leader in mobile communication, pioneering and driving 5G globally, security is at the core of the network infrastructure we build and deliver to our customers. In an industry increasingly built around open source and open standardization we are fully committed to address cybersecurity vulnerabilities in a collaborative effort. We are proud to join the Open Source Security Foundation as a founding member and we look forward to continue to work with the community and wider industry for a secure software supply chain, including the open source components,” says Erik Ekudden, Senior Vice President and Chief Technology Officer, Ericsson.

Fidelity

“Open Source Software plays a critical role in Fidelity’s technology strategy. We are proud to be part of the Open Source Security Foundation and to work with others to ensure that Open Source solutions and their supply chains are safe, secure, and reliable, enabling Fidelity to better serve our customers and clients,” said John Andrukonis, SVP, Fidelity Application Architecture.

GitHub

“The world runs on software, and most of that software includes and relies on open source,” said Mike Hanley, Chief Security Officer at GitHub. “As the home to more than 65 million developers around the world, we’re excited to continue partnering across the open source community and with other Open Source Security Foundation members to power a more secure, trustworthy future that will benefit everyone.”

Google

“We are doubling down on our OpenSSF commitment in the wake of rising open source software supply chain attacks and President Biden’s Executive Order,” said Eric Brewer, vice president of infrastructure and fellow at Google. “This decision is part of our White House pledge to spend $100 million to fund open source security foundations and follows a variety of investments we’ve made to support developers and security engineers across the public and private sectors. The OpenSSF is the best place for cross-industry leadership for these very challenging topics, and we look forward to working with the US and other governments to improve security worldwide.” 

IBM 

“IBM is deeply focused on developing and building highly secure hybrid cloud, AI and quantum-safe technologies that are designed to protect our clients’ most sensitive workloads both today and into the future,” said Jamie Thomas, General Manager, Strategy & Development and IBM Enterprise Security Executive. “As a long-time open source leader, IBM looks forward to working with the OSSF, our industry partners, and open source communities towards addressing the ever-increasing challenge of hardware and software open source supply chain security.”

Intel

“As a long-standing member of the open source software community, Intel contributes daily in the upstream projects we collaborate with,” said Greg Lavender, senior vice president, CTO, and general manager of Software and Advanced Technology at Intel Corporation. “Along with the Linux Foundation, we believe the Open Security Foundation (OpenSSF) is a unique opportunity to engage in projects and efforts focused on improving the quality and security for today and our future. Intel remains committed to providing contributions that benefit open source software supply chains and improving the security posture of critical projects on which our ecosystem depends.”

JPMorgan Chase

“JPMorgan Chase is deeply committed to working with the open source community to solve our most pressing security challenges. As a founding member of the Open Source Security Foundation, we have worked together to improve the security of open source and the integrity of all software. We commend the US Government’s recent initiative to raise awareness on this pressing topic and call to action the technology community to solve one of the most complex security challenges of our time.  We welcome the new members to OpenSSF and look forward to continuing the journey of innovation and bringing meaningful change to how we build, secure, and validate software,” said Pat Opet, Chief Information Security Officer, JPMorgan Chase & Co.

Microsoft

“As open source is now core to nearly every company’s technology strategy, securing open source software is an essential part of securing the supply chain for every company, including our own. All of us at Microsoft are excited to participate with others in contributing new investments to the Open Source Security Foundation and we look forward to building more secure software through community-driven efforts to create solutions that will help us all,” said Mark Russinovich, Azure CTO and Technical Fellow, Microsoft.

Morgan Stanley

“Whether we are leveraging open source in our own code, contribute to OSS projects, or consume OSS via technology we procure and utilize, the safety and security of OSS and the creation of a trustworthy supply chain is critical to all businesses. To that end, we are delighted to join the Linux Foundation’s Open Source Security Foundation project to collaborate with our cross-industry partners to improve the security, safety and trust in the OSS ecosystem,” said Neil Allen, Global Head of Cyber Security Engineering, Morgan Stanley.

Oracle

“As a contributing member of the open source software community and an inaugural Linux Foundation member, Oracle has a large number of developers that contribute to third-party open source projects daily,” said Wim Coekaerts, senior vice president of software development, Oracle. “Oracle looks forward to participating in the Open Source Security Foundation and working with other members to continue to strengthen the software supply chain, helping customers work more securely.”   

Red Hat

“Open source is pervasive in software solutions of all kinds, and cybersecurity attack rates are on the rise. Our customers look to Red Hat to provide trust and enhanced security in our open source based portfolio. Open source and community collaboration is the best way to solve big, industry-wide challenges, such as open source supply chain security. And that’s why we’re excited to join together with the Linux Foundation and other industry leaders so we can continue to improve the technologies and practices to build a more secure future from open source software,” said Chris Wright, senior vice president and CTO, Red Hat.

Snyk

“Open source is built by millions of empowered developers, who also need to secure this critical foundation of the digital world,” said Guy Podjarny, Founder & President, Snyk. “The vital work of the Linux Foundation and the OpenSSF ensures we collectively live up to this responsibility. The Snyk community is fully committed to this important, collaborative effort and we look forward to working closely with the other OpenSSF members to better secure OSS so it can continue to safely fuel innovation.”

VMware

“Every company that uses software should be concerned about their software supply chain,” said Kit Colbert, chief technology officer, VMware. “For two-plus years, VMware has engaged in contributions to open source projects in the broader software supply chain security space and invested in initiatives to help customers further strengthen their security policies and processes. As a member of the Open Source Security Foundation, we’re committed to collaborating across the industry to drive increased level of software supply chain security.”

General Member Quotes 

Apiiro

“Software supply chain risks are becoming pervasive, with the potential to slow application delivery and stunt innovation,” commented John Leon, VP of Business Development at Apiiro. “Managing application risk has become increasingly complex and requires visibility across the SDLC – including the supply chain. Apiiro is excited to partner with the open source community and support the Linux Foundation and OpenSSF as they power the collaboration that is vital to securing software.”

AuriStor

“AuriStor’s founders have contributed to the standardization of security protocols and open source development of security first software for more than 35 years. We view the OpenSSF, its working groups and projects, and those that participate in them as crucial to improving the security of every industry, service, and home.  The OpenSSF has the potential to make a significant difference in everyone’s future. We encourage all members of the software development community to contribute,” said AuriStor Founder and CEO Jeffrey Altman.

Devgistics

“We seized the opportunity to join this foundation because OpenSSF offers a real industry-neutral forum to accelerate the hardening and security of the software supply chain. Devgistics (formerly InfoSiftr) provides critical enhancements to the world’s most popular open-source repository. Devgistics has been involved in many free and open-source initiatives for years, including being a Moby (Docker Engine) maintainer, providing support to the Docker/container ecosystem, and serving in the Open Container Initiative. Devgistics continues to contribute cutting-edge solutions for security-conscious clients like the US Air Force,” said Devgistics Founder and President Justin Steele. 

DTCC

“DTCC is committed to developing highly resilient and secure code to safeguard the financial marketplace. DTCC is proud to be part of the OpenSSF community and looks forward to partnering with our fellow members on safe, secure and reliable computing,” said Ajoy Kumar, Head of Tech/Cyber Risk at DTCC.

GitLab

“As organizations modernize software development and shift security left, GitLab believes that open source will play a key role in fostering this modernization and delivering secure software with speed to the market,” said Eric Johnson, CTO at GitLab. “Supporting the Open Source Security Foundation aligns with GitLab’s mission of enabling everyone to contribute, and we look forward to supporting, collaborating, and sharing our expertise in implementing security in GitLab’s DevOps Platform to the OpenSSF community.”

Goldman Sachs

“Continuing to secure the software supply chain, in particular the many critical open source projects foundational to any modern organization’s IT architecture, is a top strategic imperative for Goldman Sachs, our peers, partners, and clients in financial services, the technology ecosystem, and the wider economy,” said Atte Lahtiranta, chief technology officer at Goldman Sachs. “This work cannot be done in individual organizational silos. We instead need to work collaboratively, across both the private and public sector, together with open source maintainers and contributors, to answer the call to action that is the recent cybersecurity executive order. The OpenSSF will provide an essential forum and associated infrastructure to allow us to share leading practices, develop improved tooling, and work together to better protect our digital infrastructure.”

JFrog

“Open-source software is the backbone of hundreds of thousands of today’s applications, making it critical that we do our best to flag new vulnerabilities and insecure components fast—before they compromise businesses or critical infrastructure,” said Asaf Karas, JFrog Security CTO. “We’re happy to expand our membership with the Linux Foundation and support this cross-industry collaboration to identify and fix open source security vulnerabilities, strengthen tools, and promote best practices to ensure developers can easily shift left and bake-in security from the start of application planning and design — all the way to software deployment, distribution, and runtime.”

Nutanix

“The world runs on open source software and Nutanix is eager to help ensure its security. This can only be achieved through broad industry collaboration. We believe in the founding vision of the Open Source Security Foundation. We hope to help empower open source developers and better protect all of our customers with the partnership it enables. As members of the Open Source Software Foundation, we join other industry leaders in strengthening the software supply chain security we all rely upon,” said Rajiv Mirani, Chief Technology Officer at Nutanix.

StackHawk

“Software development is moving faster than ever before. The industry needs tooling and processes to ensure that security can keep up with today’s pace of development. StackHawk is excited about the work that the Open Source Security Foundation is doing to improve security and we are proud to continue as a member,” said Joni Klippert, StackHawk Founder & CEO.

Tencent

“IT development to date, an increasing number of critical businesses and core competencies have been built on open source, and this trend will continue. As an important part of the software supply chain, open source security plays an important role in the entire software supply chain. Tencent Cloud has always been keen to contribute code and technology to open source projects, and also maintains a continuous huge investment in security. It is very gratifying to see that OpenSSF can be established, and we look forward to working closely with industry  partners to improve the security level of open source software and strengthen the software supply chain security,” said KK Dong, Chief Security Officer at Tencent Cloud.

Wind River

“As the dependency on open-source software becomes increasingly pervasive, the Open Source Security Foundation’s community-driven approach to developing and sharing security metrics, tools and best practices becomes an imperative. Our customers are actively interested in the health of the open source from which their solutions are constructed, and assuring secure development across open the supply chain is vital,” said Paul Miller, CTO, Wind River. “We are looking forward to collaborating more closely with the OpenSSF community. By working together, Wind River can provide customers with a level of open source security assurance that would otherwise be unobtainable.”

About the Linux Foundation

Founded in 2000, the Linux Foundation is supported by more than 1,800 members and is the world’s leading home for collaboration on open source software, open standards, open data, and open hardware. Linux Foundation’s projects are critical to the world’s infrastructure, including Linux, Kubernetes, Node.js, Hyperledger, RISC-V, and more.  The Linux Foundation’s methodology focuses on leveraging best practices and addressing the needs of contributors, users, and solution providers to create sustainable models for open collaboration. For more information, please visit us at https://www.linuxfoundation.org/

###

The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see its trademark usage page: www.linuxfoundation.org/trademark-usage. Linux is a registered trademark of Linus Torvalds.

Media Contacts

Jennifer Cloer

503-867-2304

jennifer@storychangesculture.com

Imagine you have created an open source project that has become incredibly popular.  Thousands, if not millions, of developers worldwide, rely on the lines of code that you wrote. You have become an accidental hero of that community — people love your code, contribute to improving it, requesting new features, and encouraging others to use it. Life is amazing, but with great power and influence comes great responsibility.

When code is buggy, people complain. When performance issues crop up in large scale implementations, it needs to be addressed. When security vulnerabilities are discovered — because no code or its dependencies are always perfect — they need to be remediated quickly to keep your community safe.  

To help open source projects better address some of the responsibilities tied to security, many communities hosted by the Linux Foundation have invested countless hours, resources, and code into some important efforts. We’ve worked to improve the security of the Linux kernel, hosted Let’s Encrypt and sigstore, helped steward the ISO standardization for SPDX, and brought together a community building metrics for OSS health and risk through the CHAOSS project — among many others.

Today, we are taking steps with many leading organizations around the world to enhance the security of software supply chains. The Linux Foundation has raised $10 million in new investments to expand and support the Open Source Security Foundation (OpenSSF) and its initiatives. This cross-industry collaboration brings together an ecosystem to collectively identify and fix cybersecurity vulnerabilities in open source software and develop improved tooling, training, research, best practices, and vulnerability disclosure practices. We are also proud to announce that open source luminary, Brian Behlendorf, will serve the OpenSSF community as General Manager. 

Financial commitments for OpenSSF include Premier members such as AWS, Cisco, Dell Technologies, Ericsson, Facebook, Fidelity, GitHub, Google, IBM, Intel, JPMorgan Chase, Microsoft, Morgan Stanley, Oracle, Red Hat, Snyk, and VMware. Additional commitments come from General members, including Aiven, Anchore, Apiiro, AuriStor, Codethink, Cybertrust, Deepfence, Devgistics, DTCC, GitLab, Goldman Sachs, JFrog, Nutanix, StackHawk, Tencent, TideLift, and Wind River.

To learn more about how to join the OpenSSF or to get involved in one of its six working groups, listen in to this brief introduction from Brian Behlendorf recorded this week at KubeCon:

In 2021, the Linux Foundation and its community will continue to support education and share resources critical to improving open source cybersecurity.  For example, this week, we also hosted SupplyChainSecurityCon, where the SLSA and sigstore projects were heavily featured.

If you are an open source software developer, user, or other community participant who just wants to help further protect the software that accelerates innovation around the world, please consider joining one of our six OpenSSF working groups, or suggest a new working group that addresses gaps in software supply chain security needs.

You can follow the latest news from OpenSSF here on our blog, Twitter (@TheOpenSSF), and LinkedIn.

Backed by many of the world’s largest companies for more than a decade, SPDX formally becomes an internationally recognized ISO/IEC JTC 1 standard during a transformational time for software and supply chain security

SAN FRANCISCO, September 9, 2021 – The Linux Foundation, Joint Development Foundation, and the SPDX community, today announced the Software Package Data Exchange® (SPDX®) specification has been published as ISO/IEC 5962:2021 and recognized as the international open standard for security, license compliance, and other software supply chain artifacts. ISO/IEC JTC 1 is an independent, non-governmental standards body. 

Intel, Microsoft, Siemens, Sony, Synopsys, VMware, and WindRiver are just a small sample of the companies already using SPDX to communicate Software Bill of Materials (SBOM) information in policies or tools to ensure compliant, secure development across global software supply chains. 

“SPDX plays an important role in building more trust and transparency in how software is created, distributed, and consumed throughout supply chains. The transition from a de-facto industry standard to a formal ISO/IEC JTC 1 standard positions SPDX for dramatically increased adoption in the global arena,” said Jim Zemlin, executive director, the Linux Foundation. “SPDX is now perfectly positioned to support international requirements for software security and integrity across the supply chain.” 

Between eighty and ninety percent (80%-90%) of a modern application is assembled from open source software components. An SBOM accounts for the software components contained in an application — open source, proprietary, or third-party — and details their provenance, license, and security attributes. SBOMs are used as a part of a foundational practice to track and trace components across software supply chains. SBOMs also help to proactively identify software issues and risks and establish a starting point for their remediation.

SPDX results from ten years of collaboration from representatives across industries, including the leading Software Composition Analysis (SCA) vendors – making it the most robust, mature, and adopted SBOM standard. 

“As new use cases have emerged in the software supply chain over the last decade, the SPDX community has demonstrated its ability to evolve and extend the standard to meet the latest requirements. This really represents the power of collaboration on work that benefits all industries,” said Kate Stewart, SPDX tech team co-lead. “SPDX will continue to evolve with open community input, and we invite everyone, including those with new use cases, to participate in SPDX’s evolution and securing the software supply chain.”  

For more information on how to participate in and benefit from SPDX, please visit: https://spdx.dev.

To learn more about how companies and open source projects are using SPDX, recordings from the “Building Cybersecurity into the Software Supply Chain” Town Hall that was held on August 18th are available and can be viewed at: https://events.linuxfoundation.org/supply-chain-town-hall/ 

ISO/IEC JTC 1 is an independent, non-governmental international organization based in Geneva, Switzerland. Its membership represents more than 165 national standards bodies with experts who share knowledge and develop voluntary, consensus-based, market-relevant international standards that support innovation and provide solutions to global challenges.

Supporting Comments

Intel

“Software security and trust are critical to our Industry’s success. Intel has been an early participant in the development of the SPDX specification and utilizes SPDX both internally and externally for a number of software use-cases,” said Melissa Evers, Vice President – Software and Advanced Technology Group, General Manager of Strategy to Execution, Intel.

Microsoft

“Microsoft has adopted SPDX as our SBOM format of choice for software we produce,” says Adrian Diglio, Principal Program Manager of Software Supply Chain Security at Microsoft. “SPDX SBOMs make it easy to produce U.S. Presidential Executive Order compliant SBOMs, and the direction that SPDX is taking with the design of their next gen schema will help further improve the security of the software supply chain.”

Siemens

“With ISO/IEC 5962:2021 we have the first official standard for metadata of software packages. It’s natural that SPDX is that standard, as it’s been the de facto standard for a decade. This will make license compliance in the supply chain much easier, especially because several open source tools like FOSSology, ORT, scancode, and sw360 already support SPDX,” said Oliver Fendt, senior manager, open source at Siemens. 

Sony

”The Sony team uses various approaches to managing open source compliance and governance,” says Hisashi Tamai, Senior Vice President, Deputy President of R&D Center, Representative of the Software Strategy Committee, Sony Group Corporation. “An example is the use of an OSS management template sheet that is based on SPDX Lite, a compact subset of the SPDX standard. It is important for teams to be able to quickly review the type, version, and requirements of software, and using a clear standard is a key part of this process.”

Synopsys

“The Black Duck team from Synopsys has been involved with SPDX since its inception, and I personally had the pleasure of coordinating the activities of the project’s leadership for more than a decade. 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,” said Phil Odence, General Manager, Black Duck Audits.

VMware

“SPDX is the essential common thread among tools under the Automating Compliance Tooling (ACT) Umbrella. SPDX enables tools written in different languages and for different software targets to achieve coherence and interoperability around SBOM production and consumption. SPDX is not just for compliance, either; the well-defined and ever-evolving spec is also able to represent security and supply chain implications. This is incredibly important for the growing community of SBOM tools as they aim to thoroughly represent the intricacies of modern software,” said Rose Judge, ACT TAC Chair and open source engineer at VMware.

Wind River

“The SPDX format greatly facilitates the sharing of software component data across the supply chain. Wind River has been providing a Software Bill of Materials (SBOM) to its customers using the SPDX format for the past 8 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,” said Mark Gisi, Wind River Open Source Program Office Director and OpenChain Specification Chair.

About SPDX

SPDX is an open standard for communicating software bill of material information, including provenance, license, security, and other related information. SPDX reduces redundant work by providing common formats for organizations and communities to share important data, thereby streamlining and improving compliance, security, and dependability. For more information, please visit us at spdx.org.

###

The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our trademark usage page:  https://www.linuxfoundation.org/trademark-usage. Linux is a registered trademark of Linus Torvalds.

Media Contact

Jennifer Cloer

for the Linux Foundation

503-867-2304

jennifer@storychangesculture.com

Open source software (OSS) is vitally important to the functioning of society today; it underpins much of the global economy. However, some OSS is highly secure, while others are not as secure as they need to be.

By its very nature, open source enables worldwide peer review, yet while its transparency has the potential for enhanced software security, that potential isn’t always realized. Many people are working to improve things where it’s needed. Most of that work is done by volunteers or organizations outside the Linux Foundation (LF) who directly pay people to do the work (typically as employees). Often those people work together within a foundation that’s part of the Linux Foundation. Sometimes, however, the LF or an LF foundation/project (e.g., a fund) directly funds people to do security work.

At the Linux Foundation (LF), I have the privilege of overseeing focused work to improve OSS security by the very people paid to do it. This work is funded through various grants and foundations, with credits to organizations like Google, Microsoft, the Open Source Security Foundation (OpenSSF), the LF Public Health foundation, and the LF itself.

The LF and its foundations do much more that I don’t oversee, so I’ve only listed the ones I am personally involved with in the interest of brevity. I hope it will give you a sense of some of the things we’re doing that you might not know about otherwise.

The typical LF oversight process for this work is described in “Post-Approval LF Security Funding.” Generally, performers must provide a periodic summary of their work so they can get paid. Most of those summaries are public, and in those cases, it’s easy for others to learn about their interesting work!

Here’s a sample of the work I oversee:

  • Ariadne Conill is improving Alpine Linux security, including significant improvements to its vulnerability processing and making it reproducible. For example, as noted in the July 2021 report, this resulted in Alpine 3.14 being released with the lowest open vulnerability count in the final release in a long time. Alpine Linux’s security is important because many containers use it. For more information, see “Bits relating to Alpine security initiatives in June” and “Bits relating to Alpine security initiatives in July.”
  • kpcyrd is doing a lot of reproducible build work on Linux distributions, especially Alpine Linux (including on the Raspberry Pi) and Arch Linux. Reproducible builds are a strong countermeasure against build system attacks (such as the devastating attack on SolarWinds Orion). More than half of the currently unreproducible packages in Arch Linux have now been reviewed and classified.
  • David Huseby has been working on modifying git to have a much more flexible cryptographic signing infrastructure. This will make it easier to verify the integrity of software source code; git is widely used to manage source code.
  • Theo de Raadt has also been receiving funding to secure the critical “plumbing” behind modern communications infrastructure:
    • This funding is being used towards improving OpenSSH (a widely-used tool whose security is critical). These include various smaller improvements, an updated configuration file parser, and a transition to using the SFTP protocol rather than the older RCP protocol inside the scp(1) program.
    • It is also being used to improve rpki-client, implementing Resource Public Key Infrastructure (RPKI). RPKI is an important protocol for protecting the Internet’s routing protocols from attack. These improvements implement the RPKI Repository Delta Protocol (RRDP) data transfer protocol and fix various edge cases (e.g., through additional validation checks). The https://irrexplorer.nlnog.net/ service is even using rpki-client behind the scenes.
  • Nathan Chancellor is improving the Linux kernel’s ability to be compiled with clang (instead of just gcc). This includes eliminating warning messages from clang (which helps to reduce kernel bugs even when gcc is used) and fixing/extending the clang compiler (which helps clang users when compiling code other than the Linux kernel). Unsurprisingly this involves changing both the Linux kernel and the clang/LLVM compiler infrastructure, and sometimes other software as well.
    • In the long run, eliminating warnings that by themselves aren’t bugs is important; developers will ignore warnings if there are many irrelevant ones, but if there are only a few warnings, they’ll examine them (making warnings more useful).
    • Of notable mention for security implications is clang support for Control-Flow Integrity (CFI); this can counter many attacks on arm64, and work will eventually enable x86_64 support.
  • I oversee some security audits conducted via the Open Source Technology Improvement Fund (OSTIF) when funded through the LF. We (the LF) often work with OSTIF to conduct security audits. We work with OSTIF to define the audit scope, and then OSTIF runs a bidding process where qualified security audit firms propose to do the work. We then work with OSTIF to select the winner (who isn’t always the cheapest — we want good work, not a box-check). OSTIF & I then oversee the process and review the final result. 
    • Note that we don’t just want to do audits, we also want to fix or mitigate any critical issues the audits identify, but the audits help us find the key problems. Subject matter experts perform the audit reports, and handling bidding is OSTIF’s primary focus, so my main contribution is usually to help ensure these reports are clear to non-experts while still being accurate. Experts sometimes forget to explain their context and jargon, and it’s sometimes hard to fix that (you must know the terminology & technology to explain it).
    • This work included two security audits related to the Linux kernel, one for signing and key management policies and the other for vulnerability reporting and remediation. 
    • I’ve also overseen audits of the exposure notification applications COVID Shield and COVID Green: 
    • It’s not part of my oversight of OSTIF on behalf of the LF, but I also informally talk with OSTIF about other OSS they’re auditing (such as flux2, lodash, jackson-core, jackson-databind, httpcomponents-core, httpcomponents-client, laravel, and slf4j). A little coordination and advice-sharing among experts can make everything better.

The future is hard to predict, but we anticipate that we will be doing more. In late July, the OpenSSF Technical Advisory Council (TAC) recommended approving funding for a security audit of (part of) Symfony, a widely-used web framework. The OpenSSF Governing Board (GB) approved this on 2021-08-05 and I expect OSTIF will soon take bids on it.

The OpenSSF is also taking steps to raise more money via membership dues (this was delayed due to COVID; starting a new foundation is harder during a pandemic). Once the OpenSSF has more money, we expect they’ll be funding a lot more work to identify critical projects, do security audits, fix problems, and improve or create projects to enhance OSS security. The future looks bright.

Please remember that this is only a small part of ongoing work to improve OSS security. Almost all LF projects need to be secure, so most foundations’ projects include security efforts not listed here. As noted earlier, most development work is done by volunteers or by non-LF organizations directly paying people to do the work (typically employees). 

The OpenSSF has several working groups and many projects where people are working together to improve OSS security. These include free courses on how to develop secure software and the CII Best Practices badge project. We (at the LF) also have many other projects working to improve OSS security. For example, sigstore is making cryptographic signatures much easier; sigstore’s “cosign” tool just released its version 1.0. Many organizations have recently become interested in software bill-of-materials (SBOMs), and we’ve been working on SBOMs for a long time.

If you or your organization would like to fund focused work on improving OSS security, please reach out! You can contribute to the OpenSSF (in general or as a directed fund); just contact them (e.g., Microsoft contributed to OpenSSF in December 2020). If you’d prefer, you can create a grant directly with the Linux Foundation itself — just email me at <dwheeler@linuxfoundation.org> if you have questions. For smaller amounts, say to fund a specific project, you can also consider using the LFX crowdfunding tools to fund or request funding. Many people & organizations struggle to pay individual OSS developers because of the need to handle taxes and oversight. If that’s your concern, talk to us. The LF has experience & processes to do all that, letting experts focus on getting the work done.

My sincere thanks to all the performers for their important work and to all the funders for their confidence in us!

About the author: David A. Wheeler is Director of Open Source Supply Chain Security for The Linux Foundation.

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:

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/

Nearly a year after the Internet Engineering Task Force took up a plan to replace words that could be considered racist, the debate is still raging.

Anyone who joined a video call during the pandemic probably has a global volunteer organization called the Internet Engineering Task Force to thank for making the technology work. The group, which helped create the technical foundations of the internet, designed the language that allows most video to run smoothly online. It made it possible for someone with a Gmail account to communicate with a friend who uses Yahoo, and for shoppers to safely enter their credit card information on e-commerce sites.

Now the organization is tackling an even thornier issue: getting rid of computer engineering terms that evoke racist history, like “master” and “slave” and “whitelist” and “blacklist.”

But what started as an earnest proposal has stalled as members of the task force have debated the history of slavery and the prevalence of racism in tech. Some companies and tech organizations have forged ahead anyway, raising the possibility that important technical terms will have different meanings to different people — a troubling proposition for an engineering world that needs broad agreement so technologies work together.

While the fight over terminology reflects the intractability of racial issues in society, it is also indicative of a peculiar organizational culture that relies on informal consensus to get things done.

The Internet Engineering Task Force eschews voting, and it often measures consensus by asking opposing factions of engineers to hum during meetings. The hums are then assessed by volume and ferocity. Vigorous humming, even from only a few people, could indicate strong disagreement, a sign that consensus has not yet been reached.

The I.E.T.F. has created rigorous standards for the internet and for itself. Until 2016, it required the documents in which its standards are published to be precisely 72 characters wide and 58 lines long, a format adapted from the era when programmers punched their code into paper cards and fed them into early IBM computers.

“We have big fights with each other, but our intent is always to reach consensus,” said Vint Cerf, one of the founders of the task force and a vice president at Google. “I think that the spirit of the I.E.T.F. still is that, if we’re going to do anything, let’s try to do it one way so that we can have a uniform expectation that things will function.”

The group is made up of about 7,000 volunteers from around the world. It has two full-time employees, an executive director and a spokesman, whose work is primarily funded by meeting dues and the registration fees of dot-org internet domains. It cannot force giants like Amazon or Apple to follow its guidance, but tech companies often choose to do so because the I.E.T.F. has created elegant solutions for engineering problems.

Its standards are hashed out during fierce debates on email lists and at in-person meetings. The group encourages participants to fight for what they believe is the best approach to a technical problem.

While shouting matches are not uncommon, the Internet Engineering Task Force is also a place where young technologists break into the industry. Attending meetings is a rite of passage, and engineers sometimes leverage their task force proposals into job offers from tech giants.

In June, against the backdrop of the Black Lives Matter protests, engineers at social media platforms, coding groups and international standards bodies re-examined their code and asked themselves: Was it racist? Some of their databases were called “masters” and were surrounded by “slaves,” which received information from the masters and answered queries on their behalf, preventing them from being overwhelmed. Others used “whitelists” and “blacklists” to filter content.

Mallory Knodel, the chief technology officer at the Center for Democracy and Technology, a policy organization, wrote a proposal suggesting that the task force use more neutral language. Invoking slavery was alienating potential I.E.T.F. volunteers, and the terms should be replaced with ones that more clearly described what the technology was doing, argued Ms. Knodel and the co-author of her proposal, Nielsten Oever, a postdoctoral researcher at the University of Amsterdam. “Blocklist” would explain what a blacklist does, and “primary” could replace “master,” they wrote.

On an email list, responses trickled in. Some were supportive. Others proposed revisions. And some were vehemently opposed. One respondent wrote that Ms. Knodel’s draft tried to construct a new “Ministry of Truth.”

Amid insults and accusations, many members announced that the battle had become too toxic and that they would abandon the discussion.

The pushback didn’t surprise Ms. Knodel, who had proposed similar changes in 2018 without gaining traction. The engineering community is “quite rigid and averse to these sorts of changes,” she said. “They are averse to conversations about community comportment, behavior — the human side of things.”

In July, the Internet Engineering Task Force’s steering group issued a rare statement about the draft from Ms. Knodel and Mr. ten Oever. “Exclusionary language is harmful,” it said.

A month later, two alternative proposals emerged. One came from Keith Moore, an I.E.T.F. contributor who initially backed Ms. Knodel’s draft before creating his own. His cautioned that fighting over language could bottleneck the group’s work and argued for minimizing disruption.

The other came from Bron Gondwana, the chief executive of the email company Fastmail, who said he had been motivated by the acid debate on the mailing list.

“I could see that there was no way we would reach a happy consensus,” he said. “So I tried to thread the needle.”

Mr. Gondwana suggested that the group should follow the tech industry’s example and avoid terms that would distract from technical advances.

Last month, the task force said it would create a new group to consider the three drafts and decide how to proceed, and members involved in the discussion appeared to favor Mr. Gondwana’s approach. Lars Eggert, the organization’s chair and the technical director for networking at the company NetApp, said he hoped guidance on terminology would be issued by the end of the year.

The rest of the industry isn’t waiting. The programming community that maintains MySQL, a type of database software, chose “source” and “replica” as replacements for “master” and “slave.” GitHub, the code repository owned by Microsoft, opted for “main” instead of “master.”

In July, Twitter also replaced a number of terms after Regynald Augustin, an engineer at the company, came across the word “slave” in Twitter’s code and advocated change.

But while the industry abandons objectionable terms, there is no consensus about which new words to use. Without guidance from the Internet Engineering Task Force or another standards body, engineers decide on their own. The World Wide Web Consortium, which sets guidelines for the web, updated its style guide last summer to “strongly encourage” members to avoid terms like “master” and “slave,” and the IEEE, an organization that sets standards for chips and other computing hardware, is weighing a similar change.

Other tech workers are trying to solve the problem by forming a clearinghouse for ideas about changing language.

That effort, the Inclusive Naming Initiative, aims to provide guidance to standards bodies and companies that want to change their terminology but don’t know where to begin.

The group got together while working on an open-source software project, Kubernetes, which like the I.E.T.F. accepts contributions from volunteers. Like many others in tech, it began the debate over terminology last summer.

“We saw this blank space,” said Priyanka Sharma, the general manager of the Cloud Native Computing Foundation, a nonprofit that manages Kubernetes. Ms. Sharma worked with several other Kubernetes contributors, including Stephen Augustus and Celeste Horgan, to create a rubric that suggests alternative words and guides people through the process of making changes without causing systems to break. Several major tech companies, including IBM and Cisco, have signed on to follow the guidance.

Priyanka Sharma

Priyanka Sharma and several other tech workers in the Inclusive Naming Initiative came up
with a rubric to suggest alternative words

Although the Internet Engineering Task Force is moving more slowly, Mr. Eggert said it would eventually establish new guidelines. But the debate over the nature of racism — and whether the organization should weigh in on the matter — has continued on its mailing list.

In a subversion of an April Fools’ Day tradition within the group, several members submitted proposals mocking diversity efforts and the push to alter terminology in tech.

Two prank proposals were removed hours later because they were “racist and deeply disrespectful,” Mr. Eggert wrote in an email to task force participants, while a third remained up.

“We build consensus the hard way, so to speak, but in the end the consensus is usually stronger because people feel their opinions were reflected,” Mr. Eggert said. “I wish we could be faster, but on topics like this one that are controversial, it’s better to be slower.”

Kate Conger is a technology reporter in the San Francisco bureau, where she covers the gig economy and social media. @kateconger

Linux Foundation Blog Post Abstract Graphic

Every month there seems to be a new software vulnerability showing up on social media, which causes open source program offices and security teams to start querying their inventories to see how FOSS components they use may impact their organizations. 

Frequently this information is not available in a consistent format within an organization for automatic querying and may result in a significant amount of email and manual effort. By exchanging software metadata in a standardized software bill of materials (SBOM) format between organizations, automation within an organization becomes simpler, accelerating the discovery process and uncovering risk so that mitigations can be considered quickly. 

In the last year, we’ve also seen standards like OpenChain (ISO/IEC 5320:2020) gain adoption in the supply chain. Customers have started asking for a bill of materials from their suppliers as part of negotiation and contract discussions to conform to the standard. OpenChain has a focus on ensuring that there is sufficient information for license compliance, and as a result, expects metadata for the distributed components as well. A software bill of materials can be used to support the systematic review and approval of each component’s license terms to clarify the obligations and restrictions as it applies to the distribution of the supplied software and reduces risk. 

Kate Stewart, VP, Dependable Embedded Systems, The Linux Foundation, will host a complimentary mentorship webinar entitled Generating Software Bill Of Materials on Thursday, March 25 at 7:30 am PST. This session will work through the minimum elements included in a software bill of materials and detail the reasoning behind why those elements are included. To register, please click here

There are many ways this software metadata can be shared. The common SBOM document format options (SPDX, SWID, and CycloneDX) will be reviewed so that the participants can better understand what is available for those just starting. 

This mentorship session will work through some simple examples and then guide where to find the next level of details and further references. 

At the end of this session, participants will be on a secure footing and a path towards the automated generation of SBOMs as part of their build and release processes in the future. 

Jason Perlow, Director of Project Insights and Editorial Content at the Linux Foundation, had an opportunity to speak with Shuah Khan about her experiences as a woman in the technology industry. She discusses how mentorship can improve the overall diversity and makeup of open source projects, why software maintainers are important for the health of open source projects such as the Linux kernel, and how language inclusivity and codes of conduct can improve relationships and communication between software maintainers and individual contributors.

JP: So, Shuah, I know you wear many different hats at the Linux Foundation. What do you call yourself around here these days?

SK: <laughs> Well, I primarily call myself a Kernel Maintainer & Linux Fellow. In addition to that, I focus on two areas that are important to the continued health and sustainability of the open source projects in the Linux ecosystem. The first one is bringing more women into the Kernel community, and additionally, I am leading the mentorship program efforts overall at the Linux Foundation. And in that role, in addition to the Linux Kernel Mentorship, we are looking at how the Linux Foundation mentorship program is working overall, how it is scaling. I make sure the LFX Mentorship platform scales and serves diverse mentees and mentors’ needs in this role. 

The LF mentorships program includes several projects in the Linux kernel, LFN, HyperLedger, Open MainFrame, OpenHPC, and other technologies. The Linux Foundation’s Mentorship Programs are designed to help developers with the necessary skills–many of whom are first-time open source contributors–experiment, learn, and contribute effectively to open source communities. 

The mentorship program has been successful in its mission to train new developers and make these talented pools of prospective employees trained by experts to employers. Several graduated mentees have found jobs. New developers have improved the quality and security of various open source projects, including the Linux kernel. Several Linux kernel bugs were fixed, a new subsystem mentor was added, and a new driver maintainer is now part of the Linux kernel community. My sincere thanks to all our mentors for volunteering to share their expertise.

JP: How long have you been working on the Kernel?

SK: Since 2010, or 2011, I got involved in the Android Mainlining project. My first patch removed the Android pmem driver.

JP: Wow! Is there any particular subsystem that you specialize in?

SK: I am a self described generalist. I maintain the kernel self-test subsystem, the USB over IP driver, usbip tool, and the cpupower tool. I contributed to the media subsystem working on Media Controller Device Allocator API to resolve shared device resource management problems across device drivers from different subsystems.

JP: Hey, I’ve actually used the USB over IP driver when I worked at Microsoft on Azure. And also, when I’ve used AWS and Google Compute. 

SK: It’s a small niche driver used in cloud computing. Docker and other containers use that driver heavily. That’s how they provide remote access to USB devices on the server to export devices to be imported by other systems for use.

JP: I initially used it for IoT kinds of stuff in the embedded systems space. Were you the original lead developer on it, or was it one of those things you fell into because nobody else was maintaining it?

SK: Well, twofold. I was looking at USB over IP because I like that technology. it just so happened the driver was brought from the staging tree into the Mainline kernel, I volunteered at the time to maintain it. Over the last few years, we discovered some security issues with it, because it handles a lot of userspace data, so I had a lot of fun fixing all of those. <laugh>.

JP: What drew you into the Linux operating system, and what drew you into the kernel development community in the first place?

SK: Well, I have been doing kernel development for a very long time. I worked on the LynxOS RTOS, a while back, and then HP/UX, when I was working at HP, after which I transitioned into  doing open source development — the OpenHPI project, to support HP’s rack server hardware, and that allowed me to work much more closely with Linux on the back end. And at some point, I decided I wanted to work with the kernel and become part of the Linux kernel community. I started as an independent contributor.

JP: Maybe it just displays my own ignorance, but you are the first female, hardcore Linux kernel developer I have ever met. I mean, I had met female core OS developers before — such as when I was at Microsoft and IBM — but not for Linux. Why do you suppose we lack women and diversity in general when participating in open source and the technology industry overall?

SK: So I’ll answer this question from my perspective, from what I have seen and experienced, over the years. You are right; you probably don’t come across that many hardcore women Kernel developers. I’ve been working professionally in this industry since the early 1990s, and on every project I have been involved with, I am usually the only woman sitting at the table. Some of it, I think, is culture and society. There are some roles that we are told are acceptable to women — even me, when I was thinking about going into engineering as a profession. Some of it has to do with where we are guided, as a natural path. 

There’s a natural resistance to choosing certain professions that you have to overcome first within yourself and externally. This process is different for everybody based on their personality and their origin story. And once you go through the hurdle of getting your engineering degree and figuring out which industry you want to work in, there is a level of establishing credibility in those work environments you have to endure and persevere. Sometimes when I would walk into a room, I felt like people were looking at me and thinking, “why is she here?” You aren’t accepted right away, and you have to overcome that as well. You have to go in there and say, “I am here because I want to be here, and therefore, I belong here.” You have to have that mindset. Society sends you signals that “this profession is not for me” — and you have to be aware of that and resist it. I consider myself an engineer that happens to be a woman as opposed to a woman engineer.

JP: Are you from India, originally?

SK: Yes.

JP: It’s funny; my wife really likes this Netflix show about matchmaking in India. Are you familiar with it?

SK: <laughs> Yes I enjoyed the series, and A Suitable Girl documentary film that follows three women as they navigate making decisions about their careers and family obligations.

JP: For many Americans, this is our first introduction to what home life is like for Indian people. But many of the women featured on this show are professionals, such as doctors, lawyers, and engineers. And they are very ambitious, but of course, the family tries to set them up in a marriage to find a husband for them that is compatible. As a result, you get to learn about the traditional values and roles they still want women to play there — while at the same time, many women are coming out of higher learning institutions in that country that are seeking technical careers. 

SK: India is a very fascinatingly complex place. But generally speaking, in a global sense, having an environment at home where your parents tell you that you may choose any profession you want to choose is very encouraging. I was extremely fortunate to have parents like that. They never said to me that there was a role or a mold that I needed to fit into. They have always told me, “do what you want to do.” Which is different; I don’t find that even here, in the US. Having that support system, beginning in the home to tell you, “you are open to whatever profession you want to choose,” is essential. That’s where a lot of the change has to come from. 

JP: Women in technical and STEM professions are becoming much more prominent in other countries, such as China, Japan, and Korea. For some reason, in the US, I tend to see more women enter the medical profession than hard technology — and it might be a level of effort and perceived reward thing. You can spend eight years becoming a medical doctor or eight years becoming a scientist or an engineer, and it can be equally difficult, but the compensation at the end may not be the same. It’s expensive to get an education, and it takes a long time and hard work, regardless of the professional discipline.

SK: I have also heard that women also like to enter professions where they can make a difference in the world — a human touch, if you will. So that may translate to them choosing careers where they can make a larger impact on people — and they may view careers in technology as not having those same attributes. Maybe when we think about attracting women to technology fields, we might have to promote technology aspects that make a difference. That may be changing now, such as the LF Public Health (LFPH) project we kicked off last year. And with LF AI & Data Foundation, we are also making a difference in people’s lives, such as detecting earthquakes or analyzing climate change. If we were to promote projects such as these, we might draw more women in.

JP: So clearly, one of the areas of technology where you can make a difference is in open source, as the LF is hosting some very high-concept and existential types of projects such as LF Energy, for example — I had no idea what was involved in it and what its goals were until I spoke to Shuli Goodman in-depth about it. With the mentorship program, I assume we need this to attract fresh talent — because as folks like us get older and retire, and they exit the field, we need new people to replace them. So I assume mentorship, for the Linux Foundation, is an investment in our own technologies, correct?

SK: Correct. Bringing in new developers into the fold is the primary purpose, of course — and at the same time, I view the LF as taking on mentorship provides that neutral, level playing field across the industry for all open source projects. Secondly, we offer a self-service platform, LFX Mentorship, where anyone can come in and start their project. So when the COVID-19 pandemic began, we expanded this program to help displaced people — students, et cetera, and less visible projects. Not all projects typically get as much funding or attention as others do — such as a Kubernetes or  Linux kernel — among the COVID mentorship program projects we are funding. I am particularly proud of supporting a climate change-related project, Using Machine Learning to Predict Deforestation.

The self-service approach allows us to fund and add new developers to projects where they are needed. The LF mentorships are remote work opportunities that are accessible to developers around the globe. We see people sign up for mentorship projects from places we haven’t seen before, such as Africa, and so on, thus creating a level playing field. 

The other thing that we are trying to increase focus on is how do you get maintainers? Getting new developers is a starting point, but how do we get them to continue working on the projects they are mentored on? As you said, someday, you and I and others working on these things are going to retire, maybe five or ten years from now. This is a harder problem to solve than training and adding new developers to the project itself.

JP: And that is core to our software supply chain security mission. It’s one thing to have this new, flashy project, and then all these developers say, “oh wow, this is cool, I want to join that,” but then, you have to have a certain number of people maintaining it for it to have long-term viability. As we learned in our FOSS study with Harvard, there are components in the Linux operating system that are like this. Perhaps even modules within the kernel itself, I assume that maybe you might have only one or two people actively maintaining it for many years. And what happens if that person dies or can no longer work? What happens to that code? And if someone isn’t familiar with that code, it might become abandoned. That’s a serious problem in open source right now, isn’t it?

SK: Right. We have seen that with SSH and other security-critical areas. What if you don’t have the bandwidth to fix it? Or the money to fix it? I ended up volunteering to maintain a tool for a similar reason when the maintainer could no longer contribute regularly. It is true; we have many drivers where maintainer bandwidth is an issue in the kernel. So the question is, how do we grow that talent pool?

JP: Do we need a job board or something? We need X number of maintainers. So should we say, “Hey, we know you want to join the kernel project as a contributor, and we have other people working on this thing, but we really need your help working on something else, and if you do a good job, we know tons of companies willing to hire developers just like you?” 

SK: With the kernel, we are talking about organic growth; it is just like any other open source project. It’s not a traditional hire and talent placement scenario. Organically they have to have credibility, and they have to acquire it through experience and relationships with people on those projects. We just talked about it at the previous Linux Plumbers Conference, we do have areas where we really need maintainers, and the MAINTAINERS file does show areas where they need help. 

To answer your question, it’s not one of those things where we can seek people to fill that role, like LinkedIn or one of the other job sites. It has to be an organic fulfillment of that role, so the mentorship program is essential in creating those relationships. It is the double-edged sword of open source; it is both the strength and weakness. People need to have an interest in becoming a maintainer and also a commitment to being one, long term.

JP: So, what do you see as the future of your mentorship and diversity efforts at the Linux Foundation? What are you particularly excited about that is forthcoming that you are working on?

SK: I view the Linux Foundation mentoring as a three-pronged approach to provide unstructured webinars, training courses, and structured mentoring programs. All of these efforts combine to advance a diverse, healthy, and vibrant open source community. So over the past several months, we have been morphing our speed mentorship style format into an expanded webinar format — the LF Live Mentorship series. This will have the function of growing our next level of expertise. As a complement to our traditional mentorship programs, these are webinars and courses that are an hour and a half long that we hold a few times a month that tackle specific technical areas in software development. So it might cover how to write great commit logs, for example, for your patches to be accepted, or how to find bugs in C code. Commit logs are one of those things that are important to code maintenance, so promoting good documentation is a beneficial thing. Webinars provide a way for experts short on time to share their knowledge with a few hours of time commitment and offer a self-paced learning opportunity to new developers.

Additionally, I have started the Linux Kernel Mentorship forum for developers and their mentors to connect and interact with others participating in the Linux Kernel Mentorship program and graduated mentees to mentor new developers. We kicked off Linux Kernel mentorship Spring 2021 and are planning for Summer and Fall.

A big challenge is we are short on mentors to be able to scale the structured program. Solving the problem requires help from LF member companies and others to encourage their employees to mentor, “it takes a village,” they say.

JP: So this webinar series and the expanded mentorship program will help developers cultivate both hard and soft skills, then.

SK: Correct. The thing about doing webinars is that if we are talking about this from a diversity perspective, they might not have time for a full-length mentorship, typically like a three-month or six-month commitment. This might help them expand their resources for self-study. When we ask for developers’ feedback about what else they need to learn new skill sets, we hear that they don’t have resources, don’t have time to do self-study, and learn to become open source developers and software maintainers. This webinar series covers general open source software topics such as the Linux kernel and legal issues. It could also cover topics specific to other LF projects such as CNCF, Hyperledger, LF Networking, etc.

JP: Anything else we should know about the mentorship program in 2021?

SK: In my view,  attracting diversity and new people is two-fold. One of the things we are working on is inclusive language. Now, we’re not talking about curbing harsh words, although that is a component of what we are looking at. The English you and I use in North America isn’t the same English used elsewhere. As an example, when we use North American-centric terms in our email communications, such as when a maintainer is communicating on a list with people from South Korea, something like “where the rubber meets the road” may not make sense to them at all. So we have to be aware of that.

JP: I know that you are serving on the Linux kernel Code of Conduct Committee and actively developing the handbook. When I first joined the Linux Foundation, I learned what the Community Managers do and our governance model. I didn’t realize that we even needed to have codes of conduct for open source projects. I have been covering open source for 25 years, but I come out of the corporate world, such as IBM and Microsoft. Codes of Conduct are typically things that the Human Resources officer shows you during your initial onboarding, as part of reviewing your employee manual. You are expected to follow those rules as a condition of employment. 

So why do we need Codes of Conduct in an open source project? Is it because these are people who are coming from all sorts of different backgrounds, companies, and ways of life, and may not have interacted in this form of organized and distributed project before? Or is it about personalities, people interacting with each other over long distance, and email, which creates situations that may arise due to that separation?

SK: Yes, I come out of the corporate world as well, and of course, we had to practice those codes of conduct in that setting. But conduct situations arise that you have to deal with in the corporate world. There are always interpersonal scenarios that can be difficult or challenging to work with — the corporate world isn’t better than the open source world in that respect. It is just that all of that happens behind a closed setting.

But there is no accountability in the open source world because everyone participates out of their own free will. So on a small, traditional closed project, inside the corporate world, where you might have 20 people involved, you might get one or two people that could be difficult to work with. The same thing happens and is multiplied many times in the open source community, where you have hundreds of thousands of developers working across many different open source projects. 

The biggest problem with these types of projects when you encounter situations such as this is dealing with participation in public forums. In the corporate world, this can be addressed in private. But on a public mailing list, if you are being put down or talked down to, it can be extremely humiliating. 

These interactions are not always extreme cases; they could be simple as a maintainer or a lead developer providing negative feedback — so how do you give it? It has to be done constructively. And that is true for all of us.

JP: Anything else?

SK: In addition to bringing our learnings and applying this to the kernel project, I am also doing this on the ELISA project, where I chair the Technical Steering Committee, where I am bridging communication between experts from the kernel and the safety communities. To make sure we can use the kernel the best ways in safety-critical applications, in the automotive and medical industry, and so on. Many lessons can be learned in terms of connecting the dots, defining clearly what is essential to make Linux run effectively in these environments, in terms of dependability. How can we think more proactively instead of being engaged in fire-fighting in terms of security or kernel bugs? As a result of this, I am also working on any necessary kernel changes needed to support these safety-critical usage scenarios.

JP: Before we go, what are you passionate about besides all this software stuff? If you have any free time left, what else do you enjoy doing?

SK: I read a lot. COVID quarantine has given me plenty of opportunities to read. I like to go hiking, snowshoeing, and other outdoor activities. Living in Colorado gives me ample opportunities to be in nature. I also like backpacking — while I wasn’t able to do it last year because of COVID — I like to take backpacking trips with my son. I also love to go to conferences and travel, so I am looking forward to doing that again as soon as we are able.

Talking about backpacking reminded me of the two-day, 22-mile backpacking trip during the summer of 2019 with my son. You can see me in the picture above at the end of the road, carrying a bearbox, sleeping bag, and hammock. It was worth injuring my foot and hurting in places I didn’t even know I had.

JP: Awesome. I enjoyed talking to you today. So happy I finally got to meet you virtually.

Open Source Summit Europe, October 26, 2020 – The Linux Foundation, the nonprofit organization enabling mass innovation through open source, today announced the Software Developer Diversity and Inclusion (SDDI) project. SDDI will explore, evaluate, and promote best practices from research and industry to increase diversity and inclusion in software engineering. Founding contributors include Comcast, Facebook, GitHub, Intel and VMware and research professors from Beijing University of Posts and Telecommunications, Eindhoven University of Technology, Oregon State University, University of Auckland and University of Victoria.

According to StackOverflow’s 2020 survey of more than 65,000 developers, 91.7 percent identify as male and 70.7 percent as white or of European descent. There is a tremendous amount of work to be done to create inclusive environments that can lead to a more diverse community building the software that is the foundation for our digital society. Research indicates that racially diverse groups make better decisions, diverse open source projects are more productive and that working on gender diverse teams improves attitudes towards women.

“While there are a variety of important diversity and inclusion initiatives in the technology industry, none are focused on increasing diversity across categories – race, gender, age and cognitive ability –  in software engineering and informed by science and research,” said Kate Stewart, senior director of strategic programs at Linux Foundation. “We have optimism about the future of the open source community and our collective ability to increase diversity and inclusion. The work we do today can influence the vibrancy of the community and effectiveness of our technologies tomorrow.”

SDDI will include a steering committee and working groups that explore, evaluate and promote best practices from research and industry to increase diversity and inclusion in software engineering. The steering committee will be responsible for prioritizing the initial working groups, which could address research methods, ethics, resources and data, as well as diversity in the areas of gender, age, cognitive ability and education.

Open source projects are encouraged to participate in SDDI to inform best practices and to benefit from the findings of the Project. Existing Linux Foundation projects – TODO, which focuses on open source program office best practices, and the CHAOSS Project, which identifies tooling and metrics for diversity and inclusion – will also work closely with the new SDDI Project.

Supporting Comments

“The Software Developer Diversity and Inclusion Project (SDDI) is an excellent initiative that complements the work of the CHAOSS Project. Through collaboration, we can accelerate progress towards building a better virtual workplace for all developers,” said Nicole Huesman, Governing Board Co-Chair, the CHAOSS Project. “We’re looking forward to the research and best practices that surface from this work, so we can implement it in our work on metrics and tooling.”

“Diversity and inclusion are the cornerstone of building long term sustainable open source communities and programs,” said Chris Aniszczyk, co-founder of the TODO Group and CTO, CNCF. “The TODO Group looks forward to collaborating with the SDDI to share lessons and best practices from corporate open source programs.”

“Inclusive Open Source is of vital importance to industry and academia. The Software Developer Diversity and Inclusion (SDDI) project is a great initiative to bring inclusivity to OSS projects and products. For example, gender biases are embedded in the very tools that OSS projects use and the way information is structured. I look forward to working with SDDI to bring down these barriers, one feature at a time,” said Dr. Anita Sarma, Associate Professor, Computer Science, School of EECS, Oregon State University.

“Software systems are responsible for all aspects of modern life. They help humans make critical short-term and long-term societal and personal decisions, and yet the diversity and values of the people designing software systems do not remotely represent the diversity and values of people on our planet. The SDDI initiative, an active collaboration between industry and academia, will drive essential and rigorous research towards understanding barriers to diversity and inclusion while also discovering and promoting best practices,” said Margaret-Anne Storey, University of Victoria, Canada.

“Despite significant efforts over recent years to increase diversity and inclusion in many software companies, little traction has been made. This signals that new ways of thinking are needed to better understand the barriers and best practices. This initiative can help to stimulate new understanding and develop improved diversity and inclusion practices, which will lead to more innovative and useful software products,” said Kelly Blincoe, University of Auckland, New Zealand.

“Diversity is essential not only to create products that address needs of diverse groups of users but also to create sustainable and vibrant development teams. SDDI has the power and the promise to combine best industrial practices, insights from open source software developments and findings of the academic research to bring change in the ways teams are are organised and work together, and ultimately both in more comfortable and sustainable working environment, and better software products,” said Alexander Serebrenik, Eindhoven University of Technology, The Netherlands.

“Diversity and inclusion in software development have broad impact beyond our industry, particularly for those who are living in low and medium HDI countries. For them, being included in the software development profession is often a life-changing opportunity. I believe SDDI, a strong collaboration between academia and industry, would benefit the disadvantaged groups around the world,” said Yi Wang, Professor, Beijing University of Posts and Telecommunications.

“Diversity of thought is a vital component for building sustainable and healthy open source communities. Individuals from diverse backgrounds injecting new and innovative ideas advances an inclusive and welcoming ecosystem for all. SDDI with its focus on best practices in increasing D&I will be instrumental in providing the right direction for all committed to increasing diversity,” said Shuah Khan, Kernel Maintainer & Fellow, the Linux Foundation.

“Without an intentional and coordinated effort like the SDDI, it will be hard to move the needle on more diversity in software engineering.   There are many great practices across open source, companies and universities that we need to aggregate, make easier to discover and put into action.  The Linux Foundation is at the center of all of these communities and can get us together to improve the state of diversity in tech,” said Nithya Ruff, Head of Comcast Open Source Program Office, Chair, Linux Foundation Board.

“At Intel, we believe diverse and inclusive teams are more creative and innovative. We continue to raise the bar in areas such as representation, pay equity, and inclusion initiatives. This year, we announced our 2030 goals, global challenges and RISE strategy to create a more responsible, inclusive, and sustainable world, enabled through technology and our collective actions. We welcome the Linux Foundation’s new SDDI initiative to focus on improving inclusion and representation in the Open Source community and look forward to furthering this effort,” said Melissa Evers-Hood, Vice President, General Manager of Software Business Strategy, Intel Architecture, Graphics and Software, Intel Corporation

“Open source lifts all boats — creating innovation and opportunity for developers around the world. For Facebook, investing in open source is a way to empower developers as well as broader communities of individuals and businesses. To that end, we’re thrilled to support Linux Foundation’s SDDI effort which will not only help us invest in the next generation of open source developers but also promote increasing diversity in tech,” said Kathy Kam, Head of Open Source, Facebook.

“As home to most of the world’s open source software, GitHub believes deeply in the potential of a passionate, diverse open source community to move our world forward and accelerate human progress. GitHub is thrilled to collaborate on this project, which will allow us to “open source diversity and inclusion” for the benefit of us all. By making software development more accessible, inclusive, and sustainable, we can support the growth of a community where all developers — no matter who or where they are in the world — can learn, contribute, grow, and feel like they belong,” said Demetris Cheatham, Senior Director of Diversity, Inclusion and Belonging, GitHub.

“Innovation is a core tenet of VMware. We know that to make faster progress around Diversity and Inclusion we need to apply innovation and research the same way we do to technology problems. Supporting initiatives like this aligns with our values and is critical to the long term success of the technology industry as a whole,” said Shanis Windland, vice president, Diversity and Inclusion, VMware.

“SDDI will be an important initiative,” said Daniel Izquierdo, cofounder of Bitergia. “We at Bitergia do D&I research for customers and we look forward to sharing our experience and learning from others through SDDI.”

For more information about SDDI and to contribute, please visit: https://sddiproject.org/

About the Linux Foundation

Founded in 2000, the Linux Foundation is supported by more than 1,500 members and is the world’s leading home for collaboration on open source software, open standards, open data, and open hardware. Linux Foundation’s projects are critical to the world’s infrastructure including Linux, Kubernetes, Node.js, and more.  The Linux Foundation’s methodology focuses on leveraging best practices and addressing the needs of contributors, users and solution providers to create sustainable models for open collaboration. For more information, please visit us at linuxfoundation.org.

###

The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see its trademark usage page: www.linuxfoundation.org/trademark-usage. Linux is a registered trademark of Linus Torvalds.

Media Contact
Jennifer Cloer
503-867-2304
pr@linuxfoundation.org

[1] Sommers, Samuel R. “On racial diversity and group decision making: identifying multiple effects of racial composition on jury deliberations.” Journal of personality and social psychology 90.4 (2006): 597. Vasilescu, Bogdan, et al. “Gender and tenure diversity in GitHub teams.” Proceedings of the 33rd annual ACM conference on human factors in computing systems. 2015. Wang, Oliver and Zhang, Min. “Reducing Implicit Gender Biases in Software Development: Does Intergroup Contact Theory Work?” Proceedings of Foundations of Software Engineering. 2020.