We are a group of community members working to help define the vision and execution of the OpenSSF's Security Toolbelt initiative that is focused on helping all participants and consumers in the open source software ecosystem work more securely.
We are part of the BEST Working Group.
The open source software ecosystem has incredible diversity and variation of practice. The Security Toolbelt seeks to provide consistent guidance, processes, and tools that enable open source developers to create amazing software, securely, and allow all partipants and consumers of that downstream supply chain to be able to understand the security qualities of how that software was written, assembled, and delivered to them, as well as concrete things downstream can do to implement this software securely.
Assemble a “sterling” collection of capabilities (software frameworks, specifications, and human and automated processes) that work together to automatically list, scan, remediate, and secure the components flowing through the software supply chain that come together as software is written, built, deployed, consumed, and maintained. Each piece of the collection will represent an interoperable link in that supply chain, enabling adaptation and integration into the major upstream language toolchains, developer environments, and CI/CD systems. The scanning, remediating, and listing steps will be focused on the core security principles of security by design and secure settings by default, and the data they depend on will be constantly updated based on observed threats.
A world where every software package is verifiably trustworthy, across all major open source projects and ecosystems, meaning fewer security defects across the software landscape, reduction of the costs and damages when remediating the defects that still happen, and support for the growing use of audits and regulatory requirements for secure development and deployment.
To achieve the mission and vision of the Toolbelt initiative, the following strategy will be followed
- Expose critical security actions through the definition of specific use cases that are needed to harden the software factory from code through deploy.
- Define barriers to the adoption of security tooling in the software factory.
- Identify and address gaps in tooling that are not addressed by existing open-source and closed source security tooling categories.
- Create a coalition of open-source and closed source contributors to define a common security tooling vocabulary.
- Support existing tooling integration efforts, or build a common integration layer between security tooling that can be easily integrated into developer practices, regardless of language/platform.
- Drive and then monitor the adoption of key pieces of the toolbelt into upstream language ecosystems. Where they succeed we will document and aim to make repeatable; where they underwhelm, we will analyze why. Where they fail, we will look for fixes or alternatives.
- To iterate a scalable system, we will work with the Alpha-Omega project to identify potential POC teams to test out approaches, including projects with a single maintainer.
What the strategy will not include:
- A strict list of security tooling.
- This strategy will not be a “big tent” of all possible tools and approaches, but a lean collection of strictly the most important pieces we expect the toolchains of the world to adopt. This must still be vendor-neutral.
At each stage of this roadmap, we will revise and refine our plans based on what we have learned.
- The OpenSSF will develop a clear set of capabilities, personas, use cases, taxonomy/shared language, and threat models that span the entirety of the software supply chain.
- Align controls to the threats identified and with existing control frameworks, e.g. NIST SP800-218. Where existing control frameworks are insufficient, we will propose new controls. Based on that, develop a map of the existing products, processes, templates and other IP (inside and outside the OpenSSF) that act as “controls”, that reduce the risks identified by these use cases and threat models.
- Perform a market survey to determine what products, patterns or techniques could achieve the control requirements identified in (2), noting where there are gaps.
- Identify functional gaps, integration challenges, and opportunities to simplify by looking at the links between these pieces.
- Fill those gaps by adapting interfaces/existing tools/processes/templates or driving the development of new interfaces/tools/processes/templates. Address the integration challenges by working with the existing pieces to get to e.g. better APIs. Develop a shared vocabulary to avoid confusion between the parts of the Toolbelt.
- Validate the approach by working with selected OSS projects and modify it as necessary.
- Document everything to sufficient degree as to develop a certification mark (or series of marks) that verify conformant toolchains and other supply chain components, and a dashboard or other risk measurement frameworks that drive a “race to the top” among toolchains and ecosystems.
- Develop an outreach strategy to initiate adoption and build awareness of the toolbelt solution. The outreach should be persona / platform based.
Original working document
Scope Initiatives, Projects, Working Groups, Special Interest Groups, and other collaborative efforts supported by the OpenSSF
The group is developing a list of
We currently are soliciting ideas around the design, implementation, and evangelism of the Security Toolbelt. Questions and feedback are welcome on our mailing list, slack channel, or as an issue filed here in our repo.
- Official communications occur on the The Security Toolbelt Mailing List.
- Manage your subscriptions to Open SSF mailing lists.
- Security Toolbelt Slack channel
Areas that need contributions :
- Where to file issues: Issues can be filed here in our GitHub repo.
- Every Tuesday @ 12:00pm EST OpenSSF Community Calendar
- Meeting Minutes
The CHARTER.md outlines the scope and governance of our group activities.
- Co-Lead name : Sarah Evans, Dell
- Co-Lead name: John Kjell, TestifySec
- Andrea Frittoli, IBM
- Arnaud Le Hors, IBM
- Behan Webster, The Linux Foundation
- Brandon Mitchell, IBM
- Brian Behlendorf, The Linux Foundation
- Brian Wagner, IBM
- Christopher "CRob" Robinson, Intel
- Daniel Appelquist, Synk
- David A Wheeler, LF/OSSF
- Georg Kunz, Ericsson
- Jacques Chester, independent
- Jay White, Microsoft
- Jeff Borek, IBM
- John Kjell, TestifySec
- Jon Meadows, Citi
- Josh Clements, Analog Devices
- Joshua Lock, Verizon
- Kris Borchers, independent
- Marcela Melara, Intel
- Matthew Coles, Dell
- Matt Rutkowski, IBM
- Melba Lopez, IBM
- Michael Leiberman, Kusari
- Phil Estes, AWS
- Ryan Ware, Intel
- Sal Kimmich, EscherCloud AI
- Sarah Evans, Dell
- Steve Taylor, Deployhub/Ortelius/Pyrsia
- Tom Hennen, Google
- Tracy Ragan, Deployhub/Ortelius/CDEvents
Intellectual Property
In accordance with the OpenSSF Charter (PDF), work produced by this group is licensed as follows:
[TODO: Select below the applicable license(s), delete those that don't apply, and update the LICENSE file accordingly. For specification development refer to the specific instructions on the Community Specification Getting Started page.
Note that for source code, instead of Apache, you may choose to use the MIT License available at https://opensource.org/licenses/MIT. Otherwise, no other license than those listed here may be used without approval from the Governing Board.]
- Software source code
- Apache License, Version 2.0, available at https://www.apache.org/licenses/LICENSE-2.0;
- Data
- Any of the Community Data License Agreements, available at https://www.cdla.io;
- Specifications
- Community Specification License, Version 1.0, available at https://github.com/CommunitySpecification/1.0
- All other Documentation
- Creative Commons Attribution 4.0 International License, available at https://creativecommons.org/licenses/by/4.0/
Antitrust Policy Notice
Linux Foundation meetings involve participation by industry competitors, and it is the intention of the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws.
Examples of types of actions that are prohibited at Linux Foundation meetings and in connection with Linux Foundation activities are described in the Linux Foundation Antitrust Policy available at http://www.linuxfoundation.org/antitrust-policy. If you have questions about these matters, please contact your company counsel, or if you are a member of the Linux Foundation, feel free to contact Andrew Updegrove of the firm of Gesmer Updegrove LLP, which provides legal counsel to the Linux Foundation.