4 |
5 | The S2C2F Project is a group working within the OpenSSF's Supply Chain Integrity Working Group formed to further develop and continuously improve the S2C2F guide which outlines and defines how to securely consume Open Source Software (OSS) dependencies into the developer’s workflow. This paper is split into two parts: a solution-agonistic set of practices and a maturity model-based implementation guide. The Framework is targeted toward organizations that do software development, that take a dependency on open source software, and that seek to improve the security of their software supply chain.
6 |
7 | ## Motivation
8 |
9 | OSS has become a critical aspect of any software supply chain. The S2C2F was designed based on known threats (i.e. tactics and techniques) used by adversaries to compromise OSS packages. By leveraging the framework, software development teams and organizations can securely consume OSS dependencies into the developer's workflow and enhance their OSS governance program to address threats specific to OSS consumption.
10 |
11 | ## Objective
12 |
13 | The objective for the S2C2F Project is to develop and continuously improve upon a guide that provides the following:
14 |
15 | * A high-level solution-agnostic set of practices
16 | * A detailed list of requirements
17 | * A list of real-world supply chain threats specific to OSS, and how our Framework requirements mitigates them
18 | * A maturity model-based implementation guide, with links to tools from across the industry
19 | * A process for assessing your organization’s maturity
20 | * A mapping of the Framework requirements to 6 other supply chain specifications
21 |
22 | ## View or Download the S2C2F Specification
23 |
24 | :atom:: **Click _[here](./specification/framework.md)_ to view the specification in markdown**
25 |
26 | To learn more, the S2C2F FAQ is available [here](./FAQ.md).
27 |
28 | ## Get Involved
29 |
30 | * Official communications occur on the [openssf-sig-s2c2f@lists.openssf.org](https://lists.openssf.org/g/openssf-sig-s2c2f). \
31 | [Manage your subscriptions to Open SSF mailing lists](https://lists.openssf.org/g/main/subgroups).
32 | * [S2C2F Project Slack](https://openssf.slack.com/archives/C03THTH3RSM)
33 | * [Supply Chain Integrity WG Slack](https://openssf.slack.com/archives/C01A1MA7A1K)
34 |
35 | ### Quick Start
36 |
37 | * File issues in the [Issues page](https://github.com/ossf/s2c2f/issues)
38 | * We are actively seeking contributions to our [Reference Implementations](./Reference_implementation)
39 |
40 | ### Meeting times
41 |
42 | * Every other Tuesday @ 12:00pm PST The invite is available on the [OpenSSF Community Calendar](https://calendar.google.com/calendar/u/0/r?cid=czYzdm9lZmhwNWk5cGZsdGI1cTY3bmdwZXNAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ)
43 | * [Meeting Minutes](https://docs.google.com/document/d/10Q_VOvKsGaYJoK-5yJY4868mTkYZjEo-6xV6ghYS84k/edit)
44 |
45 | # Governance
46 |
47 | The [GOVERNANCE.md](https://github.com/ossf/s2c2f/blob/main/governance/Governance.md) outlines the scope and governance of our group activities.
48 |
49 | * Lead: Adrian Diglio (https://github.com/adriandiglio)
50 | * Co-Lead: Jay White (https://github.com/camaleon2016)
51 |
52 | ## Steering Committee
53 | - [Jay White, Microsoft](https://github.com/camaleon2016)
54 | - [Adrian Diglio, Microsoft](https://github.com/adriandiglio)
55 |
56 | ## Project Maintainers
57 | - [Jay White, Microsoft](https://github.com/camaleon2016)
58 | - [Adrian Diglio, Microsoft](https://github.com/adriandiglio)
59 | - [Jasmine Wang, Microsoft](https://github.com/jasminewang0)
60 | - [Tom Bedford, Bloomberg](https://github.com/tombedfordgit)
61 |
62 |
63 | ## Project Collaborators
64 | - [Christopher "CRob" Robinson, Intel](https://github.com/SecurityCRob)
65 | - [David A Wheeler, LF/OSSF](https://github.com/david-a-wheeler)
66 |
--------------------------------------------------------------------------------
/Reference_implementation/GitLab.md:
--------------------------------------------------------------------------------
1 | # Suggested Reference Implementation for GitLab open source projects
2 |
3 | The goal of this document is to show how far a GitLab project can get using as much native tooling as possible toward achieving up to maturity level 3 for the Secure Supply Chain Consumption Framework (S2C2F).
4 |
5 | The community helps maintain these suggested methods of implementing the requirements, and will be updated over time.
6 |
7 | | Requirement ID | Requirement Title | Maturity Level | Reference Implementation in GitLab |
8 | | --- | --- | --- | --- |
9 | | ING-1 | Use public package managers trusted by your organization | L1 | Ex. npmjs.org, DockerHub |
10 | | ING-2 | Use an OSS binary repository manager solution | L1 | GitLab [Package Registry](https://docs.gitlab.com/ee/user/packages/package_registry/index.html) or [Container Registry](https://docs.gitlab.com/ee/user/packages/container_registry/) |
11 | | ING-3 | Have a Deny List capability to block known malicious OSS from being consumed | L3 | Not Available |
12 | | ING-4 | Mirror a copy of all OSS source code to an internal location | L3 | N/A. This requirement is geared toward large development teams |
13 | | SCA-1 | Scan OSS for known vulnerabilities | L1 | GitLab [Dependency Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/) and [Container Scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/index.html) |
14 | | SCA-2 | Scan OSS for licenses | L1 | GitLab [License compliance](https://docs.gitlab.com/ee/user/compliance/license_compliance/index.html) |
15 | | SCA-3 | Scan OSS to determine if its end-of-life | L2 | [OpenSSF Scorecard](https://github.com/ossf/scorecard) - actively maintained (inactivity for X years). Security Insights (Luigi) |
16 | | SCA-4 | Scan OSS for malware | L3 | [OpenSSF Package Analysis](https://github.com/ossf/package-analysis) |
17 | | SCA-5 | Perform proactive security review of OSS | L3 | Proactive security scans will be done out-of-band from a build. Usually it's an action that can be taken on cloned source |
18 | | INV-1 | Maintain an automated inventory of all OSS used in development | L1 | GitLab [Dependency list](https://docs.gitlab.com/ee/user/application_security/dependency_list/) |
19 | | INV-2 | Have an OSS Incident Response Plan | L2 | Write one - be focused on how to roll back versions of OSS |
20 | | UPD-1 | Update vulnerable OSS manually | L1 | |
21 | | UPD-2 | Enable automated OSS updates | L2 | [Renovate](https://github.com/renovatebot/renovate) |
22 | | UPD-3 | Display OSS vulnerabilities as comments in Pull Requests (PRs) | L2 | Leverage a [custom Scan Result Policy](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html) that requires a reviewer to approve |
23 | | AUD-1 | Verify the provenance of your OSS | L3 | Repo it came from and commit hash from where it came. GitBOM? SBOM? |
24 | | AUD-2 | Audit that developers are consuming OSS through the approved ingestion method | L2 | An index methodology to identify the OSS code undeclared. Searching for Copyright and != your company name |
25 | | AUD-3 | Validate integrity of the OSS that you consume into your build | L2 | This is usually performed by the language package client |
26 | | AUD-4 | Validate SBOMs of OSS that you consume into your build | L4 | |
27 | | ENF-1 | Securely configure your package source files (i.e. nuget.config, .npmrc, pip.conf, pom.xml, etc.) | L2 | https://azure.microsoft.com/en-us/resources/3-ways-to-mitigate-risk-using-private-package-feeds/ |
28 | | ENF-2 | Enforce usage of a curated OSS feed that enhances the trust of your OSS | L3 | Enforce that “OpenSSF Package Analysis” was run via GitLab [Scan Execution Policies](https://docs.gitlab.com/ee/user/application_security/policies/scan-execution-policies.html) |
29 | | REB-1 | Rebuild the OSS in a trusted build environment, or validate that it is reproducibly built | L4 | Vet or validate tools that you use in your pipeline. This accounts for closed source scenarios as well. |
30 | | REB-2 | Digitally sign the OSS you rebuild | L4 | |
31 | | REB-3 | Generate SBOMs for OSS that you rebuild | L4 | |
32 | | REB-4 | Digitally sign the SBOMs you produce | L4 | |
33 | | FIX-1 | Implement a change in the code to address a zero-day vulnerability, rebuild, deploy to your organization, and confidentially contribute the fix to the upstream maintainer | L4 | |
34 |
35 |
36 |
37 |
--------------------------------------------------------------------------------
/Reference_implementation/GitHub.md:
--------------------------------------------------------------------------------
1 | # Suggested Reference Implementation for GitHub open source projects
2 |
3 | The goal of this document is to show how far a GitHub project can get using as much native tooling as possible toward achieving up to maturity level 3 for the Secure Supply Chain Consumption Framework (S2C2F).
4 |
5 | The community helps maintain these suggested methods of implementing the requirements, and will be updated over time.
6 |
7 | | Requirement ID | Requirement Title | Maturity Level | Reference Implementation in GitHub |
8 | | --- | --- | --- | --- |
9 | | ING-1 | Use public package managers trusted by your organization | L1 | Ex. npmjs.org, DockerHub |
10 | | ING-2 | Use an OSS binary repository manager solution | L1 | GitHub Packages |
11 | | ING-3 | Have a Deny List capability to block known malicious OSS from being consumed | L3 | a Deny list can be achieved through [Dependency Review action](https://josh-ops.com/posts/dependency-review-action/). You must create a branch protection rule for your default branch, and select "Require status checks to pass before merging" box. If a component has vulnerabilities, this part of the build will fail. And GitHub now auto-creates CVEs for malicious components, so this is in-effect your Deny List. |
12 | | ING-4 | Mirror a copy of all OSS source code to an internal location | L3 | [Duplicate a repository](https://docs.github.com/en/repositories/creating-and-managing-repositories/duplicating-a-repository) |
13 | | SCA-1 | Scan OSS for known vulnerabilities | L1 | Recommend using [GitHub dependency graph](https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/about-the-dependency-graph) for your repo for scanning vulns |
14 | | SCA-2 | Scan OSS for licenses | L1 | Recommend configuring [Dependency Review](https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/configuring-dependency-review#configuring-the-dependency-review-github-action) for license management |
15 | | SCA-3 | Scan OSS to determine if its end-of-life | L2 | [OpenSSF Scorecard](https://github.com/ossf/scorecard) - actively maintained (inactivity for X years). Security Insights (Luigi) |
16 | | SCA-4 | Scan OSS for malware | L3 | [OpenSSF Package Analysis](https://github.com/ossf/package-analysis) |
17 | | SCA-5 | Perform proactive security review of OSS | L3 | Proactive security scans will be done out-of-band from a build. Usually it's an action that can be taken on cloned source |
18 | | INV-1 | Maintain an automated inventory of all OSS used in development | L1 | [GitHub Dependency Graph](https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/about-the-dependency-graph) |
19 | | INV-2 | Have an OSS Incident Response Plan | L2 | Write one - be focused on how to roll back versions of OSS |
20 | | UPD-1 | Update vulnerable OSS manually | L1 | |
21 | | UPD-2 | Enable automated OSS updates | L2 | [Dependabot](https://docs.github.com/en/code-security/dependabot/dependabot-alerts/about-dependabot-alerts) |
22 | | UPD-3 | Display OSS vulnerabilities as comments in Pull Requests (PRs) | L2 | [Dependency Review](https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/about-dependency-review) via [GHAS](https://docs.github.com/en/enterprise-server@3.4/get-started/learning-about-github/about-github-advanced-security) |
23 | | AUD-1 | Verify the provenance of your OSS | L3 | Repo it came from and commit hash from where it came. GitBOM? SBOM? |
24 | | AUD-2 | Audit that developers are consuming OSS through the approved ingestion method | L2 | An index methodology to identify the OSS code undeclared. Searching for Copyright and != your company name |
25 | | AUD-3 | Validate integrity of the OSS that you consume into your build | L2 | This is usually performed by the language package client |
26 | | AUD-4 | Validate SBOMs of OSS that you consume into your build | L4 | |
27 | | ENF-1 | Securely configure your package source files (i.e. nuget.config, .npmrc, pip.conf, pom.xml, etc.) | L2 | https://azure.microsoft.com/en-us/resources/3-ways-to-mitigate-risk-using-private-package-feeds/ |
28 | | ENF-2 | Enforce usage of a curated OSS feed that enhances the trust of your OSS | L3 | Enforce a [branch protection rule](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests) to enforce that “OpenSSF Package Analysis” was run |
29 | | REB-1 | Rebuild the OSS in a trusted build environment, or validate that it is reproducibly built | L4 | |
30 | | REB-2 | Digitally sign the OSS you rebuild | L4 | |
31 | | REB-3 | Generate SBOMs for OSS that you rebuild | L4 | |
32 | | REB-4 | Digitally sign the SBOMs you produce | L4 | |
33 | | FIX-1 | Implement a change in the code to address a zero-day vulnerability, rebuild, deploy to your organization, and confidentially contribute the fix to the upstream maintainer | L4 | |
34 |
--------------------------------------------------------------------------------
/Contributing.md:
--------------------------------------------------------------------------------
1 | # Community Specification Contribution Policy 1.0
2 |
3 | This document provides the contribution policy for specifications and other documents developed using the Community Specification process in a repository (each a “Working Group”). Additional or alternate contribution policies may be adopted and documented by the Working Group.
4 |
5 | ## 1. Contribution Guidelines.
6 |
7 | This Working Group accepts contributions via pull requests. The following section outlines the process for merging contributions to the specification
8 |
9 | **1.1. Issues.** Issues are used as the primary method for tracking anything to do with this specification Working Group.
10 |
11 | **1.1.1. Issue Types.** There are three types of issues (each with their own corresponding label):
12 |
13 | **1.1.1.1. Discussion.** These are support or functionality inquiries that we want to have a record of for future reference. Depending on the discussion, these can turn into "Spec Change" issues.
14 |
15 | **1.1.1.2. Proposal.** Used for items that propose a new ideas or functionality that require a larger discussion. This allows for feedback from others before a specification change is actually written. All issues that are proposals should both have a label and an issue title of "Proposal: [the rest of the title]." A proposal can become a "Spec Change" and does not require a milestone.
16 |
17 | **1.1.1.3. Spec Change:** These track specific spec changes and ideas until they are complete. They can evolve from "Proposal" and "Discussion" items, or can be submitted individually depending on the size. Each spec change should be placed into a milestone.
18 |
19 | ## 2. Issue Lifecycle.
20 |
21 | The issue lifecycle is mainly driven by the Maintainer. All issue types follow the same general lifecycle. Differences are noted below.
22 |
23 | **2.1. Issue Creation.**
24 |
25 | **2.2. Triage.**
26 |
27 | o The Editor in charge of triaging will apply the proper labels for the issue. This includes labels for priority, type, and metadata.
28 |
29 | o (If needed) Clean up the title to succinctly and clearly state the issue. Also ensure that proposals are prefaced with "Proposal".
30 |
31 | **2.3. Discussion.**
32 |
33 | o "Spec Change" issues should be connected to the pull request that resolves it.
34 |
35 | o Whoever is working on a "Spec Change" issue should either assign the issue to themselves or make a comment in the issue saying that they are taking it.
36 |
37 | o "Proposal" and "Discussion" issues should stay open until resolved.
38 |
39 | **2.4. Issue Closure.**
40 |
41 | ## 3. How to Contribute a Patch.
42 |
43 | The Working Group uses pull requests to track changes. To submit a change to the specification:
44 |
45 | **3.1 Fork the Repo, modify the Specification to Address the Issue.**
46 |
47 | **3.2. Submit a Pull Request.**
48 |
49 | ## 4. Pull Request Workflow.
50 |
51 | The next section contains more information on the workflow followed for Pull Requests.
52 |
53 | **4.1. Pull Request Creation.**
54 |
55 | o We welcome pull requests that are currently in progress. They are a great way to keep track of important work that is in-flight, but useful for others to see. If a pull request is a work in progress, it should be prefaced with "WIP: [title]". You should also add the wip label Once the pull request is ready for review, remove "WIP" from the title and label.
56 |
57 | o It is preferred, but not required, to have a pull request tied to a specific issue. There can be circumstances where if it is a quick fix then an issue might be overkill. The details provided in the pull request description would suffice in this case.
58 |
59 | **4.2. Triage**
60 |
61 | o The Editor in charge of triaging will apply the proper labels for the issue. This should include at least a size label, a milestone, and awaiting review once all labels are applied.
62 |
63 | **4.3. Reviewing/Discussion.**
64 |
65 | o All reviews will be completed using the review tool.
66 |
67 | o A "Comment" review should be used when there are questions about the spec that should be answered, but that don't involve spec changes. This type of review does not count as approval.
68 |
69 | o A "Changes Requested" review indicates that changes to the spec need to be made before they will be merged.
70 |
71 | o Reviewers should update labels as needed (such as needs rebase).
72 |
73 | o When a review is approved, the reviewer should add LGTM as a comment.
74 |
75 | o Final approval is required by a designated Editor. Merging is blocked without this final approval. Editors will factor reviews from all other reviewers into their approval process.
76 |
77 | **4.4. Responsive.** Pull request owner should try to be responsive to comments by answering questions or changing text. Once all comments have been addressed, the pull request is ready to be merged.
78 |
79 | **4.5. Merge or Close.**
80 |
81 | o A pull request should stay open until a Maintainer has marked the pull request as approved.
82 |
83 | o Pull requests can be closed by the author without merging.
84 |
85 | o Pull requests may be closed by a Maintainer if the decision is made that it is not going to be merged.
86 |
--------------------------------------------------------------------------------
/Code of Conduct.md:
--------------------------------------------------------------------------------
1 | # Contributor Covenant Code of Conduct
2 |
3 | ## Our Pledge
4 |
5 | We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.
6 |
7 | We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.
8 |
9 | ## Our Standards
10 |
11 | Examples of behavior that contributes to a positive environment for our community include:
12 |
13 | * Demonstrating empathy and kindness toward other people
14 | * Being respectful of differing opinions, viewpoints, and experiences
15 | * Giving and gracefully accepting constructive feedback
16 | * Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience
17 | * Focusing on what is best not just for us as individuals, but for the overall community
18 |
19 | Examples of unacceptable behavior include:
20 |
21 | * The use of sexualized language or imagery, and sexual attention or advances of any kind
22 | * Trolling, insulting or derogatory comments, and personal or political attacks
23 | * Public or private harassment
24 | * Publishing others' private information, such as a physical or email address, without their explicit permission
25 | * Other conduct which could reasonably be considered inappropriate in a professional setting
26 |
27 | ## Enforcement Responsibilities
28 |
29 | Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful.
30 |
31 | Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate.
32 |
33 | ## Scope
34 |
35 | This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event.
36 |
37 | ## Enforcement
38 |
39 | Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement as set forth in the repository's Notices.md file. All complaints will be reviewed and investigated promptly and fairly.
40 |
41 | All community leaders are obligated to respect the privacy and security of the reporter of any incident.
42 |
43 | ## Enforcement Guidelines
44 |
45 | Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct:
46 |
47 | ### 1. Correction
48 |
49 | **Community Impact**: Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community.
50 |
51 | **Consequence**: A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested.
52 |
53 | ### 2. Warning
54 |
55 | **Community Impact**: A violation through a single incident or series of actions.
56 |
57 | **Consequence**: A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.
58 |
59 | ### 3. Temporary Ban
60 |
61 | **Community Impact**: A serious violation of community standards, including sustained inappropriate behavior.
62 |
63 | **Consequence**: A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.
64 |
65 | ### 4. Permanent Ban
66 |
67 | **Community Impact**: Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals.
68 |
69 | **Consequence**: A permanent ban from any sort of public interaction within the project community.
70 |
71 | ## Attribution
72 |
73 | This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 2.0,
74 | available at https://www.contributor-covenant.org/version/2/0/code_of_conduct.html.
75 |
76 | Community Impact Guidelines were inspired by [Mozilla's code of conduct enforcement ladder](https://github.com/mozilla/diversity).
77 |
78 | [homepage]: https://www.contributor-covenant.org
79 |
80 | For answers to common questions about this code of conduct, see the FAQ at
81 | https://www.contributor-covenant.org/faq. Translations are available at https://www.contributor-covenant.org/translations.
82 |
--------------------------------------------------------------------------------
/FAQ.md:
--------------------------------------------------------------------------------
1 | # Frequently Asked Questions
2 |
3 | Below are some frequently asked questions regarding the Framework. If you have further questions, feel free to start a discussion by opening an [Issue](https://github.com/ossf/s2c2f/issues).
4 |
5 | - [What is the Secure Supply Chain Consumption Framework (S2C2F)?](#what-is-the-secure-supply-chain-consumption-framework-s2c2f)
6 | - [What does this Framework focus on securing?](#what-does-this-framework-focus-on-securing)
7 | - [How do you define OSS?](#how-do-you-define-OSS)
8 | - [Why should I use the S2C2F?](#why-should-i-use-the-s2c2f)
9 | - [What is this Framework not?](#what-is-this-framework-not)
10 | - [Why is this Framework focused on open source?](#why-is-this-framework-focused-on-open-source)
11 | - [How does this Framework relate to other supply chain security specifications like SLSA?](#how-does-this-framework-relate-to-other-supply-chain-security-specifications-like-slsa)
12 | - [What is the difference between the SCA-5 and FIX-1 requirements?](#what-is-the-difference-between-the-SCA-5-and-FIX-1-requirements)
13 | - [Is the SCA-3 requirement only about the end of an open source project, or is it also about the end of support of a branch in the project used by a product?](#is-the-sca-3-requirement-only-about-the-end-of-an-open-source-project-or-is-it-also-about-the-end-of-support-of-a-branch-in-the-project-used-by-a-product)
14 | - [Is the UPD-3 requirement to add a reference to the known vulnerabilities in the pull requests intending to fix these vulnerabilities? What is the "Two-person PR reviews are enforced" prerequisite?](#is-the-upd-3-requirement-to-add-a-reference-to-the-known-vulnerabilities-in-the-pull-requests-intending-to-fix-these-vulnerabilities-what-is-the-two-person-pr-reviews-are-enforced-prerequisite)
15 | - [Is the ENF-1 requirement about properly configuring the allowed repositories into package managers?](#is-the-enf-1-requirement-about-properly-configuring-the-allowed-repositories-into-package-managers)
16 |
17 | ## About the framework
18 |
19 | ### What is the Secure Supply Chain Consumption Framework (S2C2F)?
20 | The S2C2F is a combination of processes and tools for any organization to adopt to help establish a secure OSS ingestion process to protect developers from OSS Supply Chain threats and to help establish a governance program to manage your organization’s use of OSS. The framework is based on three core concepts: control all artifact inputs, continuous process improvement, and scale.
21 |
22 | ### What does this Framework focus on securing?
23 | This framework focuses on securing OSS dependencies like PyPI, Maven, NuGet, npm, etc. The implementation guide does not apply to containers, but the 8 high level practices do. For further container guidance, please refer to the [Cloud Native Computing Foundation (CNCF) projects](https://www.cncf.io/projects/).
24 |
25 | ### How do you define OSS?
26 | Open Source Software, as adopted from [The Free Software Definition](https://en.wikipedia.org/wiki/The_Free_Software_Definition), is software that ensures that the end users have freedom in using, studying, sharing and modifying that software. For more details about the definition of Open Source Software (OSS), see [The Open Source Definition](https://opensource.org/osd/).
27 |
28 | ### Why should I use the S2C2F?
29 | Our framework provides the support and implementation guidance to protect your supply chains and prevent open source software threats from compromising your organization’s software and development environment. The framework includes solution-agonistic practices – suited for individuals like compliance/risk managers, security managers, engineering managers, and Chief Information Security Officers – plus an implementation guide with recommended tooling – suited for software developers, Continuous Integration and Continuous Development administrators, and security practitioners.
30 |
31 | ### What is this Framework not?
32 | The S2C2F does not provide guidance on how to secure your DevOps workflows, how to secure your build infrastructure, how to secure the code you author, or how to secure your containers.
33 |
34 | ### Why is this Framework focused on open source?
35 | Across the software industry today, developers are using and relying upon OSS components to expedite developer productivity and innovation – which makes OSS a critical piece of any software’s supply chain. However, cyberattacks that specifically target open source are growing at an exponential rate, as they are trying to abuse these package manager ecosystems to either distribute their own malicious components or to compromise existing OSS components.
36 |
37 | ### How does this Framework relate to other supply chain security specifications like SLSA?
38 | The S2C2F is focused on securely consuming OSS and makes an excellent bridge to other producer-focused supply chain security frameworks, such as SLSA.
39 |
40 | ## Requirements
41 |
42 | ### What is the difference between the SCA-5 and FIX-1 requirements?
43 | `SCA-5: Perform proactive security review of OSS - Identify zero-day vulnerabilities and confidentially contribute fixes back to the upstream maintainer.`
44 |
45 | SCA-5 requirement is simply that your organization is performing proactive security reviews of OSS and helping improve the security of the entire ecosystem by partnering with the upstream maintainer (confidentially - outside of public GitHub issues via [private security notifications](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing/privately-reporting-a-security-vulnerability)) and suggesting a fix.
46 |
47 | `FIX-1: Implement a change in the code to address a zero-day vulnerability, rebuild, deploy to your organization, and confidentially contribute the fix to the upstream maintainer - To be used only in extreme circumstances when the risk is too great and to be used temporarily until the upstream maintainer issues a fix.`
48 |
49 | FIX-1 is when you come across a zero-day vulnerability that is so severe that your organization feels that they can't wait for the upstream maintainer to issue a public fix. The only other action would be to implement a private fix (just for your team/organization) while you continue trying to partner with the upstream maintainer on a public fix. A private fix should always be considered a temporary risk reduction measure for extreme circumstances, as your team/organization should plan to convert to the public fix once available.
50 |
51 | ### Is the SCA-3 requirement only about the end of an open source project, or is it also about the end of support of a branch in the project used by a product?
52 |
53 | Scanning for end of support entails scanning for all of the above to understand if anything consumed is no longer supported. Consumers of open source may want to know if a product is no longer supported or even if a specific version range is unsupported. The point is to identify if anything consumed is no longer supported. It is vital to know if any dependency is unsupported as this can create gaps in security since dependencies won't get patched and attackers can take advantage of the lack of support.
54 |
55 | ### Is the UPD-3 requirement to add a reference to the known vulnerabilities in the pull requests intending to fix these vulnerabilities? What is the "Two-person PR reviews are enforced" prerequisite?
56 |
57 | Including references to known vulnerabilities in pull requests prevents vulnerabilities from being unknowingly introduced earlier in the DevOps lifecycle. This requirement should be exercised when a developer adds new dependencies at pull request time. The prerequisite of "two-person PR reviews" means that manual pull request reviews are conducted by at least one reviewer separate from the person the developed the code so that they see and remediate the vulnerabilities prior to approving and merging the pull request.
58 |
59 | ### Is the ENF-1 requirement about properly configuring the allowed repositories into package managers?
60 |
61 | ENF-1 is about hardening package source file configuration to prevent mix-and-match attacks through dependencies being sourced from multiple registries or otherwise not using the expected version. How to do it varies by environment (OSS developer, indie, enterprise) and ecosystem (Python, npm, etc).
62 |
--------------------------------------------------------------------------------
/governance/Governance.md:
--------------------------------------------------------------------------------
1 | # Community Specification Governance Policy 1.0
2 |
3 | This document provides the governance policy for specifications and other documents developed using the Community Specification process in a repository (each a “Working Group”). Each Working Group and must adhere to the requirements in this document.
4 |
5 | ## 1. Roles.
6 |
7 | Each Working Group may include the following roles. Additional roles may be adopted and documented by the Working Group.
8 |
9 | **1.1. Maintainer.** "Maintainers" are responsible for organizing activities around developing, maintaining, and updating the specification(s) and other assets developed by the Project. Maintainers are also responsible for determining consensus and coordinating appeals. Examples of the responsibility of a Maintainer (directly or by delegation) include:
10 |
11 | 
2 |
3 | # Secure Supply Chain Consumption Framework (S2C2F) Simplified Requirements
4 |
5 | This document is provided "as-is." Information and views expressed in this document, including URL and other Internet Web site references, may change without notice. You bear the risk of using it.
6 |
7 | Some examples depicted herein are provided for illustration only and are fictitious. No real association or connection is intended or should be inferred.
8 |
9 | This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes.
10 |
11 | Licensed under [Community Specification License 1.0](https://github.com/CommunitySpecification/1.0)
12 |
13 | # Table of Contents
14 |
15 | - [Secure Supply Chain Consumption Framework (S2C2F) Simplified Requirements](#secure-supply-chain-consumption-framework-s2c2f-simplified-requirements)
16 | - [Table of Contents](#table-of-contents)
17 | - [Document Change Record](#document-change-record)
18 | - [Introduction](#introduction)
19 | - [About the Secure Supply Chain Consumption Framework](#about-the-secure-supply-chain-consumption-framework)
20 | - [What is the Secure Supply Chain Consumption Framework?](#what-is-the-secure-supply-chain-consumption-framework)
21 | - [Common OSS Supply Chain Threats](#common-oss-supply-chain-threats)
22 | - [Secure Supply Chain Consumption Framework Practices](#secure-supply-chain-consumption-framework-practices)
23 | - [Target Audience](#target-audience)
24 | - [Secure Supply Chain Consumption Framework Practices](#secure-supply-chain-consumption-framework-practices-1)
25 | - [_Practice 1: Ingest It_](#practice-1-ingest-it)
26 | - [_Practice 2: Scan It_](#practice-2-scan-it)
27 | - [_Practice 3: Inventory It_](#practice-3-inventory-it)
28 | - [_Practice 4: Update It_](#practice-4-update-it)
29 | - [_Practice 5: Audit It_](#practice-5-audit-it)
30 | - [_Practice 6: Enforce It_](#practice-6-enforce-it)
31 | - [_Practice 7: Rebuild It_](#practice-7-rebuild-it)
32 | - [_Practice 8: Fix It + Upstream_](#practice-8-fix-it--upstream)
33 | - [The Secure Supply Chain Consumption Framework Implementation Guide](#the-secure-supply-chain-consumption-framework-implementation-guide)
34 | - [Target Audience](#target-audience-1)
35 | - [Secure Supply Chain Consumption Framework Levels of Maturity](#secure-supply-chain-consumption-framework-levels-of-maturity)
36 | - [How to Assess Where Your Organization is in the Maturity Model?](#how-to-assess-where-your-organization-is-in-the-maturity-model)
37 | - [Secure Supply Chain Consumption Framework Requirements](#secure-supply-chain-consumption-framework-requirements)
38 | - [Secure Supply Chain Consumption Framework Tooling Availability](#secure-supply-chain-consumption-framework-tooling-availability)
39 | - [Implementing the Secure Supply Chain Consumption Framework by Level](#implementing-the-secure-supply-chain-consumption-framework-by-level)
40 | - [Conclusion](#conclusion)
41 | - [Appendix: Relation to SCITT](#appendix-relation-to-scitt)
42 | - [Appendix: Mapping Secure Supply Chain Consumption Framework Requirements to Other Specifications](#appendix-mapping-secure-supply-chain-consumption-framework-requirements-to-other-specifications)
43 | - [Appendix: References](#appendix-references)
44 |
45 | # Document Change Record
46 |
47 | | Date | Author | Version | Change Reference |
48 | | --- | --- | --- | --- |
49 | | 8/1/2022 | Adrian Diglio (Microsoft) | 1.0 | Initial release |
50 | | 10/19/2022 | Jasmine Wang (Microsoft) | 1.1 | Resolving issues [#5](https://github.com/microsoft/oss-ssc-framework/issues/5), [#6](https://github.com/microsoft/oss-ssc-framework/issues/6), [#7](https://github.com/microsoft/oss-ssc-framework/issues/7), [#9](https://github.com/microsoft/oss-ssc-framework/issues/9), [#1](https://github.com/ossf/s2c2f/issues/1). Replaced references to "Microsoft OSS SSC Framework" with "Secure Supply Chain Consumption Framework." |
51 |
52 | # Introduction
53 |
54 | The purpose of this paper is to illustrate the core concepts of the Secure Supply Chain Consumption Framework (S2C2F) to outline and define how to securely consume OSS dependencies, such as NuGet and NPM, into the developer's workflow. Open Source Software, as adopted from [The Free Software Definition](https://en.wikipedia.org/wiki/The_Free_Software_Definition), is software that ensures that the end users have freedom in using, studying, sharing and modifying that software. For more details about the definition of Open Source Software (OSS), see [The Open Source Definition](https://opensource.org/osd). This framework is applicable to OSS dependencies consumed into the developer's workflow, such as any source code, language package, module, component, container, library, or binary. This guide provides a dedicated framework to enhance any organization's OSS governance program to address supply chain threats specific to OSS consumption.
55 |
56 | OSS has become a critical aspect of any software supply chain. Across the software industry, developers are using and relying upon OSS components to expedite developer productivity and innovation. However, attackers are trying to abuse these package manager ecosystems to either distribute their own malicious components, or to compromise existing OSS components.
57 |
58 | This paper is split into two parts: a solution-agonistic set of practices and a maturity model-based implementation guide. The practices section should be utilized by individuals like Chief Information Security Officers (CISOs) and security, engineering, compliance/risk managers while the implementation guide should be utilized by software developers and other security practitioners.
59 |
60 | This paper presents:
61 |
62 | - An overview of the Secure Supply Chain Consumption Framework (S2C2F) Practices.
63 | - Common supply chain threats with examples and how the S2C2F can help.
64 | - An overview of the S2C2F Implementation Guide and Maturity Model.
65 | - A process for assessing your organization's maturity.
66 | - Detailed walkthrough of the S2C2F implementation requirements and tools.
67 | - A mapping of the S2C2F requirements to other specifications.
68 |
69 | The guidance provided in this paper is targeted toward organizations that do software development, that take a dependency on open source software, and that seek to improve the security of their software supply chain.
70 |
71 | # About the Secure Supply Chain Consumption Framework
72 |
73 | The Secure Supply Chain Consumption Framework (S2C2F) is a security assurance and risk reduction process that is focused on securing how developers consume open source software. As an initiative widely used across Microsoft since 2019, the S2C2F provides security guidance and tools throughout the developer inner-loop and outer-loop processes that have played a critical role in defending and preventing supply chain attacks through consumption of open source software. Using a threat-based risk-reduction approach, the goals of the S2C2F are to:
74 |
75 | 1. Provide a strong OSS governance program
76 | 2. Improve the Mean Time To Remediate (MTTR) for resolving known vulnerabilities in OSS
77 | 3. Prevent the consumption of compromised and malicious OSS packages
78 |
79 | The S2C2F (described later in this document) is modeled after three core concepts—_control all artifact inputs, continuous process improvement, and scale._
80 |
81 |
82 | 
83 |
UPD-3 | L2 | 106 | | Intentional vulnerabilities/backdoors added to an OSS code base | [colors v1.4.1](https://snyk.io/blog/open-source-npm-packages-colors-faker/) | SCA-5 | L3 | 107 | | A malicious actor compromises a distribution mirror of a package | [phpMyAdmin](https://arstechnica.com/information-technology/2012/09/questions-abound-as-malicious-phpmyadmin-backdoor-found-on-sourceforge-site/) | AUD-3 | L2 | 108 | | A malicious actor compromises a known good OSS component and adds malicious code into the repo | [ESLint incident](https://eslint.org/blog/2018/07/postmortem-for-malicious-package-publishes) | ING-3
ENF-2
SCA-4 | L3 | 109 | | A malicious actor creates a malicious package that is similar in name to a popular OSS component to trick developers into downloading it | [Typosquatting](https://www.securityweek.com/checkmarx-finds-threat-actor-fully-automating-npm-supply-chain-attacks) | AUD-1
ENF-2
SCA-4 | L3 | 110 | | A malicious actor compromises the compiler used by the OSS during build, adding backdoors | [CCleaner](https://blog.morphisec.com/morphisec-discovers-ccleaner-backdoor) | REB-1 | L4 | 111 | | Dependency confusion, package substitution attacks | [Dependency Confusion](https://www.bleepingcomputer.com/news/security/copycats-imitate-novel-supply-chain-attack-that-hit-tech-giants/) | ENF-1
ENF-2 | L3 | 112 | | An OSS component adds new dependencies that are malicious | [Event-Stream incident](https://blog.npmjs.org/post/180565383195/details-about-the-event-stream-incident) | SCA-4
ENF-2 | L3 | 113 | | The integrity of an OSS package is tampered after build, but before consumption | [How to tamper with Electron apps](https://github.com/jonmest/How-To-Tamper-With-Any-Electron-Application) | AUD-3
AUD-4 | L4 | 114 | | Upstream source can be removed or taken down which can then break builds that depend on that OSS component or container | [left-pad](https://www.theregister.com/2016/03/23/npm_left_pad_chaos/) | ING-2
ING-4 | L3 | 115 | | OSS components reach end-of-support/end-of-life and therefore don't patch vulnerabilities | [log4net](https://github.com/apache/logging-log4net/) and [CVE-2018-1285](https://nvd.nist.gov/vuln/detail/CVE-2018-1285) | SCA-3 | L2 | 116 | | Vulnerability not fixed by upstream maintainer in desired timeframe | [Prototype Pollution in Lodash](https://hackerone.com/reports/712065) | FIX-1 | L4 | 117 | | Bad actor compromises a package manager account (e.g. npm) with no change to the corresponding open source repo and uploads a new malicious version of a package | [Ua-parser-js](https://www.truesec.com/hub/blog/uaparser-js-npm-package-supply-chain-attack-impact-and-response) | AUD-1
ENF-2
SCA-4 | L3 | 118 | | Upstream source code re-licensed which may pose legal risk or prevent practical upgrade paths when licenses are incompatible | [node-ipc license change to DBAD](https://snyk.io/blog/peacenotwar-malicious-npm-node-ipc-package-vulnerability/) | SCA-2 | L1 | 119 | 120 | # Secure Supply Chain Consumption Framework Practices 121 | 122 | ## Target Audience 123 | 124 | This section is a solution-agonistic description of what should be implemented to secure your organization's OSS supply chain. The guidance is useful to compliance/risk managers, security managers, engineering managers, and Chief Information Security Officers (CISOs). 125 | 126 | ## Secure Supply Chain Consumption Framework Practices 127 | 128 | ### _Practice 1: Ingest It_ 129 | 130 | _I can ship any existing asset if external OSS sources are compromised or unavailable._ 131 | 132 | **Sample threat scenarios addressed by this job:** 133 | 134 | - The Docker Hub repository becomes compromised 135 | - A team might be targeted by a dependency confusion attack 136 | - Cloud service itself is unavailable and we need access to OSS assets to restore it 137 | - A package becomes permanently unavailable (i.e. left-pad is removed) 138 | 139 | The first step towards securing a software supply chain is ensuring you control all the artifact inputs. To satisfy this practice, there are two ingestion mechanisms: one for packaged artifacts and one for source code artifacts. 140 | 141 | For **packaged artifacts**, we require ingestion into an artifact stores – Linux package repositories, artifact stores, OCI registries – to fully support _upstream sources_, which transparently proxy from the artifact store to an external source and save a copy of everything used from that source. When using a mix of internal and external packaged artifacts, it is important to secure your package source file configuration to protect yourself from dependency confusion attacks ([CVE-2021-24105](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-24105)). 142 | 143 | For **source code artifacts**, we require mirroring external source code repositories to an internal location. Mirroring the source in addition to caching packages locally is also useful for many reasons: 144 | 145 | - Business Continuity and Disaster Recovery (BCDR) purposes, so that your organization can take ownership of code if a critical dependency is removed from the upstream 146 | - Enables proactive security scans to look for backdoors and zero-day vulnerabilities 147 | - Enables your organization to contribute fixes back upstream 148 | - Enables your organization to perform fixes if needed (in extreme circumstances) 149 | 150 | ### _Practice 2: Scan It_ 151 | 152 | _I know if any OSS artifact in my pipeline has vulnerabilities or malware._ 153 | 154 | **Sample threat scenarios addressed by this job:** 155 | 156 | - A team tries to use an OSS package with a known vulnerability 157 | - A team is already using an OSS package believed to be secure, but a new vulnerability in that package is later publicly disclosed 158 | - A team tries to use an OSS package that is known to steal bitcoins (i.e. the _event-stream_ scenario) 159 | - A team tries to use an OSS package with a backdoor 160 | 161 | Once we control all artifact inputs, we must scan all inputs to trust them. This trust is built using scanners that look for vulnerabilities, malware, malicious or anomalous behavior, extraneous code, end-of-life notices, and other known or previously undiscovered issues (i.e. zero-day vulnerabilities). 162 | 163 | ### _Practice 3: Inventory It_ 164 | 165 | _I know where OSS artifacts are deployed in production._ 166 | 167 | **Sample threat scenarios addressed by this job:** 168 | 169 | - A critical vulnerability is discovered in log4j, and the incident response team wants to know all the production services using log4j so they can appropriately staff and coordinate a response effort 170 | 171 | Once we have ingested and scanned the artifacts entering the software supply chain, we must ensure that we have an inventory where each artifact is used, by knowing in which services it is deployed and in which products it was released. This is required for incident response scenarios so that teams affected by a compromised package can be contacted so the appropriate actions can be taken to remove the affected package. 172 | 173 | ### _Practice 4: Update It_ 174 | 175 | _I can deploy updated external artifacts soon after an update becomes publicly available._ 176 | 177 | **Sample threat scenarios addressed by this job:** 178 | 179 | - A team is currently using three different vulnerable NuGet packages and upgrading each package will be a substantial amount of work for the team. The team chooses to start by upgrading the most widely deployed package. 180 | 181 | Once we have ingested, scanned, and inventoried where each artifact is used, we can enable developers to _fix_ issues with artifacts that have already been used by knowing the supply chain processes that released the product/service that needs the fix. 182 | 183 | Given the [SaltStack incident](https://www.helpnetsecurity.com/2020/05/04/saltstack-salt-vulnerabilities/), where a vulnerability was exploited within 3 days after announcement, every organization should aspire to patch vulnerable OSS packages in under 72 hours so that you patch faster than the adversary can operate. Using tools such as Dependabot to auto-generate Pull Requests (PRs) to update vulnerable OSS become critical capabilities for securing your supply chain. 184 | 185 | ### _Practice 5: Audit It_ 186 | 187 | _I can prove that every OSS artifact in production has a full chain-of-custody from the original artifact source and is consumed through the official supply chain._ 188 | 189 | **Sample threat scenarios addressed by this job:** 190 | 191 | - A well-meaning but misguided developer bypasses the official engineering pipeline to update an OSS package directly in a release; however, this new version contains a known vulnerability 192 | - An attacker with network access intentionally bypasses the official engineering pipeline to deploy malware to a service 193 | 194 | Now that we have ingested, scanned, inventoried, and provided the ability to update any artifact that has come through the software supply chain properly, you must have the ability within your organization to audit OSS consumption to see if it's coming through the standardized consumption tools (such as a package repository solution) established by your organization. 195 | 196 | ### _Practice 6: Enforce It_ 197 | 198 | _I can rely on secure and trusted OSS consumption within my organization._ 199 | 200 | **Sample threat scenarios addressed by this job:** 201 | 202 | - A developer bypasses the official engineering pipeline to consume an OSS package with a known vulnerability 203 | 204 | All OSS artifacts must be consumed from organization-defined approved sources and through the official OSS consumption channels. The next step is to enable enforcement of the supply chain so that all artifacts that in any way impact a production service/release must come through the full supply chain. An example of enforcement is to reroute DNS traffic or configure builds to break if they try to consume OSS from untrusted sources. 205 | 206 | ### _Practice 7: Rebuild It_ 207 | 208 | _I can rebuild from source code every OSS artifact I'm deploying._ 209 | 210 | **Sample threat scenarios addressed by this job:** 211 | 212 | - A team uses a malicious OSS package with a hidden backdoor (which could happen via traditional exploitation, political influence, blackmail or even threats of violence); as a result, the package's binaries do not match its source code. 213 | - An attacker gains access to build infrastructure and modifies generated binaries during the build process; as a result, illicit changes can be injected in a manner that is essentially invisible to its original authors and users alike. 214 | 215 | Until now, we have assumed that we took our inputs at the beginning of the supply chain _as-is_: as the package, container, or other delivery vehicle provided by the author. For key artifacts that are business-critical and for all artifacts that are inputs to High Value Assets, this assumption may not be sufficient. Hence, the next step to secure the supply chain is creating a chain of custody _from the original source code_ for every artifact used to create a production service/release. 216 | 217 | The baseline REBUILD IT requirement is to enable developers who have a critical dependence on certain OSS components to ingest source code (including discovering the source code, which is not always linked to the built artifact), rebuild it (possibly developing build scripts along the way, if they're not part of the source code), make any post-build modifications (e.g. signing), cache the rebuilt artifact, and advertise the internally-rebuilt version's existence to other teams in the organization. One other potential method is the use of multiple third parties to build and come to consensus on a 'correct' artifact (e.g. [Reproducible Builds](https://reproducible-builds.org/)). 218 | 219 | ### _Practice 8: Fix It + Upstream_ 220 | 221 | _I can privately patch, build, and deploy any external artifact within 3 days of harm notification and confidentially contribute the fix to the upstream maintainer._ 222 | 223 | **Sample threat scenarios addressed by this job:** 224 | 225 | - A team has taken a dependency on a package; the package is later discovered to have a critical vulnerability and the maintainer needs help/more time to fix the issue 226 | 227 | **When To Use This:** _This is intended to be used only in extreme scenarios and for temporary risk mitigation. It should only be used when the upstream maintainer is unable to provide a public fix within an acceptable time for your Organization's risk tolerance. The first action any organization should take is to confidentially report the vulnerability to the upstream maintainer AND help suggest a fix_. 228 | 229 | Once we can rebuild any artifact used in the software supply chain, the final step is to be able to privately fix it while confidentially disclosing the vulnerability to the upstream maintainer. Assuming that the team that ingested the source and rebuilt the artifact has allowed PRs to their forked copy of the source and set up CI builds appropriately, then anyone needing to private fix a component can use the normal PR workflow. The only additional work needed is the ability to distribute the private fix as widely within the organization as is needed. 230 | 231 | Related to the note below, the implemented fix should be confidentially contributed to the upstream maintainer to give back to the community. 232 | 233 | 234 | > **📝 Important Note** 235 | > 236 | > The Fix It + Upstream practice should not be perceived as being at odds with supporting communities and projects. If an organization chooses to take a dependency on open source, they should also find ways to give back to the community. Microsoft suggests a number of different ways to contribute: 237 | > - Financial support and participating in foundations or even individual projects: [GitHub Sponsors](https://github.com/sponsors), [OpenCollective](https://opencollective.com/become-a-sponsor), etc. 238 | > - Bounty programs (such as [SOS Rewards](https://sos.dev/)) and sharing best practices and tools with projects around security 239 | > - Being present and participating in key open source projects to share fixes or expertise 240 | > - See Microsoft's approach toward contributing to open source for more ideas [Microsoft's Open Source Program | Microsoft Open Source](https://opensource.microsoft.com/program#program-contributing) 241 | 242 | # The Secure Supply Chain Consumption Framework Implementation Guide 243 | 244 | ## Target Audience 245 | 246 | This section details a maturity model, which splits the practices in the previous section into 4 levels to achieve. There is also a list of tools your organization can implement to meet each security level in the framework. The guidance is useful to software developers, Continuous Integration and Continuous Development (CI/CD) administrators, and security practitioners. 247 | 248 | ## Secure Supply Chain Consumption Framework Levels of Maturity 249 | 250 | When the S2C2F was first developed, the strategy to secure our OSS supply chain was comprised of 8 practices. 251 | 252 |
253 | 
254 |
261 | 
262 |
**Prerequisite**: Two-person PR reviews are enforced. | PR reviewer doesn't want to approve knowing that there are unaddressed vulnerabilities. | 324 | | *Audit It* | AUD-1 | L3 | Verify the provenance of your OSS | Able to track that a given OSS package traces back to a repo | 325 | | | AUD-2 | L2 | Audit that developers are consuming OSS through the approved ingestion method | Detect when developers consume OSS that isn't detected by your inventory or scan tools | 326 | | | AUD-3 | L2 | Validate integrity of the OSS that you consume into your build | Validate digital signature or hash match for each component | 327 | | | AUD-4 | L4 | Validate SBOMs of OSS that you consume into your build | Validate SBOM for provenance data, dependencies, and its digital signature for SBOM integrity | 328 | | *Enforce It* | ENF-1 | L2 | Securely configure your package source files (i.e. nuget.config, .npmrc, pip.conf, pom.xml, etc.) | By using NuGet package source mapping, or a single upstream feed, or using version pinning and lock files, you can protect yourself from race conditions and Dependency Confusion attacks | 329 | | | ENF-2 | L3 | Enforce usage of a curated OSS feed that enhances the trust of your OSS | Curated OSS feeds can be systems that scan OSS for malware, validate claims-metadata about the component, or systems that enforce an allow/deny list. Developers should not be allowed to consume OSS outside of the curated OSS feed | 330 | | *Rebuild It* | REB-1 | L4 | Rebuild the OSS in a trusted build environment, or validate that it is reproducibly built.
**Prerequisite**: Sufficient build integrity measures are in place to establish a trusted build environment. | Mitigates against build-time attacks such as those seen on CCleaner and SolarWinds. Open Source developers could introduce scripts or code that aren't present in the repository into the build process or be building in a compromised environment. | 331 | | | REB-2 | L4 | Digitally sign the OSS you rebuild | Protect the integrity of the OSS you use. | 332 | | | REB-3 | L4 | Generate SBOMs for OSS that you rebuild | Captures the supply chain information for each package to enable you to better maintain your dependencies, auditability, and blast radius assessments | 333 | | | REB-4 | L4 | Digitally sign the SBOMs you produce | Ensures that consumers of your SBOMs can trust that the contents have not been tampered with | 334 | | *Fix It + Upstream* | FIX-1 | L4 | Implement a change in the code to address a zero-day vulnerability, rebuild, deploy to your organization, and confidentially contribute the fix to the upstream maintainer | To be used only in extreme circumstances when the risk is too great and to be used temporarily until the upstream maintainer issues a fix. | 335 | 336 | ## Secure Supply Chain Consumption Framework Tooling Availability 337 | 338 | **Tooling referenced within the S2C2F:** 339 | 340 | The implementation guidance and tooling in this document are a combination of paid and free tools across the industry. It is not a comprehensive list, but is included to provide examples of the type of solutions that help address the S2C2F requirements. Before jumping to any solutions, you should first understand the needs of your team/organization (such as what languages they use) and then assess multiple tool's capabilities from across the industry against your needs (such as ensuring the solution supports your top-used languages). 341 | 342 | 343 | ## Implementing the Secure Supply Chain Consumption Framework by Level 344 | 345 | Below is a table of the S2C2F requirements with example tools from across the industry or detailed instructions to implement them, sorted by maturity level. Many of the tools referenced below are freely available and are listed as such. Some tools that are individually listed are available through a bundled offering, such as [GitHub Advanced Security](https://docs.github.com/en/enterprise-server@3.4/get-started/learning-about-github/about-github-advanced-security) (GHAS). We aren't specifically endorsing any tool or service, as they each have different strengths or weaknesses. We recommend performing a thorough evaluation before deciding on a specific solution, including tools not referenced in this document. 346 | 347 | This table maps each Framework requirement to corresponding level and Framework practice. To see the full list of requirements and their benefits, please see the [Secure Supply Chain Consumption Framework Requirements](#Secure-Supply-Chain-Consumption-Framework-Requirements) earlier in this document. 348 | 349 | | **Practice name** | **L1** | **L2** | **L3** | **L4** | 350 | | --- | --- | --- | --- | --- | 351 | | **Ingest it** – save a local copy of artifacts and source code | [**ING-1**] Use package managers trusted by your organization
[**ING-2**] Saving a local copy of the OSS artifact can be done by adopting an integrated package caching solution into your CI/CD infrastructure. All developers across your organization should standardize their consumption methods (using governed workflows) so that security policy can be enforced.
**Free Tools:** [VCPKG for C/C++ OSS](https://github.com/Microsoft/vcpkg), [Pulp](https://pulpproject.org/)
**Paid Tools:** [Artifacts](https://docs.microsoft.com/en-us/azure/devops/artifacts/start-using-azure-artifacts?view=azure-devops), [GitHub Packages](https://github.com/features/packages), [Azure Container Registry](https://docs.microsoft.com/en-us/azure/container-registry/container-registry-get-started-portal), [PackageCloud](https://packagecloud.io/) | | [**ING-3**] Having a Deny List capability to block ingestion of vulnerable and malicious OSS components is a required defensive tool in incident response situations. Having an incident response team that can rapidly respond and update the deny list is also critical.
**Paid Tool:** [Nexus Firewall](https://www.sonatype.com/products/firewall)
[**ING-4**] Saving a local copy of the OSS source code
**Free Tool:** [Duplicating a repo](https://docs.github.com/en/repositories/creating-and-managing-repositories/duplicating-a-repository) | | 352 | | **Scan It -** for vulnerabilities and malware | [**SCA-1**] It is required to scan for known vulnerabilities of your dependencies. Choosing a tool that gets vulnerabilities from more places than just CVEs is important to ensure that you are being informed from across multiple vulnerability sources.
**Free Tool:** [GitHub Dependency Graph](https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/about-the-dependency-graph)
**Paid Tool:** [Snyk Open Source](https://snyk.io/product/open-source-security-management/), [Mend SCA](https://www.mend.io/sca/)
[**SCA-2**] In addition to scanning for vulnerabilities, OSS should be scanned for software licenses.
**Free Tool:** [ScanCode](https://github.com/nexB/scancode-toolkit) | [**SCA-3**] Scanning OSS to determine if it is end of life is crucial to ensure that you are not taking dependencies on OSS that is no longer updated.
**Free Tool**: [OpenSSF Scorecard](https://github.com/ossf/scorecard) | [**SCA-4**] Given the rise in malicious OSS packages over the years, it is critical that OSS be scanned for malware prior to consumption.
**Free Tool:** [Mend Supply Chain Defender](https://www.mend.io/mend-supply-chain-defender/), [OpenSSF Package Analysis](https://github.com/ossf/package-analysis)
**Paid Tool:** [Nexus Firewall](https://www.sonatype.com/products/firewall), [Checkmarx SCA](https://checkmarx.com/resource/documents/en/34965-19105-preventing-supply-chain-attacks.html)
[**SCA-5**] Without doing proactive security analysis to look for zero-day vulnerabilities, there would be entire threat categories that would go unmitigated, such as back-doors.
**Free Tools:** [OSSGadget](https://github.com/microsoft/OSSGadget), [DevSkim](https://github.com/microsoft/DevSkim), [Attack Surface Analyzer](https://github.com/microsoft/AttackSurfaceAnalyzer), [Application Inspector](https://github.com/microsoft/ApplicationInspector), [CodeQL](https://codeql.github.com/), [OneFuzz](https://github.com/microsoft/onefuzz), [RESTler](https://github.com/microsoft/restler-fuzzer)
**Paid Tool:** [Semgrep](https://semgrep.dev/) | | 353 | | **Inventory It -** OSS usage and deployment | [**INV-1**] Establishing an inventory of all developer OSS dependencies is critical when responding to an incident as an ingested malicious component would need to be deleted from the developer's desktop, the package caching solution, and the software/service that in production that consumed the package. Knowing which projects are using which OSS components and their versions across your enterprise is vital toward supporting rapid Incident Response.
**Free Tool**: [Component Detection](https://github.com/microsoft/component-detection), [SBOM Generator for 1st party code](https://github.com/microsoft/sbom-tool), [Syft](https://github.com/anchore/syft), [Tern](https://github.com/tern-tools/tern), [SCA tooling](https://github.com/bureado/awesome-software-supply-chain-security#sca-and-sbom)
**Paid Tool**: [Dependency Graph w/ Insights](https://docs.github.com/en/organizations/collaborating-with-groups-in-organizations/viewing-insights-for-your-organization#viewing-organization-dependency-insights) via [GHAS](https://docs.github.com/en/enterprise-server@3.4/get-started/learning-about-github/about-github-advanced-security) | [**INV-2**] Have an incident response plan that leverages your inventory and your deny list.
**Free Tool:** [Incident Response Reference Guide](https://www.microsoft.com/en-us/download/details.aspx?id=103148) | | | 354 | | **Update It** | [**UPD-1**] Update vulnerable OSS manually. | [**UPD-2**] Automating patching OSS dependencies to address known vulnerabilities in a timely manner.
**Free Tool**: [Dependabot](https://docs.github.com/en/code-security/dependabot/dependabot-alerts/about-dependabot-alerts), [Renovate](https://github.com/renovatebot/renovate)
[**UPD-3**] Display OSS vulnerabilities in developer contribution flow (i.e. Pull Requests).
**Paid Tool**: [Dependency Review](https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/about-dependency-review) via [GHAS](https://docs.github.com/en/enterprise-server@3.4/get-started/learning-about-github/about-github-advanced-security) | | | 355 | | **Audit It -** provenance and consumption workflows | | [**AUD-2**] Audit that developers are consuming OSS through the approved ingestion method. You can search for binaries that are checked into the repo.
**Free Guide**: [Searching Code](https://docs.github.com/en/search-github/searching-on-github/searching-code)
[**AUD-3**] Validate integrity of the OSS that you consume into your build.
**Free Tool**: [NuGet CLI verify command](https://docs.microsoft.com/en-us/nuget/reference/cli-reference/cli-ref-verify), | [**AUD-1**] Verify the provenance of all OSS components to ensure they come through the official supply chain.
**Paid Tool**: [Nexus Firewall](https://www.sonatype.com/products/firewall) | [**AUD-4**] Validate the SBOMs of OSS that you consume into your build.
**Free Tool**: [Community Attestation Service](https://cas.codenotary.com/) | 356 | | **Enforce It -** OSS consumption meets security policy | | [**ENF-1**] Securing the configuration of how build pipelines consume OSS components.
**Free Tools:** [NuGet Package Source Mapping](https://docs.microsoft.com/en-us/nuget/consume-packages/package-source-mapping), [Version pinning and Lock Files](https://azure.microsoft.com/mediahandler/files/resourcefiles/3-ways-to-mitigate-risk-using-private-package-feeds/3%20Ways%20to%20Mitigate%20Risk%20When%20Using%20Private%20Package%20Feeds%20-%20v1.0.pdf) | [**ENF-2**] Enforcing teams to only consume packages from a curated feed is the goal of this Framework.
**Paid Tool**: [Nexus Firewall](https://www.sonatype.com/products/firewall) | | 357 | | **Rebuild It -** from source | | | | [**REB-1**] Rebuilding from source in a trusted build environment removes the risk of consuming a package that may have been victim to a CCleaner/SolarWinds style build-time attack.
**Free Tools:** [Oryx](https://github.com/microsoft/oryx), [DotNet.ReproducibleBuilds](https://www.nuget.org/packages/DotNet.ReproducibleBuilds/), [Reproducible-Builds.org](https://reproducible-builds.org/), [OSS Reproducible](https://github.com/microsoft/OSSGadget/tree/main/src/oss-reproducible), [rebuilderd](https://github.com/kpcyrd/rebuilderd)
[**REB-2**] Digitally sign the OSS you rebuild.
**Tool:** [Notary](http://notaryproject.dev/), [SigStore](https://www.sigstore.dev/)
[**REB-3**] If you are rebuilding the OSS yourself, you can automate Software Bill of Material (SBOM) generation at build time. This helps capture the supply chain information for each package to enable you to better maintain auditability and blast radius assessments.
**Free Tool:** [SBOM Generator](https://github.com/microsoft/sbom-tool) on rebuilt 3rd party code
[**REB-4**] Digitally sign the SBOMs you produce.
**Free Tool:** [Notary](notaryproject.dev) | 358 | | **Fix It + Upstream** | | | | [**FIX-1**] In extreme cases, when a newly discovered vulnerability is so severe and you cannot wait for an upstream maintainer to implement a fix, you should implement a change in the code to address a zero-day vulnerability, rebuild, deploy to your organization, and confidentially contribute the fix to the upstream maintainer.
**Free Tool**: [Follow confidential disclosure guidelines](https://docs.github.com/en/code-security/security-advisories/about-coordinated-disclosure-of-security-vulnerabilities) | 359 | 360 | # Conclusion 361 | 362 | The goal of this paper is to provide a _simple_ framework for the pragmatic inclusion of secure OSS consumption practices in the software development process. It outlines a series of discrete, non-proprietary security development activities that when joined with effective process automation and maturation levels represent the steps necessary for an organization to objectively claim compliance with the S2C2F as defined by the requirements identified in Level 3 of the S2C2F Maturity Model. 363 | 364 | # Appendix: Relation to SCITT 365 | The [Supply Chain Integrity, Transparency, and Trust](https://github.com/ietf-scitt) initiative, or SCITT, is a set of proposed industry standards for managing the compliance of goods and services across end-to-end supply chains. In the future, we expect teams to output "attestations of conformance" to the S2C2F requirements and store it in SCITT. The format of such attestations is to be determined. 366 | 367 | # Appendix: Mapping Secure Supply Chain Consumption Framework Requirements to Other Specifications 368 | 369 | There are many other security frameworks, guides, and controls. This section maps the S2C2F Framework requirements to other relevant specifications including NIST SP 800-161, NIST SP 800-218, CIS Software Supply Chain Security Guide, OWASP Software Component Verification Standard, SLSA, and the CNCF Software Supply Chain Best Practices. 370 | 371 | | **Requirement ID** | **Requirement Title** | **References** | 372 | | --- | --- | --- | 373 | | ING-1 | Use package managers trusted by your organization | **CIS SSC SG** : 3.1.5
**OWASP SCVS:** 1.2
**CNCF SSC:** Define and prioritize trusted package managers and repositories | 374 | | ING-2 | Use an OSS binary repository manager solution | **OWASP SCVS:** 4.1
**CNCF SSC:** Define and prioritize trusted package managers and repositories | 375 | | ING-3 | Have a Deny List capability to block known malicious OSS from being consumed | | 376 | | ING-4 | Mirror a copy of all OSS source code to an internal location | **CNCF SSC:** Build libraries based upon source code | 377 | | SCA-1 | Scan OSS for known vulnerabilities | **SP800218** : RV.1.1
**SP800161** : SA-10, SR-3, SR-4
**CIS SSC SG** : 1.5.5, 3.2.2
**OWASP SCVS:** 5.4
**CNCF SSC:** Verify third party artefacts and open source libraries, Scan software for vulnerabilities, Run software composition analysis on ingested software | 378 | | SCA-2 | Scan OSS for licenses | **CIS SSC SG** : 1.5.6, 3.2.3
**OWASP SCVS:** 5.12
**CNCF SSC:** Scan software for license implications | 379 | | SCA-3 | Scan OSS to determine if its end-of-life | **SP800218** : PW.4.1
**SP800161** : SA-4, SA-5, SA-8(3), SA-10(6), SR-3, SR-4
**OWASP SCVS:** 5.8 | 380 | | SCA-4 | Scan OSS for malware | | 381 | | SCA-5 | Perform proactive security analysis of OSS | **SP800218** : PW.4.4
**SP800161** : SA-4, SA-8, SA-9, SA-9(3), SR-3, SR-4, SR-4(3), SR-4(4)
**OWASP SCVS:** 5.2, 5.3, | 382 | | INV-1 | Maintain an automated inventory of all OSS used in development | **OWASP SCVS:** 1.1, 1.3, 1.8, 5.11
**CNCF SSC:** Track dependencies between open source components | 383 | | INV-2 | Have an OSS Incident Response Plan | **SP800218** : RV.2.2
**SP800161** : SA-5, SA-8, SA-10, SA-11, SA-15(7) | 384 | | UPD-1 | Update vulnerable OSS manually | | 385 | | UPD-2 | Enable automated OSS updates | | 386 | | UPD-3 | Display OSS vulnerabilities in developer contribution flow (i.e. Pull Requests) | | 387 | | AUD-1 | Verify the provenance of your OSS | **CIS SSC SG** : 3.2.4
**OWASP SCVS:** 1.10, 6.1
**SLSA v1.0:** Producing artifacts – Distribute provenance | 388 | | AUD-2 | Audit that developers are consuming OSS through the approved ingestion method | **CIS SSC SG** : 4.3.3 | 389 | | AUD-3 | Validate integrity of the OSS that you consume into your build | **CIS SSC SG** : 2.4.3
**OWASP SCVS:** 4.12
**CNCF SSC:** Verify third party artefacts and open source libraries | 390 | | AUD-4 | Validate SBOMs of OSS that you consume into your build | **CNCF SSC:** Require SBOM from third party supplier | 391 | | ENF-1 | Securely configure your package source files (i.e. nuget.config, .npmrc, pip.conf, pom.xml, etc.) | **SP800218** : PO.5.2
**CIS SSC SG** : 2.4.2, 3.1.7, 4.3.4, 4.4.2 | 392 | | ENF-2 | Enforce usage of a curated OSS feed that enhances the trust of your OSS | **SP800218** : PO.5.2
**CIS SSC SG** : 2.4.3, 3.1.1, 3.1.3 | 393 | | REB-1 | Rebuild the OSS in a trusted build environment, or validate that it is reproducibly built | **CIS SSC SG** : 2.4.4 | 394 | | REB-2 | Digitally sign the OSS you rebuild | **SP800218** : PS.2.1 | 395 | | REB-3 | Generate SBOMs for OSS that you rebuild | **SP800218** : PS.3.2
**SP800161** : SA-8, SR-3, SR-4
**CIS SSC SG** : 2.4.5
**OWASP SCVS:** 1.4, 1.7
**CNCF SSC:** Generate an immutable SBOM of the code | 396 | | REB-4 | Digitally sign the SBOMs you produce | **CIS SSC SG** : 2.4.6 | 397 | | FIX-1 | Implement a change in the code to address a zero-day vulnerability, rebuild, deploy to your organization, and confidentially contribute the fix to the upstream maintainer | | 398 | 399 | # Appendix: References 400 | 401 | Here is a list of hyperlinks for documents mentioned within this paper: 402 | 403 | - [The Free Software Definition](https://en.wikipedia.org/wiki/The_Free_Software_Definition) 404 | - [The Open Source Definition](https://opensource.org/osd) 405 | - [Supply Chain Risk Management Practices for Federal Information Systems and Organizations (nist.gov)](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-161.pdf) 406 | - [Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities (nist.gov)](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-218.pdf) 407 | - [CIS WorkBench / Benchmarks (cisecurity.org)](https://workbench.cisecurity.org/benchmarks/7555) 408 | - [OWASP Software Component Verification Standard | OWASP Foundation](https://owasp.org/www-project-software-component-verification-standard/) 409 | - [SLSA • Supply-chain Levels for Software Artifacts](https://slsa.dev/) 410 | - [tag-security/CNCF\_SSCP\_v1.pdf at main · cncf/tag-security (github.com)](https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf) 411 | -------------------------------------------------------------------------------- /Minutes/2022 -23 Meeting Notes.md: -------------------------------------------------------------------------------- 1 | 2 |
S2C2F SIG Meeting
3 | 4 | 5 |“Meeting Notes” Document
6 | 7 | 8 | Please use the [2024 Meeting Notes](https://docs.google.com/document/d/1oPfzqdPb1ey5eGggU2DOwfwY0vzEAa9kWm3FieiYT90/edit?usp=sharing) 9 | 10 | [Code of Conduct](https://github.com/ossf/s2c2f/blob/main/Code%20of%20Conduct.md) 11 | 12 | Note: For OpenSSF, see the Linux Foundation [Antitrust policy](https://www.linuxfoundation.org/antitrust-policy/) 13 | 14 | 15 | --- 16 | 17 | 18 || We keep all our docs in our GitHub Repo
21 | 22 | (This includes published papers, assessments, and other goodies) 23 | |
24 | Hangout in the OpenSSF Slack
25 | 26 | Our channel is #s2c2f 27 | |
28 | Join our mailing list https://lists.openssf.org/g/openssf-sig-s2c2f 29 | | 30 |S2C2F SIG Meeting
31 | 32 | We meet every 3rd Tuesday of the month 33 | 34 | at 35 | 36 | 12 pm PT| 3 pm ET| 8 pm GMT 37 | |
38 |
| 41 | | 42 |
43 |
44 |
45 | 46 | Join our call live on 47 | 48 | LFX Zoom 49 | |
50 | Missed a meeting?
51 | 52 | No drama - YouTube TBD 53 | |
54 | 55 | | 56 |
Document conventions & history
64 | 65 | 66 | 67 | 68 | * Template for each meeting: [Link to copy meeting notes template](https://docs.google.com/document/d/1zJHmgJDguJy0lmLv89RwkiUwv_qucqe8cSyccnd6Ryk/edit#heading=h.xuyh3ba3raf4) 69 | * Facilitators: Adrian Diglio, Jay White 70 | * Notes are in reverse chronological order. Most recent meeting at the top. 71 | 72 | 73 | [Planned Meetings](#heading=h.q3539ohya47f) 74 | 75 | 76 | **Instructions on adding agenda items to planned meetings:** 77 | 78 | 79 | 80 | * If you’d like to present during a Monthly meeting: 81 | * Submit an agenda item to [S2C2F Issues](https://github.com/ossf/s2c2f/issues) 82 | * If you’d like to add a topic of discussion for working sessions (usually ~5mins intro discussion without screen share) 83 | * Add your topic to the agenda only to WORKING SESSIONS 84 | * Contact a facilitator to inform them of the agenda item, so they can provide feedback if necessary 85 | 86 || 89 | Date 90 | | 91 |Details 92 | | 93 |
| 8/16/2022 - Community Meeting 96 | | 97 |
98 |
|
106 |
| 8/29/2022 - Technical Meeting 109 | | 110 |
111 |
|
117 |
| 9/20/2022 - Community Meeting 120 | | 121 |
122 |
|
128 |
| 9/26/2022 - Technical Meeting 131 | | 132 |
133 |
|
139 |
| 10/18/2022 142 | | 143 |
144 |
|
150 |
| 11/1/2022 153 | | 154 |
155 |
|
167 |
| 11/15/2022 170 | | 171 |
172 |
|
180 |
| 12/13/2022 183 | | 184 |
185 |
|
193 |
| 1/31/2023 196 | | 197 ||
| 2/14/2023 202 | | 203 |204 | - Looking for contributors! 205 | | 206 |
| 2/28/2023 209 | | 210 |
211 | Sharing S2C2F was discussed in the opensourcesecurity podcast Episode 363 – Joylynn Kirui from Microsoft on DevSecOps – Open Source Security
212 | 213 | 214 | - Inclusion of S2C2F in the SKF?? 215 | 216 | 217 | - Inclusion of S2C2F OSS patching tools into the Security Tooling WG Guide (Sarah Evans) 218 | |
219 |
| 3/14/2023 222 | | 223 |224 | - Sharing draft SKF Course Outline for S2C2F 225 | | 226 |
| 3/28/2023 229 | | 230 |
231 | - Approval to add a new category of tools to the Guide to Security Tools. Just need to submit PR
232 | 233 | 234 | - RSA slides complete 235 | |
236 |
| 4/11/2023 239 | | 240 |
241 | - Review Issues, discuss potential new requirement
242 | 243 | 244 | - Explanatory report 245 | |
246 |
| 5/9/2023 249 | | 250 |251 | - Looking for contributors for other CI/CD environments! s2c2f/Reference_implementation at main · ossf/s2c2f · GitHub 252 | | 253 |
| 6/6/2023 256 | | 257 |258 | - Melba Lopez (IBM) provided feedback on the S2C2F guide 259 | | 260 |
| 6/20/2023 263 | | 264 |
265 | - Crosswalk with SLSA · Issue #14 · ossf/s2c2f (github.com)
266 | 267 | 268 | - Creation of an FAQ section in the repo? 269 | 270 | 271 | - Best way to keep repo organized when adding addendums or supplemental materials (such as a C/C++ specific guide)? 272 | |
273 |
| 7/18/2023 276 | | 277 |278 | - Addressing Issues in the Repo 279 | | 280 |
| 8/1/2023 283 | | 284 |285 | - Upcoming Hackathon project to develop an OSCAL schema and possibly a tool 286 | | 287 |
| 8/15/2023 290 | | 291 |
292 | - Address questions about SCA-3, UPD-3, and ENF-1 from Gergely
293 | 294 | 295 | - OSCAL overview for Hackathon 296 | 297 | 298 | - Review JFrog article on new attack types seen on NuGet, and assess against our list of mitigations today · Issue #17 · ossf/s2c2f (github.com) 299 | 300 | 301 | - Popular NuGet Package “Moq” Silently Exfiltrates User Data to Cloud Service | by Jossef Harush Kadouri | checkmarx-security | Aug, 2023 | Medium 302 | |
303 |
| 8/29/2023 306 | | 307 |
308 | - Upcoming Hackathon - Apache license
309 | 310 | 311 | - FAQ updated per last conversation 312 | 313 | 314 | - Review JFrog article on new attack types seen on NuGet, and assess against our list of mitigations today · Issue #17 · ossf/s2c2f (github.com) 315 | 316 | 317 | - Popular NuGet Package “Moq” Silently Exfiltrates User Data to Cloud Service | by Jossef Harush Kadouri | checkmarx-security | Aug, 2023 | Medium 318 | |
319 |
| 9/12/2023 322 | | 323 |324 | - Update of S2C2F OSCAL hackathon progress 325 | | 326 |
| 9/26/2023 329 | | 330 |
331 | - Review JFrog article on new attack types seen on NuGet, and assess against our list of mitigations today · Issue #17 · ossf/s2c2f (github.com)
332 | 333 | 334 | - Popular NuGet Package “Moq” Silently Exfiltrates User Data to Cloud Service | by Jossef Harush Kadouri | checkmarx-security | Aug, 2023 | Medium 335 | |
336 |
| 10/10/2023 339 | | 340 |
341 | - Security Toolbelt presentation
342 | 343 | 344 | - Security Tooling working group, and tools for S2C2F 345 | |
346 |
| 10/24/2023 349 | | 350 |351 | - Anything to talk about S2C2F and MITRE ATT&CK? 352 | | 353 |
| 11/7/2023 356 | | 357 |
358 | -Spreading awareness: Cloudsmith
359 | 360 | 361 | -GitHub Issues 362 | 363 | 364 | -From Sarah: S2C2F and MITRE ATT&CK 365 | |
366 |
| 12/5/2023 369 | | 370 |
371 | -S2C2F PAS update
372 | 373 | 374 | -webinar and CloudSmith blog 375 | |
376 |
Proposed Topics for Future Meetings
381 | 382 | 383 | Proposed Agenda Items (anyone can propose one here for small-ish items or to discuss with the group when to schedule, and we’ll add to meetings on-the-fly as time permits) 384 | 385 | [Link to copy meeting notes template (instead of scrolling to the bottom)](https://docs.google.com/document/d/1zJHmgJDguJy0lmLv89RwkiUwv_qucqe8cSyccnd6Ryk/edit#heading=h.xuyh3ba3raf4) 386 | 387 | Facilitator intro script (to be recited at the beginning of each meeting): 388 | 389 | _“ Hello everyone, just a reminder that this meeting is being recorded, and we hope to post to YouTube in the near future. Your participation in these meetings is an agreement to abide by the Code of Conduct, which can be found in the repo. I need at least one person to volunteer as scribe to ensure all actions and primary content discussed is recorded in the written notes and may be referred to later. Who is willing? Please remember to include your organization/company along with the update.”_ 390 | 391 |**2024-1-16 S2C2F SIG Meeting**
392 | 393 | 394 |Attendance
395 | 396 | 397 | 398 || Present? 401 | | 402 |Name 403 | | 404 |Organization 405 | | 406 |
| 409 | | 410 |Jay White 411 | | 412 |Microsoft 413 | | 414 |
| 417 | | 418 |Adrian Diglio 419 | | 420 |Microsoft 421 | | 422 |
| 425 | | 426 |Victor Lu 427 | | 428 |independent 429 | | 430 |
| 433 | | 434 |Patricia Tarro 435 | | 436 |Dell 437 | | 438 |
| 441 | | 442 |Brian Crooks 443 | | 444 |Datalytica 445 | | 446 |
**2024-01-02 S2C2F SIG Meeting**
487 | 488 | 489 |Attendance
490 | 491 | 492 | 493 || Present? 496 | | 497 |Name 498 | | 499 |Organization 500 | | 501 |
| Yes 504 | | 505 |Jay White 506 | | 507 |Microsoft 508 | | 509 |
| 512 | | 513 |Adrian Diglio 514 | | 515 |Microsoft 516 | | 517 |
| 520 | | 521 |Victor Lu 522 | | 523 |independent 524 | | 525 |
| Yes 528 | | 529 |Patricia Tarro 530 | | 531 |Dell 532 | | 533 |
| 536 | | 537 |Brian Crooks 538 | | 539 |Datalytica 540 | | 541 |
| Yes 544 | | 545 |Tom Bedford 546 | | 547 |Bloomberg 548 | | 549 |
**2023-12-5 S2C2F SIG Meeting**
586 | 587 | 588 |Attendance
589 | 590 | 591 | 592 || Present? 595 | | 596 |Name 597 | | 598 |Organization 599 | | 600 |
| X 603 | | 604 |Jay White 605 | | 606 |Microsoft 607 | | 608 |
| x 611 | | 612 |Adrian Diglio 613 | | 614 |Microsoft 615 | | 616 |
| X 619 | | 620 |Victor Lu 621 | | 622 |independent 623 | | 624 |
| X 627 | | 628 |Patricia Tarro 629 | | 630 |Dell 631 | | 632 |
| X 635 | | 636 |Brian Crooks 637 | | 638 |Datalytica 639 | | 640 |
**2023-11-7 S2C2F SIG Meeting**
691 | 692 | 693 |Attendance
694 | 695 | 696 | 697 || Present? 700 | | 701 |Name 702 | | 703 |Organization 704 | | 705 |
| X 708 | | 709 |Jay White 710 | | 711 |Microsoft 712 | | 713 |
| X 716 | | 717 |Jasmine Wang 718 | | 719 |Microsoft 720 | | 721 |
| X 724 | | 725 |Tom Bedford 726 | | 727 |Bloomberg LP 728 | | 729 |
| x 732 | | 733 |Adrian Diglio 734 | | 735 |Microsoft 736 | | 737 |
| X 740 | | 741 |Sarah Evans 742 | | 743 |Dell 744 | | 745 |
**2023-10-10 S2C2F SIG Meeting**
804 | 805 | 806 |Attendance
807 | 808 | 809 | 810 || Present? 813 | | 814 |Name 815 | | 816 |Organization 817 | | 818 |
| X 821 | | 822 |Jay White 823 | | 824 |Microsoft 825 | | 826 |
| x 829 | | 830 |Mike Lieberman 831 | | 832 |Kusari 833 | | 834 |
| x 837 | | 838 |Adrian Diglio 839 | | 840 |Microsoft 841 | | 842 |
| x 845 | | 846 |Sarah Evans 847 | | 848 |Dell 849 | | 850 |
| X 853 | | 854 |Patricia Tarro 855 | | 856 |Dell 857 | | 858 |
**2023-09-12 S2C2F SIG Meeting**
898 | 899 | 900 |Attendance
901 | 902 | 903 | 904 || Present? 907 | | 908 |Name 909 | | 910 |Organization 911 | | 912 |
| X 915 | | 916 |Jay White 917 | | 918 |Microsoft 919 | | 920 |
| x 923 | | 924 |Mike Lieberman 925 | | 926 |Kusari 927 | | 928 |
| X 931 | | 932 |Adrian Diglio 933 | | 934 |Microsoft 935 | | 936 |
| X 939 | | 940 |Patricia Tarro 941 | | 942 |Dell 943 | | 944 |
**2023-09-12 S2C2F SIG Meeting**
983 | 984 | 985 |Attendance
986 | 987 | 988 | 989 || Present? 992 | | 993 |Name 994 | | 995 |Organization 996 | | 997 |
| x 1000 | | 1001 |Jay White 1002 | | 1003 |Microsoft 1004 | | 1005 |
| x 1008 | | 1009 |Mike Lieberman 1010 | | 1011 |Kusari 1012 | | 1013 |
| x 1016 | | 1017 |Tom Bedford 1018 | | 1019 |Bloomberg LP 1020 | | 1021 |
| x 1024 | | 1025 |Adrian Diglio 1026 | | 1027 |Microsoft 1028 | | 1029 |
| x 1032 | | 1033 |Nisha Kumar 1034 | | 1035 |Oracle 1036 | | 1037 |
| x 1040 | | 1041 |Andres Orbe 1042 | | 1043 |independent 1044 | | 1045 |
**2023-08-29 S2C2F SIG Meeting**
1084 | 1085 | 1086 |Attendance
1087 | 1088 | 1089 | 1090 || Present? 1093 | | 1094 |Name 1095 | | 1096 |Organization 1097 | | 1098 |
| X 1101 | | 1102 |Jay White 1103 | | 1104 |Microsoft 1105 | | 1106 |
| X 1109 | | 1110 |Jasmine Wang 1111 | | 1112 |Microsoft 1113 | | 1114 |
| X 1117 | | 1118 |Mike Lieberman 1119 | | 1120 |Kusari 1121 | | 1122 |
| X 1125 | | 1126 |Tom Bedford 1127 | | 1128 |Bloomberg LP 1129 | | 1130 |
| X 1133 | | 1134 |Adrian Diglio 1135 | | 1136 |Microsoft 1137 | | 1138 |
| X 1141 | | 1142 |Sarah Evans 1143 | | 1144 |Dell 1145 | | 1146 |
| X 1149 | | 1150 |Victor Lu 1151 | | 1152 |independent 1153 | | 1154 |
| X 1157 | | 1158 |Tabatha DiDomenico 1159 | | 1160 |G-Research 1161 | | 1162 |
| X 1165 | | 1166 |Aeva Black 1167 | | 1168 |CISA 1169 | | 1170 |
| X 1173 | | 1174 |Eddie Knight 1175 | | 1176 |Sonatype 1177 | | 1178 |
| X 1181 | | 1182 |Colin Griffin 1183 | | 1184 |Krumware 1185 | | 1186 |
**2023-08-15 S2C2F SIG Meeting**
1238 | 1239 | 1240 |Attendance
1241 | 1242 | 1243 | 1244 || Present? 1247 | | 1248 |Name 1249 | | 1250 |Organization 1251 | | 1252 |
| X 1255 | | 1256 |Jay White 1257 | | 1258 |Microsoft 1259 | | 1260 |
| X 1263 | | 1264 |Tom Bedford 1265 | | 1266 |Bloomberg LP 1267 | | 1268 |
| X 1271 | | 1272 |Adrian Diglio 1273 | | 1274 |Microsoft 1275 | | 1276 |
| X 1279 | | 1280 |Sarah Evans 1281 | | 1282 |Dell 1283 | | 1284 |
| X 1287 | | 1288 |Nisha Kumar 1289 | | 1290 |Oracle 1291 | | 1292 |
**2023-08-1 S2C2F SIG Meeting**
1338 | 1339 | 1340 |Attendance
1341 | 1342 | 1343 | 1344 || Present? 1347 | | 1348 |Name 1349 | | 1350 |Organization 1351 | | 1352 |
| X 1355 | | 1356 |Jay White 1357 | | 1358 |Microsoft 1359 | | 1360 |
| X 1363 | | 1364 |Jasmine Wang 1365 | | 1366 |Microsoft 1367 | | 1368 |
| X 1371 | | 1372 |David A. Wheeler 1373 | | 1374 |Linux Foundation 1375 | | 1376 |
| X 1379 | | 1380 |Mike Lieberman 1381 | | 1382 |Kusari 1383 | | 1384 |
| X 1387 | | 1388 |Tom Bedford 1389 | | 1390 |Bloomberg LP 1391 | | 1392 |
| X 1395 | | 1396 |Adrian Diglio 1397 | | 1398 |Microsoft 1399 | | 1400 |
| X 1403 | | 1404 |Sarah Evans 1405 | | 1406 |Dell 1407 | | 1408 |
| X 1411 | | 1412 |Victor Lu 1413 | | 1414 |independent 1415 | | 1416 |
**2023-07-18 S2C2F SIG Meeting**
1463 | 1464 | 1465 |Attendance
1466 | 1467 | 1468 | 1469 || Present? 1472 | | 1473 |Name 1474 | | 1475 |Organization 1476 | | 1477 |
| X 1480 | | 1481 |Jasmine Wang 1482 | | 1483 |Microsoft 1484 | | 1485 |
| X 1488 | | 1489 |David A. Wheeler 1490 | | 1491 |Linux Foundation 1492 | | 1493 |
| X 1496 | | 1497 |Melba-Lopez 1498 | | 1499 |IBM 1500 | | 1501 |
| X 1504 | | 1505 |Mike Lieberman 1506 | | 1507 |Kusari 1508 | | 1509 |
| X 1512 | | 1513 |Tom Bedford 1514 | | 1515 |Bloomberg LP 1516 | | 1517 |
| X 1520 | | 1521 |Adrian Diglio 1522 | | 1523 |Microsoft 1524 | | 1525 |
| X 1528 | | 1529 |Sarah Evans 1530 | | 1531 |Dell 1532 | | 1533 |
| X 1536 | | 1537 |Josh Clements 1538 | | 1539 |ADI 1540 | | 1541 |
**2023-06-20 S2C2F SIG Meeting**
1593 | 1594 | 1595 |Attendance
1596 | 1597 | 1598 | 1599 || Present? 1602 | | 1603 |Name 1604 | | 1605 |Organization 1606 | | 1607 |
| X 1610 | | 1611 |Jay White 1612 | | 1613 |Microsoft 1614 | | 1615 |
| X 1618 | | 1619 |Jasmine Wang 1620 | | 1621 |Microsoft 1622 | | 1623 |
| X 1626 | | 1627 |David A. Wheeler 1628 | | 1629 |Linux Foundation 1630 | | 1631 |
| X 1634 | | 1635 |Melba-Lopez 1636 | | 1637 |IBM 1638 | | 1639 |
| X 1642 | | 1643 |Tom Bedford 1644 | | 1645 |Bloomberg LP 1646 | | 1647 |
| X 1650 | | 1651 |Adrian Diglio 1652 | | 1653 |1654 | | 1655 |