🚧 This Repo Is Under Construction 🚧
Welcome to the OpenSSF Community! For any questions, concerns, reports, etc., please email operations@openssf.org.
This is the starting point for the community to learn how to contribute.
We keep a living spreadsheet of all the working groups, projects, and special interest groups that contains meeting links, notes and most recent TAC updates.
Allstar is a GitHub App that continuously monitors GitHub organizations or repositories for adherence to security best practices. If Allstar detects a security policy violation, it creates an issue to alert the repository or organization owner. For some security policies, Allstar can also automatically change the project setting that caused the violation, reverting it to the expected state.
Allstar’s goal is to give you finely tuned control over the files and settings that affect the security of your projects. You can choose which security policies to monitor at both the organization and repository level, and how to handle policy violations. You can also develop or contribute new policies.
Currently, Allstar meets as part of the Scorecard meetings
A project's criticality score defines the influence and importance of a project. It is a number between 0 (least-critical) and 1 (most-critical). It is based on the following algorithm by Rob Pike:
We have the Goals
- Generate a criticality score for every open source project.
- Create a list of critical projects that the open source community depends on.
- Use this data to proactively improve the security posture of these critical projects.
Currently, Criticality Score meets as part of the Securing Critical Projects Work Group. Join us every other Thursday.
The Package Analysis project analyses the capabilities of packages available on open source repositories. The project looks for behaviors that indicate malicious software:
- What files do they access?
- What addresses do they connect to?
- What commands do they run?
The project also tracks changes in how packages behave over time, to identify when previously safe software begins acting suspiciously.
This effort is meant to improve the security of open source software by detecting malicious behavior, informing consumers selecting packages, and providing researchers with data about the ecosystem.
This code is designed to work with the Package Feeds project, and originally started there.
If you want to get involved or have ideas you'd like to chat about, we discuss this project in the OSSF Securing Critical Projects Working Group meetings.
We help identify the best practices for Free/Libre and Open Source Software (FLOSS) and implement a badging system for those best practices. The "BadgeApp" badging system is a simple web application that lets projects self-certify that they meet the criteria and show a badge. The real goal of this project is to encourage projects to apply best practices, and to help users determine which FLOSS projects do so. We believe that FLOSS projects that implement best practices are more likely to produce better software, including more secure software.
See the OpenSSF Best Practices badge website if you want to try to get a badge.
Currently, we are not meeting but join us on the slack channel #wg_best_practices_ossdev to participate in the conversation!
HELP WANTED
We created OpenSSF Scorecard to help open source maintainers improve their security best practices and to help open source consumers judge whether their dependencies are safe.
OpenSSF Scorecard is an automated tool that assesses a number of essential heuristics ("checks") associated with software security and assigns each check a score of 0-10. You can use these scores to understand specific areas to improve in order to strengthen the security posture of your project. You can also assess the risks that dependencies introduce and make informed decisions about accepting these risks, evaluating alternative solutions, or working with the maintainers to make improvements.
Currently, we are meeting at many convenient times; Check the OpenSSF Google Calander for a time that fits your needs.
Fuzz introspector is a tool to help fuzzer developers to get an understanding of their fuzzer’s performance and identify any potential blockers. Fuzz introspector aggregates the fuzzers’ functional data like coverage, hit frequency, entry points, etc to give the developer a birds eye view of their fuzzer. This helps with identifying fuzz bottlenecks and blockers and eventually helps in developing better fuzzers.
Fuzz-introspector aims to improve fuzzing experience of a project by guiding on whether you should:
- introduce new fuzzers to a fuzz harness
- modify existing fuzzers to improve the quality of your harness.
We meet monthly on the first Tuesday, join in the conversation
We created OpenSSF Scorecard to help open source maintainers improve their security best practices and to help open source consumers judge whether their dependencies are safe.
OpenSSF Scorecard is an automated tool that assesses a number of essential heuristics ("checks") associated with software security and assigns each check a score of 0-10. You can use these scores to understand specific areas to improve in order to strengthen the security posture of your project. You can also assess the risks that dependencies introduce and make informed decisions about accepting these risks, evaluating alternative solutions, or working with the maintainers to make improvements.
Currently, we every other Wednesday; Check the OpenSSF Google Calander for a time that fits your needs. Or join us on the slack channel #sbomit to join the conversation.
Software supply chain attacks are on the rise and it’s hard to know what your software is at risk for and how to protect it. Many tools are available to help you generate Software Bills of Materials (SBOMs), signed attestations, and vulnerability reports, but they stop there, leaving you to figure out how they all fit together.
GUAC (Graph for Understanding Artifact Composition) aims to fill in the gaps by ingesting software metadata, like SBOMs, and mapping out relationships between software. When you know how one piece of software affects another, you’ll be able to fully understand your software security position and act as needed.
Currently, we have office hours and community meetings; Check the OpenSSF Google Calander for a time that fits your needs.
Or join us on the slack channel #guac to join the conversation.
gittuf provides a security layer for Git using some concepts introduced by The Update Framework (TUF). Among other features, gittuf handles key management for all developers on the repository, allows you to set permissions for repository branches, tags, files, etc., lets you use new cryptographic algorithms (SHA256, etc.), protects against other attacks Git is vulnerable to, and more — all while being backwards compatible with GitHub, GitLab, etc.
We meet on the first Friday of every month, or join us on the Slack channel #gittuf to talk.
HELP WANTED
Supply-chain Levels for Software Artifacts, or SLSA ("salsa").
It’s a security framework, a checklist of standards and controls to prevent tampering, improve integrity, and secure packages and infrastructure. It’s how you get from "safe enough" to being as resilient as possible, at any link in the chain.
We would love to have you join our slack channel #slsa-specification Also, every week on Monday, we meet on Zoom; join us next week! Check the OpenSSF Google Calander for the invite.
This is the repository for the Open Source Vulnerability schema (OSV Schema), which is currently exported by:
- AlmaLinux
- Bitnami Vulnerability Database
- Curl
- GitHub Security Advisories
- Global Security Database
- Go Vulnerability Database
- Haskell Security Advisories
- LoopBack Advisory Database
- OSS-Fuzz
- OSV.dev maintained converters (Debian, Alpine, NVD)
- PyPI Advisory Database
- Python Software Foundation Database
- RConsortium Advisory Database
- Rocky Linux
- Rust Advisory Database
- VMWare Photon OS (unofficial)
Currently, we are not meeting but join us on the slack channel #osv_schema to participate in the conversation!
Repository Service for TUF (RSTUF) is a collection of components that provide services for securing content downloads from tampering between the repository and the client (for example, by an on-path attacker).
RSTUF security properties are achieved by implementing The Update Framework (TUF) as a service.
Repository Service for TUF is platform, artifact, language, and process-flow agnostic.
RSTUF simplifies the adoption of TUF by removing the need to design a repository integration -- RSTUF encapsulates that design.
Repository Service for TUF (RSTUF) is designed to be integrated with existing content delivery solutions -- at the edge or in public/private clouds -- alongside current artifact production systems, such as build systems, including; Jenkins, GitHub Actions, GitLab, CircleCI, etc. RSTUF protects downloading, installing, and updating content from arbitrary content repositories, such as a web server, JFrog Artifactory, GitHub packages, etc.
Our community meetings are Monthly on the first Wednesday. Join us on the slack channel #repository-service-tuf to participate in the conversation!
The following projects are discussed at the work group level every other Wednesday. To join the meeting see theOpenSSF Community Calendar.
This specification provides a mechanism for projects to report information about their security in a machine-processable way. It is formatted as a YAML file to make it easy to read and edit by humans.
Values that are included within the specification may be required or optional. Optional values are recommendations from the Open Source Security Foundation's Identifying Security Threats Working Group, but may not be prudent for all use cases.
Example implementations can be found on the specification's GitHub repository.
A collection of unofficial supplemental tooling can be found in the "SI Tooling" GitHub Repository.
We are not seeking new members but improvement, suggestions and clarification requests can be logged as GitHub Issues, raised as discussion on Slack channel #security_insights.
To discuss live join the work group meeting.
The purpose of this project is to collect, organize, and provide interesting security metrics for open source projects to stakeholders, including users.
This project is in early development and we welcome community support.
To discuss live join the work group meeting.
Learn more at https://sigstore.dev/
We meet every 2 weeks on Tuesday
Coming soon
Alpha-Omega is an associated project of the OpenSSF, established in February 2022, funded by Microsoft, Google, and Amazon, and with a mission to protect society by catalyzing sustainable security improvements to the most critical open source software projects and ecosystems. The project aims to build a world where critical open source projects are secure and where security vulnerabilities are found and fixed quickly.
We meet on the first Wednesday of each month or join us on the slack channel #alpha_omega to participate in the conversation!
The OpenSSF Technical Advisory Council is responsible for oversight of the various Technical Initiatives (TI) of the OpenSSF.
We meet every other Tuesday 11:00a ET
Our Group Lead(s):
Special Interest Groups (SIGs):
- Secure Software Development Fundamentals
- Concise & Best Practices Guides
- Education
- Memory Safety
- Security Toolbelt
Projects:
- OpenSSF Best Practices Badge
- OpenSSF Scorecard
- Security Knowledge Framework 'SKF'
- Common Requirements Enumeration
Want to help drive open source security education or help develop best practices? We have a lot of projects and groups that are working towards these goals.
We meet None
Join us on Slack channel #wg_best_practices_ossdev
Our Group Lead(s):
Special Interest Groups (SIGs):
- Secure Software Development Fundamentals
- Security Knowledge Framework 'SKF'
- Common Requirements Enumeration
- Concise & Best Practices Guides
- Education
- Memory Safety
- Security Toolbelt
Projects:
We formed in September 2023 after the growing problem of AI/ML Security in open source. Join is to discuss the possible security impacts of AI / ML technologies on open source software, maintainers, communities, and their adopters, along with how OSS projects could safely or effectively leverage LLMs to improve their security posture.
We meet every other Monday 1:00p ET
Join us on Slack channel #wg_ai_ml_security
Our Group Lead(s):
We are improving the overall security of the OSS ecosystem by helping advance vulnerability reporting and communication.
We meet every other Wednesday 11:00a ET
Join us on Slack channel #wg_vulnerability_disclosures
Our Group Lead(s):
Special Interest Groups (SIGs):
Projects:
We formed in December 2023 to help increase representation and strengthen the overall effectiveness of the cybersecurity workforce.
We meet every other Tuesday 11:00a ET
Join us on Slack channel #wg_dei
Our Group Lead(s):
Special Interest Groups (SIGs):
- Secure Software Development Fundamentals
- Security Knowledge Framework 'SKF'
- Common Requirements Enumeration
- Concise & Best Practices Guides
- Education
- Memory Safety
- Security Toolbelt
Projects:
We represent the interests of public and private sector organizations that primarily consume open source rather than produce it. Right now, we are focusing on threat modeling. Join us to see how threat modeling works and get your ideas in the current scope.
We meet every Monday 12:30p ET
Join us on Slack channel #wg_end_users
Our Group Lead(s):
Special Interest Groups (SIGs):
Now called Metrics & Metadata! We enable informed confidence in the security of OSS by collecting, curating, and communicating relevant metrics and metadata. Our WG has mostly projects that focus on the code to get this done.
We meet every other Wednesday 1:00p ET
Join us on Slack channel #wg_identifying_security_threats
Our Group Lead(s):
Projects:
Our mission is to provide the best security tools for open source developers and make them universally accessible. We talk a lot about SBOMs currently.
We meet every other Friday 11:00a ET
Join us on Slack channel #wg_security_tooling
Our Group Lead(s):
Special Interest Groups (SIGs):
Projects:
We provide a collaborative environment for aligning on the introduction of new tools and technologies to strengthen and secure software repositories. Our current project is Repository Service for TUF, join to learn more.
We meet every 4 weeks on Wednesday at 6:00p ET and every 4 weeks on Thursday at 9:00pa ET
Join us on Slack channel #wg_securing_software_repos
Our Group Lead(s):
Projects:
We are helping people understand and make decisions on the provenance of the code they maintain, produce and use. We have great projects like GUAC, SLSA and gittuf that you can work with.
We meet every other Wednesday 12:00p ET
Join us on Slack channel #wg_supply_chain_integrity
Our Group Lead(s):
Special Interest Groups (SIGs):
Projects:
Wonder how critical OSS projects are selected? Then join us! We have progress reports every other week on each project/SIG so it is easy to jump in and get going.
We meet every 4 weeks on Thursday 12:00p ET
Join us on Slack channel #wg_securing_critical_projects
Our Group Lead(s):
Special Interest Groups (SIGs):
Projects: