On Tue, Feb 8, 2022 at 12:18 AM Brian Russell <[email protected]> wrote:
> Hello Security-Discuss, > > My name is Brian Russell and I work with the OpenSSF as part of Google’s > Open Source Security Team (GOSST). Our team was directed to this group by > Mark Cox (thank you!) and we believe that we have a vested interest in > bolstering the state of OSS security. After reading Mark’s summary of the > White House meeting (message to the group on 1/20/2022), I wanted to > elaborate on the OpenSSF’s Scorecards project and introduce a few other > projects that the team is also working on. We’d love to get ASF’s feedback > and want to work towards making our projects truly useful for projects > under Apache. > Thanks Brian. We've made a start on capturing some projects and initiatives on our wiki and have tried to thread in the OpenSSF projects that would be useful as best we could into those. Our next step would be to go through the list with a bit more detail around what each project would entail and pick ones that are the most pressing needs (for example, while SigStore looks promising, at the moment all ASF projects sign their code using our defined process, so it's not as urgent need as some of the others). Then see if we can find people that want to get involved and make those things happen (or if not how we can get help from OpenSSF community or others on those initiatives). Please take a look at where we've weaved in OpenSSF and update/suggest any addtions or changes or add detail: https://cwiki.apache.org/confluence/display/COMDEV/Brainstorm+Initiatives Cheers, Mark > OpenSSF Scorecards > > OpenSSF’s Scorecards project aims to bring security transparency to > consumers and maintainers of open source projects. From our GitHub page, > “we created Scorecards to give consumers of open-source projects an easy > way to judge whether their dependencies are safe” [1a]. The Scorecard > itself is a series of heuristics (we call them “checks”) to evaluate the > health of a project (e.g. does the project require peer-reviews, is the > project free from check-in binaries, etc.) [1b]. These checks form the > basis for an overall security score that offers a starting point for anyone > evaluating a project’s security practices (not unlike a product or business > review score which offers consumers a starting point to learn more). We’ve > seen adoption from several projects including: TensorFlow, Kubernetes, > Envoy, and Angular [1c]. > > OpenSSF and Google’s GOSST Vision > > Both OpenSSF and Google’s team share a common mission to strengthen OSS > security. Other projects that our team is actively developing include: > > > - > > SLSA: a security framework for the software development lifecycle. It > aims to create a straight-forward checklist that will prevent tampering, > improve integrity, and secure packages and infrastructure in software > projects [2a]. This framework has been adopted by projects like > Kubernetes > [2b]. > - > > OSS-Fuzz: infrastructure that surfaces vulnerabilities in critical open > source projects by applying fuzzing techniques [3] > - > > Allstar: a tool to help organization maintainers manage security across > Git repositories [4] > - > > OSV: a community-driven vulnerability database and format created > specifically for OSS projects. It aims to help both OSS maintainers and > consumers by consolidating vulnerability feeds from multiple sources > (e.g. > OSS-Fuzz, GitHub Security Advisories) and has been adopted by multiple > communities (e.g. PyPI, Go, Rust, GSD). The format is intended to be > simple > to read and was created to be more specific than other formats (i.e. > provides the ability to match vulnerabilities to specific version > ranges) > [5a][5b] > - > > Sigstore: a set of tools to facilitate artifact/binary signing and key > management [6] > > > > Today these projects are rapidly developing and have all launched features > targeting a subset of the longer-term problems. In addition to these > projects, our team will help to fund OSS developers to make these security > improvements. Our Alpha-Omega initiative aims to improve security for both > the most critical OSS projects (Alpha) and the long-tail (Omega) [7]. > Furthermore, we’ve sponsored a Secure Open Source (SOS) Rewards program > that directly rewards critical security improvements and fixes [8]. > > At this stage, we’d welcome your thoughts on where these are going and how > to make them most useful to projects within the governance of ASF. For each > project we hold regular community meetings that we believe would benefit > from your feedback. Also, we’d be happy to meet directly with anyone in > this group who would like to further discuss these projects. To directly > reach members of our team, we have a Google group that’s routed to all of > us: [email protected] > > Thank you again for inviting us into this group. > > Brian Russell (on behalf of Google’s Open Source Security Team) > > [1a] Scorecards project page: https://github.com/ossf/scorecard > > [1b] Full list of checks: > https://github.com/ossf/scorecard#scorecard-checks > > > [1c] Example: end-to-end Scorecards setup: > > https://blog.envoyproxy.io/security-scorecards-envoy-automating-supply-chain-analysis-7b8fd9829169 > > > [2a] SLSA project page: https://slsa.dev/ > > [2b] Kubernetes SLSA announcement: > > https://kubernetes.io/blog/2021/12/07/kubernetes-1-23-release-announcement/#software-supply-chain-slsa-level-1-compliance-in-the-kubernetes-release-process > > > [3] OSS-Fuzz project page: https://github.com/google/oss-fuzz > > [4] Allstar project page: https://github.com/ossf/allstar > > [5a] OSV project page: https://osv.dev/ > > [5b] OSV schemas supported: https://github.com/ossf/osv-schema > > [6] Sigstore project page: https://www.sigstore.dev/ > > [7] Alpha-Omega announcement: > > https://openssf.org/press-release/2022/02/01/openssf-announces-the-alpha-omega-project-to-improve-software-supply-chain-security-for-10000-oss-projects/ > > [8] SOS Rewards announcement: > > https://security.googleblog.com/2021/10/introducing-secure-open-source-pilot.html >
