Home

Awesome

The OpenSSF Security Toolbelt (formally known as the Sterling Toolchain)

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.

Motivation

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.

Mission

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.

Vision

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.

Strategy

To achieve the mission and vision of the Toolbelt initiative, the following strategy will be followed

  1. Expose critical security actions through the definition of specific use cases that are needed to harden the software factory from code through deploy.
  2. Define barriers to the adoption of security tooling in the software factory.
  3. Identify and address gaps in tooling that are not addressed by existing open-source and closed source security tooling categories.
  4. Create a coalition of open-source and closed source contributors to define a common security tooling vocabulary.
  5. 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.
  6. 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.
  7. 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:

  1. A strict list of security tooling.
  2. 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.

Roadmap

At each stage of this roadmap, we will revise and refine our plans based on what we have learned.

  1. 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.
  2. 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.
  3. Perform a market survey to determine what products, patterns or techniques could achieve the control requirements identified in (2), noting where there are gaps.
  4. Identify functional gaps, integration challenges, and opportunities to simplify by looking at the links between these pieces.
  5. 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.
  6. Validate the approach by working with selected OSS projects and modify it as necessary.
  7. 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.
  8. 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

<TBD>

Current Efforts

The group is developing a list of

Prior Work

Get Involved

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.

Quick Start

Areas that need contributions :

Meeting times

Governance

The CHARTER.md outlines the scope and governance of our group activities.

Project Maintainers

Project Collaborators

Project Contributors

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.]

  1. Software source code
  1. Data
  1. Specifications
  1. All other Documentation

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.