Establishing a security baseline for open source projects

In this Help Net Security interview, Dana Wang, Chief Architect at OpenSSF, discusses the most significant barriers to improving open-source software security (OSS security) and opportunities for overcoming these challenges.

The OpenSSF community has developed open-source security tools and projects, aiming to make security the default and promote a collaborative effort to strengthen the security posture of open-source ecosystems.

What are the most significant barriers to improving OSS security, and what opportunities exist for overcoming these challenges?

Open-source software is the foundation of the digital world we live in. As open source code develops, it moves through the supply chain from a contributor or maintainer’s machine to a software repository, going through the CI/CD process, injecting dependencies, and landing in the package registry to be ingested into downstream consumers’ ecosystems. Because of this process, threats exist at every link of the chain.

There have been no consistent baseline security requirements for securely developing and releasing open-source software. OpenSSF is working to combat that challenge by establishing a security baseline for open-source projects and aims to propagate it across the Linux Foundation. We aim to ensure we have minimally viable secure open source projects and build security into an open source software incrementally as the software becomes production-ready.

Another challenge is that ecosystem support of tooling/configuration capabilities varies, depending on the programming languages and the roadmaps for new features or feature enhancements. This begs the question: how do we make security less of a burden while uplifting the security posture through the adoption of the security baseline? The answer is automation. Making security the default through automation and tooling is where we want to be. Achieving security through labor can be discouraging, especially for developers who do not have training or education in security.

OpenSSF has a collection of open-source security tools, all built for specific purposes to aid in the challenge of making security less of a burden. We currently have Sigstore for artifact signing, SLSA for build provenance, Witness and Archivista for attestation, OSV and OpenVEX for vulnerability management, Security Insight for fuzzers, Scorecard for gauging the security posture of a project and Allstar for enforcing security policies. It’s intimidating for new contributors to analyze the extensive list of the tools available to insert into their SDLC process.

The OpenSSF community has developed GUAC to aggregate data from all these technologies, observing the inconsistent adoptions and data quality issues with SBOM, and was also inspired to build a new project called Skootrs, to instrument these capabilities through code when bootstrapping a project to make security adopted by default.

Finally, the biggest constraint is maintainers’ limited personal time and the demands for open source software maintenance, including enhancing software security. Balancing the security, reliability, availability, performance, and cost of open-source software is not trivial. Maintainers sometimes have to choose between new features, bug fixes, and less critical security patches.

How does the involvement of major tech companies in open-source projects influence security standards and practices?

Contributors and maintainers from major tech companies bring their security expertise, passion, and practical abilities from those enterprise organizations into open-source communities such as OpenSSF. They have made global impacts in many areas, including education and training, specifications and frameworks, public policies, software-based tools including security tools, and public-instance internet services.

For our organization, community members are able to get hands-on training from those contributors and maintainers through OpenSSF guides, online classes, workshops, tech talk and various communication channels. Many of the big tech companies use OpenSSF technologies such as Scorecard, SLSA and S2C2F in their organization and their open source projects. These companies are the biggest consumers of open source software, they set a great example of giving back to the community by funding open source projects and allocating engineering hours to enhance open source software security.

While big tech plays a key role, we cannot overlook the influence of other players in open source, such as academia, smaller tech companies — especially startups — and independent contributors. Members across industries bring their unique market-specific security challenges and perspectives into the community, along with their wish lists of security standards and practices. They are contributing while absorbing the technical outcomes from the open source community. Many of our code contributors and maintainers are from security startups. They put their heart and soul into innovative ideas and turning those ideas into realities. They fuel security innovations.

I’m grateful to see they are able to interact with enterprise organizations to understand the challenges in those organizations and turn those challenges into opportunities. I admire the intellectual power that the Ph.D students, university professors, and researchers in private sectors bring to the open source community.

I feel security standards and best practices are achieved by the collaboration of all the members in the community and each plays their unique role to uplift other members, and collectively enhance the security posture of the open source ecosystems. It’s great to be part of the open source community, where security and software are democratized. A lot goes on collectively to make impacts for the greater public good, and that couldn’t be done without involvement from all, including major tech companies.

How effective are the open source community’s current security policies and practices, especially concerning transparency and response to vulnerabilities?

Open source communities have become more security-focused due to recent major cyber incidents. Events like Log4J have been a huge wake-up call for the industry and have made security more of a priority to the community.

Transparency is in the spirit of open-source, and enhancing it within the community is a key goal of our organization. Currently, every OpenSSF project is required to have a security policy that provides clear directions on how vulnerabilities should be reported and how they will be responded to. The security baseline also requires that. The OpenSSF Best Practice Badge program and Scorecard report if a project has a vulnerability disclosure policy. The badge program passing level has been used by other Linux Foundation open-source projects as a criteria to become generally available.

Open-source communities have been pushing the boundaries on SBOM to increase transparency in both open-source and closed source software. However, there have been challenges with SBOM consumption due to data quality and interoperability issues. Recently, OpenSSF, along with CISA and DHS S&T, took steps to address this challenge by releasing Protobom, an open-source software supply chain tool that enables all organizations, including system administrators and software development communities, to read and generate SBOMs and file data, as well as translate this data across standard industry SBOM formats.

Protobom is becoming the foundation of other OpenSSF security technologies to improve software transparency. SBOMit provides attestation while OpenVEX can consume specification-neutral SBOM data for more efficient vulnerability exploitability exchange. GUAC focuses on synthesizing data from OpenVEX, SBOMit and other solutions to provide insights into the overall security posture of an open-source software.

Maintainers often have to pay the tax for their passion due to irresponsible vulnerability disclosures by some researchers. A common concern among maintainers is that many CVEs were open for reasons that do not align with the public good spirit. I hope for the common standing of maintainers’ challenges and empathy for maintainers to achieve a healthy level of vulnerability disclosure.

How important is the role of software composition analysis and other tools in managing the security of open-source software components?

Software composition analysis (SCA) tools are essential in dependency management, which is one of the hardest problems. Software is only as secure as its weakest dependency. SCA results should be used to detect vulnerable components and make ingestion decisions. Static application security test (SAST) tools should also be used in the software development ecosystem, especially before the software is released. SAST gives you constructive feedback, it catches security vulnerabilities in the code you develop and gives you advice on how to fix them.

For mission critical open-source software, dynamic application security test (DAST) should be conducted to surface vulnerabilities as early as possible. Penetration (PEN) testing should be done for web applications. We should take a defense-in-depth approach when incorporating these tools into the SDLC process. There are open-source tools available, such as GitHub Dependabot for SCA, CodeQL for SAST and OSS Fuzz for DAST.

To manage vulnerability more effectively, an open-source vulnerability (OSV) database can be used. The ecosystem provides both human and machine-readable more granular information on vulnerabilities at the package level and it aggregates data from close to 20 different data sources.

How can better education and training in cybersecurity practices enhance the security of open-source projects?

Education and training in cybersecurity practices build the foundation for developing more secure code. They raise more awareness of the do’s, and when combined with hands-on software development, reinforce security concepts, making it a habit to maintain good security hygiene. Understanding the security fundamentals and basic principles goes a long way. Hands-on practice is the key to being better at security.

What are the emerging trends in open-source software security that organizations should be aware of?

Social engineering takeover of open-source software has been emerging. The XZ Utils backdoor attack and failed attacks on the OpenJS foundation’s projects are alarming. XZ Utils was maintained by a single maintainer before social engineering takeover. Many OpenJS projects are maintained by a single maintainer or a very small number of maintainers.

The ratio of maintainers’ open-source time or personal time and the demands from both open-source and commercial software manufacturers is as small as a drop of water in a lake. Sustaining open-source development and making it more secure needs to be shouldered by organizations that benefit from this open-source software, either through funding or through contributing developer hours.

On the policy side, there has been and will be more collaborations between open-source communities, public sector and private sectors across the globe. Cybersecurity has become part of national security, economic security and social stability. Shifting security burdens from consumers to digital goods providers will turn security and compliance from a checkbox into a concerted effort to make open-source software more secure.

The EU has set a great example with its CRA effort by holding software manufacturers accountable for their product security and creating the open-source steward role. Legislation will require collaboration between open source, policy makers and private sectors to work out an executable plan to sustain open-source software development, maintenance and continue to shoulder the digital economy.