├── CODE_OF_CONDUCT.md ├── Community_Specification_License_v1.md ├── Contributing.md ├── Governance.md ├── LICENSE.md ├── Notices.md ├── README.md ├── SECURITY.md ├── Scope.md ├── calendar.md ├── images ├── 8-practices-white-bkg.png ├── Diagram-white-bkg.png ├── maturity-level-white-bkg.png └── secure-package-icon.png └── specification ├── Open_Source_Software_(OSS)_Secure_Supply_Chain_(SSC)_Framework.pdf ├── README.md └── framework.md /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # Microsoft Open Source Code of Conduct 2 | 3 | This project has adopted the [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/). 4 | 5 | Resources: 6 | 7 | - [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/) 8 | - [Microsoft Code of Conduct FAQ](https://opensource.microsoft.com/codeofconduct/faq/) 9 | - Contact [opencode@microsoft.com](mailto:opencode@microsoft.com) with questions or concerns 10 | -------------------------------------------------------------------------------- /Community_Specification_License_v1.md: -------------------------------------------------------------------------------- 1 | # Community Specification License 1.0 2 | 3 | **The Purpose of this License.** This License sets forth the terms under which 1) Contributor will participate in and contribute to the development of specifications, standards, best practices, guidelines, and other similar materials under this Working Group, and 2) how the materials developed under this License may be used. It is not intended for source code. Capitalized terms are defined in the License’s last section. 4 | 5 | **1. Copyright.** 6 | 7 | **1.1. Copyright License.** Contributor grants everyone a non-sublicensable, perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as expressly stated in this License) copyright license, without any obligation for accounting, to reproduce, prepare derivative works of, publicly display, publicly perform, and distribute any materials it submits to the full extent of its copyright interest in those materials. Contributor also acknowledges that the Working Group may exercise copyright rights in the Specification, including the rights to submit the Specification to another standards organization. 8 | 9 | **1.2. Copyright Attribution.** As a condition, anyone exercising this copyright license must include attribution to the Working Group in any derivative work based on materials developed by the Working Group. That attribution must include, at minimum, the material’s name, version number, and source from where the materials were retrieved. Attribution is not required for implementations of the Specification. 10 | 11 | **2. Patents.** 12 | 13 | **2.1. Patent License.** 14 | 15 | **2.1.1. As a Result of Contributions.** 16 | 17 | **2.1.1.1. As a Result of Contributions to Draft Specifications.** Contributor grants Licensee a non-sublicensable, perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as expressly stated in this License) license to its Necessary Claims in 1) Contributor’s Contributions and 2) to the Draft Specification that is within Scope as of the date of that Contribution, in both cases for Licensee’s Implementation of the Draft Specification, except for those patent claims excluded by Contributor under Section 3. 18 | 19 | **2.1.1.2. For Approved Specifications.** Contributor grants Licensee a non-sublicensable, perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as expressly stated in this License) license to its Necessary Claims included the Approved Specification that are within Scope for Licensee’s Implementation of the Approved Specification, except for those patent claims excluded by Contributor under Section 3. 20 | 21 | **2.1.2. Patent Grant from Licensee.** Licensee grants each other Licensee a non-sublicensable, perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as expressly stated in this License) license to its Necessary Claims for its Implementation, except for those patent claims excluded under Section 3. 22 | 23 | **2.1.3. Licensee Acceptance.** The patent grants set forth in Section 2.1 extend only to Licensees that have indicated their agreement to this License as follows: 24 | 25 | **2.1.3.1. Source Code Distributions.** For distribution in source code, by including this License in the root directory of the source code with the Implementation; 26 | 27 | **2.1.3.2. Non-Source Code Distributions.** For distribution in any form other than source code, by including this License in the documentation, legal notices, via notice in the software, and/or other written materials provided with the Implementation; or 28 | 29 | **2.1.3.3. Via Notices.md.** By issuing pull request or commit to the Specification’s repository’s Notices.md file by the Implementer’s authorized representative, including the Implementer’s name, authorized individual and system identifier, and Specification version. 30 | 31 | **2.1.4. Defensive Termination.** If any Licensee files or maintains a claim in a court asserting that a Necessary Claim is infringed by an Implementation, any licenses granted under this License to the Licensee are immediately terminated unless 1) that claim is directly in response to a claim against Licensee regarding an Implementation, or 2) that claim was brought to enforce the terms of this License, including intervention in a third-party action by a Licensee. 32 | 33 | **2.1.5. Additional Conditions.** This License is not an assurance (i) that any of Contributor’s copyrights or issued patent claims cover an Implementation of the Specification or are enforceable or (ii) that an Implementation of the Specification would not infringe intellectual property rights of any third party. 34 | 35 | **2.2. Patent Licensing Commitment.** In addition to the rights granted in Section 2.1, Contributor agrees to grant everyone a no charge, royalty-free license on reasonable and non-discriminatory terms to Contributor’s Necessary Claims that are within Scope for: 36 | 1) Implementations of a Draft Specification, where such license applies only to those Necessary Claims infringed by implementing Contributor's Contribution(s) included in that Draft Specification, and 37 | 2) Implementations of the Approved Specification. 38 | 39 | This patent licensing commitment does not apply to those claims subject to Contributor’s Exclusion Notice under Section 3. 40 | 41 | **2.3. Effect of Withdrawal.** Contributor may withdraw from the Working Group by issuing a pull request or commit providing notice of withdrawal to the Working Group repository’s Notices.md file. All of Contributor’s existing commitments and obligations with respect to the Working Group up to the date of that withdrawal notice will remain in effect, but no new obligations will be incurred. 42 | 43 | **2.4. Binding Encumbrance.** This License is binding on any future owner, assignee, or party who has been given the right to enforce any Necessary Claims against third parties. 44 | 45 | **3. Patent Exclusion.** 46 | 47 | **3.1. As a Result of Contributions.** Contributor may exclude Necessary Claims from its licensing commitments incurred under Section 2.1.1 by issuing an Exclusion Notice within 45 days of the date of that Contribution. Contributor may not issue an Exclusion Notice for any material that has been included in a Draft Deliverable for more than 45 days prior to the date of that Contribution. 48 | 49 | **3.2. As a Result of a Draft Specification Becoming an Approved Specification.** Prior to the adoption of a Draft Specification as an Approved Specification, Contributor may exclude Necessary Claims from its licensing commitments under this Agreement by issuing an Exclusion Notice. Contributor may not issue an Exclusion Notice for patents that were eligible to have been excluded pursuant to Section 3.1. 50 | 51 | **4. Source Code License.** Any source code developed by the Working Group is solely subject the source code license included in the Working Group’s repository for that code. If no source code license is included, the source code will be subject to the MIT License. 52 | 53 | **5. No Other Rights.** Except as specifically set forth in this License, no other express or implied patent, trademark, copyright, or other rights are granted under this License, including by implication, waiver, or estoppel. 54 | 55 | **6. Antitrust Compliance.** Contributor acknowledge that it may compete with other participants in various lines of business and that it is therefore imperative that they and their respective representatives act in a manner that does not violate any applicable antitrust laws and regulations. This License does not restrict any Contributor from engaging in similar specification development projects. Each Contributor may design, develop, manufacture, acquire or market competitive deliverables, products, and services, and conduct its business, in whatever way it chooses. No Contributor is obligated to announce or market any products or services. Without limiting the generality of the foregoing, the Contributors agree not to have any discussion relating to any product pricing, methods or channels of product distribution, division of markets, allocation of customers or any other topic that should not be discussed among competitors under the auspices of the Working Group. 56 | 57 | **7. Non-Circumvention.** Contributor agrees that it will not intentionally take or willfully assist any third party to take any action for the purpose of circumventing any obligations under this License. 58 | 59 | **8. Representations, Warranties and Disclaimers.** 60 | 61 | **8.1. Representations, Warranties and Disclaimers.** Contributor and Licensee represents and warrants that 1) it is legally entitled to grant the rights set forth in this License and 2) it will not intentionally include any third party materials in any Contribution unless those materials are available under terms that do not conflict with this License. IN ALL OTHER RESPECTS ITS CONTRIBUTIONS ARE PROVIDED "AS IS." The entire risk as to implementing or otherwise using the Contribution or the Specification is assumed by the implementer and user. Except as stated herein, CONTRIBUTOR AND LICENSEE EXPRESSLY DISCLAIM ANY WARRANTIES (EXPRESS, IMPLIED, OR OTHERWISE), INCLUDING IMPLIED WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT, FITNESS FOR A PARTICULAR PURPOSE, CONDITIONS OF QUALITY, OR TITLE, RELATED TO THE CONTRIBUTION OR THE SPECIFICATION. IN NO EVENT WILL ANY PARTY BE LIABLE TO ANY OTHER PARTY FOR LOST PROFITS OR ANY FORM OF INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER FROM ANY CAUSES OF ACTION OF ANY KIND WITH RESPECT TO THIS AGREEMENT, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDING NEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT THE OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Any obligations regarding the transfer, successors in interest, or assignment of Necessary Claims will be satisfied if Contributor or Licensee notifies the transferee or assignee of any patent that it knows contains Necessary Claims or necessary claims under this License. Nothing in this License requires Contributor to undertake a patent search. If Contributor is 1) employed by or acting on behalf of an employer, 2) is making a Contribution under the direction or control of a third party, or 3) is making the Contribution as a consultant, contractor, or under another similar relationship with a third party, Contributor represents that they have been authorized by that party to enter into this License on its behalf. 62 | 63 | **8.2. Distribution Disclaimer.** Any distributions of technical information to third parties must include a notice materially similar to the following: “THESE MATERIALS ARE PROVIDED “AS IS.” The Contributors and Licensees expressly disclaim any warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to the materials. The entire risk as to implementing or otherwise using the materials is assumed by the implementer and user. IN NO EVENT WILL THE CONTRIBUTORS OR LICENSEES BE LIABLE TO ANY OTHER PARTY FOR LOST PROFITS OR ANY FORM OF INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER FROM ANY CAUSES OF ACTION OF ANY KIND WITH RESPECT TO THIS DELIVERABLE OR ITS GOVERNING AGREEMENT, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDING NEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT THE OTHER MEMBER HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.” 64 | 65 | **9. Definitions.** 66 | 67 | **9.1. Affiliate.** “Affiliate” means an entity that directly or indirectly Controls, is Controlled by, or is under common Control of that party. 68 | 69 | **9.2. Approved Specification.** “Approved Specification” means the final version and contents of any Draft Specification designated as an Approved Specification as set forth in the accompanying Governance.md file. 70 | 71 | **9.3. Contribution.** “Contribution” means any original work of authorship, including any modifications or additions to an existing work, that Contributor submits for inclusion in a Draft Specification, which is included in a Draft Specification or Approved Specification. 72 | 73 | **9.4. Contributor.** “Contributor” means any person or entity that has indicated its acceptance of the License 1) by making a Contribution to the Specification, or 2) by entering into the Community Specification Contributor License Agreement for the Specification. Contributor includes its Affiliates, assigns, agents, and successors in interest. 74 | 75 | **9.5. Control.** “Control” means direct or indirect control of more than 50% of the voting power to elect directors of that corporation, or for any other entity, the power to direct management of such entity. 76 | 77 | **9.6. Draft Specification.** “Draft Specification” means all versions of the material (except an Approved Specification) developed by this Working Group for the purpose of creating, commenting on, revising, updating, modifying, or adding to any document that is to be considered for inclusion in the Approved Specification. 78 | 79 | **9.7. Exclusion Notice.** “Exclusion Notice” means a written notice made by making a pull request or commit to the repository’s Notices.md file that identifies patents that Contributor is excluding from its patent licensing commitments under this License. The Exclusion Notice for issued patents and published applications must include the Draft Specification’s name, patent number(s) or title and application number(s), as the case may be, for each of the issued patent(s) or pending patent application(s) that the Contributor is excluding from the royalty-free licensing commitment set forth in this License. If an issued patent or pending patent application that may contain Necessary Claims is not set forth in the Exclusion Notice, those Necessary Claims shall continue to be subject to the licensing commitments under this License. The Exclusion Notice for unpublished patent applications must provide either: (i) the text of the filed application; or (ii) identification of the specific part(s) of the Draft Specification whose implementation makes the excluded claim a Necessary Claim. If (ii) is chosen, the effect of the exclusion will be limited to the identified part(s) of the Draft Specification. 80 | 81 | **9.8. Implementation.** “Implementation” means making, using, selling, offering for sale, importing or distributing any implementation of the Specification 1) only to the extent it implements the Specification and 2) so long as all required portions of the Specification are implemented. 82 | 83 | **9.9. License.** “License” means this Community Specification License. 84 | 85 | **9.10. Licensee.** “Licensee” means any person or entity that has indicated its acceptance of the License as set forth in Section 2.1.3. Licensee includes its Affiliates, assigns, agents, and successors in interest. 86 | 87 | **9.11. Necessary Claims.** “Necessary Claims” are those patent claims, if any, that a party owns or controls, including those claims later acquired, that are necessary to implement the required portions (including the required elements of optional portions) of the Specification that are described in detail and not merely referenced in the Specification. 88 | 89 | **9.12. Specification.** “Specification” means a Draft Specification or Approved Specification included in the Working Group’s repository subject to this License, and the version of the Specification implemented by the Licensee. 90 | 91 | **9.13. Scope.** “Scope” has the meaning as set forth in the accompanying Scope.md file included in this Specification’s repository. Changes to Scope do not apply retroactively. If no Scope is provided, each Contributor’s Necessary Claims are limited to that Contributor’s Contributions. 92 | 93 | **9.14. Working Group.** “Working Group” means this project to develop specifications, standards, best practices, guidelines, and other similar materials under this License. 94 | 95 | 96 | 97 | *The text of this Community Specification License is Copyright 2020 Joint Development Foundation and is licensed under the Creative Commons Attribution 4.0 International License available at https://creativecommons.org/licenses/by/4.0/.* 98 | 99 | SPDX-License-Identifier: CC-BY-4.0 100 | -------------------------------------------------------------------------------- /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 | -------------------------------------------------------------------------------- /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) developed by the Working Group. Maintainers are also responsible for determining consensus and coordinating appeals. Each Working Group will designate one or more Maintainer for that Working Group. A Working Group may select a new or additional Maintainer(s) upon Approval of the Working Group Participants. 10 | 11 | **1.2. Editor.** “Editors” are responsible for ensuring that the contents of the document accurately reflect the decisions that have been made by the group, and that the specification adheres to formatting and content guidelines. Each Working Group will designate an Editor for that Working Group. A Working Group may select a new Editor upon Approval of the Working Group Participants. 12 | 13 | **1.3. Participants.** “Participants” are those that have made Contributions to the Working Group subject to the Community Specification License. 14 | 15 | ## 2. Decision Making. 16 | 17 | **2.1. Consensus-Based Decision Making.** Working Groups make decisions through a consensus process (“Approval” or “Approved”). While the agreement of all Participants is preferred, it is not required for consensus. Rather, the Maintainer will determine consensus based on their good faith consideration of a number of factors, including the dominant view of the Working Group Participants and nature of support and objections. The Maintainer will document evidence of consensus in accordance with these requirements. 18 | 19 | **2.2. Appeal Process.** Decisions may be appealed be via a pull request or an issue, and that appeal will be considered by the Maintainer in good faith, who will respond in writing within a reasonable time. 20 | 21 | ## 3. Ways of Working. 22 | 23 | Inspired by [ANSI’s Essential Requirements for Due Process](https://share.ansi.org/Shared%20Documents/Standards%20Activities/American%20National%20Standards/Procedures,%20Guides,%20and%20Forms/2020_ANSI_Essential_Requirements.pdf), Community Specification Working Groups must adhere to consensus-based due process requirements. These requirements apply to activities related to the development of consensus for approval, revision, reaffirmation, and withdrawal of Community Specifications. Due process means that any person (organization, company, government agency, individual, etc.) with a direct and material interest has a right to participate by: a) expressing a position and its basis, b) having that position considered, and c) having the right to appeal. Due process allows for equity and fair play. The following constitute the minimum acceptable due process requirements for the development of consensus. 24 | 25 | **3.1. Openness.** Participation shall be open to all persons who are directly and materially affected by the activity in question. There shall be no undue financial barriers to participation. Voting membership on the consensus body shall not be conditional upon membership in any organization, nor unreasonably restricted on the basis of technical qualifications or other such requirements. Membership in a Working Group’s parent organization, if any, may be required. 26 | 27 | **3.2. Lack of Dominance.** The development process shall not be dominated by any single interest category, individual or organization. Dominance means a position or exercise of dominant authority, leadership, or influence by reason of superior leverage, strength, or representation to the exclusion of fair and equitable consideration of other viewpoints. 28 | 29 | **3.3. Balance.** The development process should have a balance of interests. Participants from diverse interest categories shall be sought with the objective of achieving balance. 30 | 31 | **3.4. Coordination and Harmonization.** Good faith efforts shall be made to resolve potential conflicts between and among deliverables developed under this Working Group and existing industry standards. 32 | 33 | **3.5. Consideration of Views and Objections.** Prompt consideration shall be given to the written views and objections of all Participants. 34 | 35 | **3.6. Written procedures.** This governance document and other materials documenting the Community Specification development process shall be available to any interested person. 36 | 37 | ## 4. Specification Development Process. 38 | 39 | **4.1. Pre-Draft.** Any Participant may submit a proposed initial draft document as a candidate Draft Specification of that Working Group. The Maintainer will designate each submission as a “Pre-Draft” document. 40 | 41 | **4.2. Draft.** Each Pre-Draft document of a Working Group must first be Approved to become a” Draft Specification”. Once the Working Group approves a document as a Draft Specification, the Draft Specification becomes the basis for all going forward work on that specification. 42 | 43 | **4.3. Working Group Approval.** Once a Working Group believes it has achieved the objectives for its specification as described in the Scope, it will Approve that Draft Specification and progress it to “Approved Specification” status. 44 | 45 | **4.4. Publication and Submission.** Upon the designation of a Draft Specification as an Approved Specification, the Maintainer will publish the Approved Specification in a manner agreed upon by the Working Group Participants (i.e., Working Group Participant only location, publicly available location, Working Group maintained website, Working Group member website, etc.). The publication of an Approved Specification in a publicly accessible manner must include the terms under which the Approved Specification is being made available under. 46 | 47 | **4.5. Submissions to Standards Bodies.** No Draft Specification or Approved Specification may be submitted to another standards development organization without Working group Approval. Upon reaching Approval, the Maintainer will coordinate the submission of the applicable Draft Specification or Approved Specification to another standards development organization. Working Group Participants that developed that Draft Specification or Approved Specification agree to grant the copyright rights necessary to make those submissions. 48 | 49 | ## 5. Non-Confidential, Restricted Disclosure. 50 | 51 | Information disclosed in connection with any Working Group activity, including but not limited to meetings, Contributions, and submissions, is not confidential, regardless of any markings or statements to the contrary. Notwithstanding the foregoing, if the Working Group is collaborating via a private repository, the Participants will not make any public disclosures of that information contained in that private repository without the Approval of the Working Group. 52 | -------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | # Licenses 2 | 3 | ## Specification License 4 | 5 | Specifications in the repository are subject to the **Community Specification License 1.0** available at [https://github.com/CommunitySpecification/1.0](https://github.com/CommunitySpecification/1.0). 6 | 7 | ## Source Code License 8 | 9 | If source code is included in this repository, or for sample or reference code included in the specification itself, that code is subject to the MIT license unless otherwise designated. In the case of any conflict or confusion within this specification repository between the Community Specification License and the MIT or other designated license, the terms of the Community Specification License shall apply. 10 | 11 | If source code is included in this repository, or for sample or reference code included in the specification itself, that code is subject to the MIT license unless otherwise marked. 12 | 13 | In the case of any conflict or confusion within this specification repository between the Community Specification License and the designated source code license, the terms of the Community Specification License shall apply. 14 | -------------------------------------------------------------------------------- /Notices.md: -------------------------------------------------------------------------------- 1 | # Notices 2 | 3 | ## Code of Conduct 4 | 5 | Contact for Code of Conduct issues or inquires: [opencode@microsoft.com](mailto:opencode@microsoft.com) 6 | 7 | 8 | ## License Acceptance 9 | 10 | Per Community Specification License 1.0 Section 2.1.3.3, Licensees may indicate their acceptance of the Community Specification License by issuing a pull request to the Specification’s repository’s Notice.md file, including the Licensee’s name, authorized individuals' names, and repository system identifier (e.g. GitHub ID), and specification version. 11 | 12 | A Licensee may consent to accepting the current Community Specification License version or any future version of the Community Specification License by indicating "or later" after their specification version. 13 | 14 | --------------------------------------------------------------------------------- 15 | 16 | Licensee’s name: 17 | 18 | Authorized individual and system identifier: 19 | 20 | Specification version: 21 | 22 | --------------------------------------------------------------------------------- 23 | 24 | ## Withdrawals 25 | 26 | Name of party withdrawing: 27 | 28 | Date of withdrawal: 29 | 30 | --------------------------------------------------------------------------------- 31 | 32 | ## Exclusions 33 | 34 | This section includes any Exclusion Notices made against a Draft Deliverable or Approved Deliverable as set forth in the Community Specification Development License. Each Exclusion Notice must include the following information: 35 | 36 | - Name of party making the Exclusion Notice: 37 | 38 | - Name of patent owner: 39 | 40 | - Specification: 41 | 42 | - Version number: 43 | 44 | **For issued patents and published patent applications:** 45 | 46 | (i) patent number(s) or title and application number(s), as the case may be: 47 | 48 | (ii) identification of the specific part(s) of the Specification whose implementation makes the excluded claim a Necessary Claim. 49 | 50 | **For unpublished patent applications must provide either:** 51 | 52 | (i) the text of the filed application; or 53 | 54 | (ii) identification of the specific part(s) of the Specification whose implementation makes the excluded claim a Necessary Claim. 55 | 56 | ----------------------------------------------------------------------------------------- 57 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Open Source Software (OSS) Secure Supply Chain (SSC) Framework 2 | 3 | THIS REPO HAS BEEN CONTRIBUTED TO THE OPENSSF. THE NEW REPO IS HERE [https://github.com/ossf/s2c2f/](https://github.com/ossf/s2c2f/). 4 | 5 | secure package icon 6 | 7 | ## Overview 8 | This guide 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. 9 | 10 | The OSS SSC Framework is complete with: 11 | 12 | * A high-level solution-agnostic set of practices 13 | * A detailed list of requirements 14 | * A list of real-world supply chain threats specific to OSS, and how our Framework requirements mitigates them 15 | * A maturity model-based implementation guide, with links to tools from across the industry 16 | * A process for assessing your organization’s maturity 17 | * A mapping of the Framework requirements to 6 other supply chain specifications 18 | 19 | ## View or Download the OSS SSC Framework Specification 20 | 21 | > ⭐: **Click 22 | > _[here](./specification/Open_Source_Software_(OSS)_Secure_Supply_Chain_(SSC)_Framework.pdf)_ for the PDF of the specification** 23 | > 24 | > :atom:: **Click _[here](./specification/framework.md)_ to view the specification in markdown** 25 | 26 | ## Contributing 27 | 28 | The general Community Specification Contributing Policy is captured on the [Contributing](Contributing.md) section. Specific guidelines based on the policy for how best to contribute to the OSS SSC Framework specification is [here](./specification/README.md). The living OSS SSC Framework is captured in [markdown](./specification/framework.md) and is where all updates will take place. 29 | 30 | *SLA to Triage Issues*: 31 | - The OSS SSC Framework working group will review, triage, and respond to issues during each Community Meeting. 32 | 33 | ## Meeting Times 34 | 35 | *Community and Technical Meetings*: 36 | - iCal Subscription Link 37 | 38 | - OSS SSC Framework community meetings are held the 3rd Tuesday of every month @ 12:00 PM Pacific. Please click the iCal Subscription link above or email adrian.diglio@microsoft.com to be added to the meeting invitation. 39 | 40 | *Technical Meetings*: 41 | - OSS SSC Framework technical meetings are held the last Monday of every month @ 2:00 PM Pacific. Please click the iCal Subscription link above or email adrian.diglio@microsoft.com to be added to the meeting invitation. 42 | 43 | [Meeting minutes and agenda](https://docs.google.com/document/d/1YG-CVbKa7pVlNNkLAOV8O7kiY5mBoFXpehc1VOW0MW4) 44 | 45 | *Chat channels*: 46 | 47 | - We have a Slack channel on the OpenSSF Slack instance: Slack Channel 48 | Slack Invite 49 | -------------------------------------------------------------------------------- /SECURITY.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | ## Security 4 | 5 | Microsoft takes the security of our software products and services seriously, which includes all source code repositories managed through our GitHub organizations, which include [Microsoft](https://github.com/Microsoft), [Azure](https://github.com/Azure), [DotNet](https://github.com/dotnet), [AspNet](https://github.com/aspnet), [Xamarin](https://github.com/xamarin), and [our GitHub organizations](https://opensource.microsoft.com/). 6 | 7 | If you believe you have found a security vulnerability in any Microsoft-owned repository that meets [Microsoft's definition of a security vulnerability](https://aka.ms/opensource/security/definition), please report it to us as described below. 8 | 9 | ## Reporting Security Issues 10 | 11 | **Please do not report security vulnerabilities through public GitHub issues.** 12 | 13 | Instead, please report them to the Microsoft Security Response Center (MSRC) at [https://msrc.microsoft.com/create-report](https://aka.ms/opensource/security/create-report). 14 | 15 | If you prefer to submit without logging in, send email to [secure@microsoft.com](mailto:secure@microsoft.com). If possible, encrypt your message with our PGP key; please download it from the [Microsoft Security Response Center PGP Key page](https://aka.ms/opensource/security/pgpkey). 16 | 17 | You should receive a response within 24 hours. If for some reason you do not, please follow up via email to ensure we received your original message. Additional information can be found at [microsoft.com/msrc](https://aka.ms/opensource/security/msrc). 18 | 19 | Please include the requested information listed below (as much as you can provide) to help us better understand the nature and scope of the possible issue: 20 | 21 | * Type of issue (e.g. buffer overflow, SQL injection, cross-site scripting, etc.) 22 | * Full paths of source file(s) related to the manifestation of the issue 23 | * The location of the affected source code (tag/branch/commit or direct URL) 24 | * Any special configuration required to reproduce the issue 25 | * Step-by-step instructions to reproduce the issue 26 | * Proof-of-concept or exploit code (if possible) 27 | * Impact of the issue, including how an attacker might exploit the issue 28 | 29 | This information will help us triage your report more quickly. 30 | 31 | If you are reporting for a bug bounty, more complete reports can contribute to a higher bounty award. Please visit our [Microsoft Bug Bounty Program](https://aka.ms/opensource/security/bounty) page for more details about our active programs. 32 | 33 | ## Preferred Languages 34 | 35 | We prefer all communications to be in English. 36 | 37 | ## Policy 38 | 39 | Microsoft follows the principle of [Coordinated Vulnerability Disclosure](https://aka.ms/opensource/security/cvd). 40 | 41 | 42 | -------------------------------------------------------------------------------- /Scope.md: -------------------------------------------------------------------------------- 1 | ## Scope 2 | 3 | This guide outlines and defines how to securely consume Open Source Software (OSS) dependencies into the developer's workflow. 4 | -------------------------------------------------------------------------------- /calendar.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: page 3 | title: Calendar 4 | weight: 98 5 | --- 6 | 7 | 8 | -------------------------------------------------------------------------------- /images/8-practices-white-bkg.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/microsoft/oss-ssc-framework/165ba893f2080e75bc69acaa6ea3fc8550315738/images/8-practices-white-bkg.png -------------------------------------------------------------------------------- /images/Diagram-white-bkg.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/microsoft/oss-ssc-framework/165ba893f2080e75bc69acaa6ea3fc8550315738/images/Diagram-white-bkg.png -------------------------------------------------------------------------------- /images/maturity-level-white-bkg.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/microsoft/oss-ssc-framework/165ba893f2080e75bc69acaa6ea3fc8550315738/images/maturity-level-white-bkg.png -------------------------------------------------------------------------------- /images/secure-package-icon.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/microsoft/oss-ssc-framework/165ba893f2080e75bc69acaa6ea3fc8550315738/images/secure-package-icon.png -------------------------------------------------------------------------------- /specification/Open_Source_Software_(OSS)_Secure_Supply_Chain_(SSC)_Framework.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/microsoft/oss-ssc-framework/165ba893f2080e75bc69acaa6ea3fc8550315738/specification/Open_Source_Software_(OSS)_Secure_Supply_Chain_(SSC)_Framework.pdf -------------------------------------------------------------------------------- /specification/README.md: -------------------------------------------------------------------------------- 1 | # Maintaining the OSS SSC Framework Specification 2 | 3 | > ⭐: **Click 4 | > _[here](Open_Source_Software_(OSS)_Secure_Supply_Chain_(SSC)_Framework.pdf)_ for the PDF of the specification** 5 | 6 | ## Updates to the specification 7 | 8 | The OSS SSC Framework specification is intended to be a living document 9 | created and maintained for the community by its members. 10 | 11 | Updates to the whitepaper, suggestions for updates, or discussion for updates 12 | should initiate with an [issue](https://github.com/microsoft/oss-ssc-framework/issues) 13 | submitted to the repo and labeled with "discussion" and "specification". 14 | 15 | ### Markdown 16 | 17 | The living OSS SSC Framework is captured in [markdown](framework.md) and is where all updates will take place. 18 | 19 | ### Contributing updates 20 | 21 | All members of the community are welcome to contribute updates to the OSS SSC Framework specification. We 22 | ask potential contributors to refer to the original design decisions, listed 23 | below, as guidance when determining the content of their updates. 24 | 25 | It is highly recommended that you seek peer review for your updates beyond that 26 | of the Technical Leads of the working group. 27 | 28 | After the issue has been triaged in the community call, and has been tagged with "Spec Change", the next step is to submit a PR to the [markdown](framework.md) with the proposed changes. Once the PR is submitted, please link the PR to the issue to request a review. 29 | 30 | ### Versioning and publishing 31 | 32 | It is expected that many minor updates will occur, corrections to grammar, 33 | spelling, clarification in language, translations, etc. When these occur they 34 | are considered minor changes to the overall content and will not warrant the 35 | regeneration of the PDF. 36 | 37 | When significant changes to the intent, content, or numerous minor changes 38 | occur, the OSS SSC Framework working group will assess and determine if a new major version 39 | of the PDF needs to be published. When this decision is made, the markdown content 40 | will be converted to text document and sent to the OSS SSC Framework technical writers to 41 | create the PDF. The PDF will then be published back into the repository 42 | annotating the new version, updating the links in the README.md accordingly. 43 | 44 | Minor updates to the markdown shall receive a minor version bump indicated in 45 | the Metadata table of the document and recorded as WIP. When enough significant 46 | changes have been recorded, the markdown will be placed "In Review" (via PR) and 47 | solicited to the OSS SSC Framework mailing list for review, at a 48 | minimum. 49 | 50 | Upon completion of review, the OSS SSC Framework technical writer shall provide final 51 | approval on the PR. At which point the markdown state will be changed to 52 | "Approved" and merged. 53 | 54 | ## Original design decisions 55 | 56 | The OSS SSC Framework creation occurred using the below general design decisions which 57 | should be considered when updating the content. 58 | 59 | * Consider if the content already exists elsewhere. Provide references to 60 | comprehensive information on a topic rather than re-writing the content. This 61 | not only allows us to provide summarization of complex topics, but also 62 | exposes the audience to other avenues of information for which they may be 63 | unaware. 64 | * Determine if the content is better suited as it's own document, such as a 65 | how-to, blog, or whitepaper of itself. 66 | * Determine if your suggestion belongs in the high-level solution-agnostic set of Practices - which can be used in any scenario - or if your suggestion is more of a detailed implementation-level requirement. 67 | * Identify if the proposed requirement is realistic or aspirational. Suggest a level of maturity that fits with the themes for each maturity level. 68 | -------------------------------------------------------------------------------- /specification/framework.md: -------------------------------------------------------------------------------- 1 | secure package icon 2 | 3 | # Open Source Software (OSS) Secure Supply Chain (SSC) Framework 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 | * [Document Change Record](#document-change-record) 16 | * [Introduction](#introduction) 17 | * [About the OSS SSC Framework](#about-the-oss-ssc-framework) 18 | * [What is the OSS SSC Framework?](#what-is-the-oss-ssc-framework) 19 | * [Common OSS Supply Chain Threats](#common-oss-supply-chain-threats) 20 | * [OSS SSC Framework Practices](#oss-ssc-framework-practices) 21 | * [Target Audience](#target-audience) 22 | * [OSS SSC Framework Practices](#oss-ssc-framework-practices-1) 23 | * [The OSS SSC Framework Implementation Guide](#the-oss-ssc-framework-implementation-guide) 24 | * [Target Audience](#target-audience-1) 25 | * [OSS SSC Framework Levels of Maturity](#oss-ssc-framework-levels-of-maturity) 26 | * [How to Assess Where Your Organization is in the Maturity Model?](#how-to-assess-where-your-organization-is-in-the-maturity-model) 27 | * [OSS SSC Framework Requirements](#oss-ssc-framework-requirements) 28 | * [OSS SSC Framework Tooling Availability](#oss-ssc-framework-tooling-availability) 29 | * [Implementing the OSS SSC Framework by Level](#implementing-the-oss-ssc-framework-by-level) 30 | * [Conclusion](#conclusion) 31 | * [Appendix: Relation to SCITT](#Appendix-Relation-to-SCITT) 32 | * [Appendix: Mapping OSS SSC Framework Requirements to Other Specifications](#Appendix-Mapping-OSS-SSC-Framework-Requirements-to-Other-Specifications) 33 | * [Appendix: References](#Appendix-References) 34 | 35 | # Document Change Record 36 | 37 | | Date | Author | Version | Change Reference | 38 | | --- | --- | --- | --- | 39 | | 8/1/2022 | Adrian Diglio (Microsoft) | 1.0 | Initial release | 40 | | 9/28/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). Replaced references to "Microsoft OSS SSC Framework" with "OSS SSC Framework." | 41 | 42 | # Introduction 43 | 44 | The purpose of this paper is to illustrate the core concepts of the Open Source Software (OSS) Secure Supply Chain (SSC) Framework 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. 45 | 46 | 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. 47 | 48 | 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. 49 | 50 | This paper presents: 51 | 52 | - An overview of the OSS SSC Framework Practices. 53 | - Common supply chain threats with examples and how OSS SSC Framework can help. 54 | - An overview of the OSS SSC Framework Implementation Guide and Maturity Model. 55 | - A process for assessing your organization's maturity. 56 | - Detailed walkthrough of the OSS SSC Framework implementation requirements and tools. 57 | - A mapping of the OSS SSC Framework requirements to other specifications. 58 | 59 | 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. 60 | 61 | # About the OSS SSC Framework 62 | 63 | The OSS SSC Framework is a security assurance and risk reduction process that is focused on securing how developers consume open source software. As a Microsoft-wide initiative since 2019, the OSS SSC Framework 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 across Microsoft. Using a threat-based risk-reduction approach, the goals of the OSS SSC Framework are to: 64 | 65 | 1. Provide a strong OSS governance program 66 | 2. Improve the Mean Time To Remediate (MTTR) for resolving known vulnerabilities in OSS 67 | 3. Prevent the consumption of compromised and malicious OSS packages 68 | 69 | The OSS SSC Framework (described later in this document) is modeled after three core concepts—_control all artifact inputs, continuous process improvement, and scale._ 70 | 71 |

72 | framework diagram 73 |

74 | 75 | - _Control All Artifact Inputs_: There are a myriad of ways that developers consume OSS today: git clone, wget, copy & pasted source, checking-in the binary into the repo, direct from public package managers, repackaging the OSS into a .zip, curl, apt-get, git submodule, and more. Securing the OSS supply chain in any organization is going to be near impossible if developer teams don't follow a uniform process for consuming OSS. Enforcing an effective secure OSS supply chain strategy necessitates standardizing your OSS consumption process across the various developer teams throughout your organization, so all developers consume OSS using governed workflows. 76 | - _Continuous Process Improvement_: To help guide organizations through continuous process improvement, we have organized the OSS SSC Framework into a maturity model. This helps organizations prioritize which requirements they should implement first. Since security risk is dynamic and new threats can emerge at any time, the OSS SSC Framework places heavy emphasis on understanding the new threats to the OSS supply chain and _requires_ regular evaluation of OSS SSC Frameworkcontrols and introduction of changes in response to new technology advancements or new threats. 77 | - _Scale_:The OSS SSC Framework tools were designed with scale in mind. Some organizations may attempt to secure their OSS ingestion process through a central internal registry that all developers within the organization are supposed to pull from. However, what if one developer chooses to pull straight from pypi.org or npmjs.com? Is there anything preventing them from doing so? A central internal registry also has the problem of requiring a team to manage the process and workflow, which is extra overhead. As such, the OSS SSC Framework tools were developed to secure how they consume OSS today at scale without requiring a central internal registry or central governance body. 78 | 79 | # What is the OSS SSC Framework? 80 | 81 | The OSS SSC Framework is a combination of requirements and tools for any organization to adopt. The Framework includes a capability maturity roadmap to help establish a secure OSS ingestion process to protect developers from OSS supply chain threats and to establish a strong governance program to manage your organization's use of OSS. 82 | 83 | # Common OSS Supply Chain Threats 84 | 85 | The OSS SSC Framework was designed based on known threats (i.e. tactics and techniques) used by adversaries to compromise OSS packages. The table below is a comprehensive compilation of OSS supply chain threats with links to real examples. It also identifies which OSS SSC Framework requirements mitigate the threat. To see the full list of requirements and their benefits, please see the [OSS SSC Framework Requirements](#oss-ssc-framework-requirements) later in this document. 86 | 87 | For other sources of OSS threats, please see the following links: 88 | 89 | - [Threats, Risks, and Mitigations in the Open Source Ecosystem](https://github.com/ossf/wg-identifying-security-threats/blob/main/publications/threats-risks-mitigations/v1.1/Threats%2C%20Risks%2C%20and%20Mitigations%20in%20the%20Open%20Source%20Ecosystem%20-%20v1.1.pdf) 90 | - [Taxonomy of Attacks on Open-Source Software Supply Chains](https://arxiv.org/pdf/2204.04008.pdf) 91 | - [Software Supply Chain Threats](https://cloud.google.com/software-supply-chain-security/docs/attack-vectors) 92 | 93 | | **OSS Supply Chain Threat** | **Real Example** | **Mitigation via OSS SSC Framework Requirement** | 94 | | --- | --- | --- | 95 | | Accidental vulnerabilities in OSS code or Containers that we inherit | [SaltStack](https://www.helpnetsecurity.com/2020/05/04/saltstack-salt-vulnerabilities/) | UPD-2
UPD-3 | 96 | | Intentional vulnerabilities/backdoors added to an OSS code base | [phpMyAdmin](https://arstechnica.com/information-technology/2012/09/questions-abound-as-malicious-phpmyadmin-backdoor-found-on-sourceforge-site/) | SCA-5 | 97 | | 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 | 98 | | 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 | 99 | | 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 | 100 | | 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 | 101 | | 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 | 102 | | 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 | 103 | | 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 | 104 | | 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 | 105 | | Vulnerability not fixed by upstream maintainer in desired timeframe | [Prototype Pollution in Lodash](https://hackerone.com/reports/712065) | FIX-1 | 106 | | 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 | 107 | 108 | # OSS SSC Framework Practices 109 | 110 | ## Target Audience 111 | 112 | 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). 113 | 114 | ## OSS SSC Framework Practices 115 | 116 | ### _Practice 1: Ingest It_ 117 | 118 | _I can ship any existing asset if external OSS sources are compromised or unavailable._ 119 | 120 | **Sample threat scenarios addressed by this job:** 121 | 122 | - The Docker Hub repository becomes compromised 123 | - A team might be targeted by a dependency confusion attack 124 | - Azure itself is unavailable and we need access to OSS assets to restore it 125 | - A package becomes permanently unavailable (i.e. left-pad is removed) 126 | 127 | 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. 128 | 129 | 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)). 130 | 131 | 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: 132 | 133 | - 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 134 | - Enables proactive security scans to look for backdoors and zero-day vulnerabilities 135 | - Enables your organization to contribute fixes back upstream 136 | - Enables your organization to perform fixes if needed (in extreme circumstances) 137 | 138 | ### _Practice 2: Scan It_ 139 | 140 | _I know if any OSS artifact in my pipeline has vulnerabilities or malware._ 141 | 142 | **Sample threat scenarios addressed by this job:** 143 | 144 | - A team tries to use an OSS package with a known vulnerability 145 | - A team is already using an OSS package believed to be secure, but a new vulnerability in that package is later publicly disclosed 146 | - A team tries to use an OSS package that is known to steal bitcoins (i.e. the _event-stream_ scenario) 147 | - A team tries to use an OSS package with a backdoor 148 | 149 | 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, and other known or previously undiscovered issues (i.e. zero-day vulnerabilities). 150 | 151 | ### _Practice 3: Inventory It_ 152 | 153 | _I know where OSS artifacts are deployed in production._ 154 | 155 | **Sample threat scenarios addressed by this job:** 156 | 157 | - 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 158 | 159 | Once we have ingested and scanned the artifacts entering the software supply chain, we must ensure that we have an inventory whereeach 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. 160 | 161 | ### _Practice 4: Update It_ 162 | 163 | _I can deploy updated external artifacts soon after an update becomes publicly available._ 164 | 165 | **Sample threat scenarios addressed by this job:** 166 | 167 | - 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. 168 | 169 | Once we have ingested, scanned, and inventoried whereeach 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. 170 | 171 | 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. 172 | 173 | ### _Practice 5: Audit It_ 174 | 175 | _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._ 176 | 177 | **Sample threat scenarios addressed by this job:** 178 | 179 | - 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 180 | - An attacker with network access intentionally bypasses the official engineering pipeline to deploy malware to a service 181 | 182 | 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. 183 | 184 | ### _Practice 6: Enforce It_ 185 | 186 | _I can rely on secure and trusted OSS consumption within my organization._ 187 | 188 | **Sample threat scenarios addressed by this job:** 189 | 190 | - A developer bypasses the official engineering pipeline to consume an OSS package with a known vulnerability 191 | 192 | All OSS artifacts must be consumed from trusted 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. 193 | 194 | ### _Practice 7: Rebuild It_ 195 | 196 | _I can rebuild from source code every OSS artifact I'm deploying._ 197 | 198 | **Sample threat scenarios addressed by this job:** 199 | 200 | - 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. 201 | - 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. 202 | 203 | 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. 204 | 205 | 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/)). 206 | 207 | ### _Practice 8: Fix It + Upstream_ 208 | 209 | _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._ 210 | 211 | **Sample threat scenarios addressed by this job:** 212 | 213 | - 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 214 | 215 | **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_. 216 | 217 | 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. 218 | 219 | Related to the note below, the implemented fix should be confidentially contributed to the upstream maintainer to give back to the community. 220 | 221 | 222 | > **📝 Important Note** 223 | > 224 | > 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: 225 | > - Financial support and participating in foundations or even individual projects: [GitHub Sponsors](https://github.com/sponsors), [OpenCollective](https://opencollective.com/become-a-sponsor), etc. 226 | > - Bounty programs (such as [SOS Rewards](https://sos.dev/)) and sharing best practices and tools with projects around security 227 | > - Being present and participating in key open source projects to share fixes or expertise 228 | > - 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) 229 | 230 | # The OSS SSC Framework Implementation Guide 231 | 232 | ## Target Audience 233 | 234 | 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. 235 | 236 | ## OSS SSC Framework Levels of Maturity 237 | 238 | When the OSS SSC Framework was first developed, the strategy to secure our OSS supply chain was comprised of 8 practices. 239 | 240 |

241 | list of practices 242 |

243 | 244 | Since all 8 practices cannot be reasonably implemented at the same time, the following maturity model organizes the requirements from each of the 8 practices into 4 different levels. It allows an organization to make incremental progress from their existing set of security capabilities toward a more secure defensive posture. Additionally, the maturity model considers different threats and themes at each Maturity Level. 245 | 246 | Depending on the projects and their criteria, you may have a mix of framework levels implemented across projects. Additionally, Level 4 of the Maturity Model has a high estimated cost to implement compared to the risk/reward, and therefore should be considered as an aspirational north star vision for your organization. While it is difficult to implement Level 4 at scale across your organization, it is feasible to implement Level 4 on your most critical dependencies for your most critical projects. 247 | 248 |

249 | list of practices 250 |

251 | 252 | **Level 1** – Using a package caching solution, performing an OSS inventory, plus scanning and updating OSS represents the most common set of OSS security capabilities across the software industry today. 253 | 254 | **Level 2** – This maturity level focuses on shifting security further left by improving ingestion configuration security, decreasing MTTR to patch OSS vulnerabilities, and responding to incidents. The SaltStack vulnerability in 2020 showed us that adversaries were able to start exploiting CVE-2020-11651 within 3 days of it being announced. Even though a patch was available, organizations were not able to patch their systems fast enough. Thus, a key component of this level leverages automation to help developers keep their OSS hygiene healthy and updated. The ideal goal is for organizations to be able to patch faster than attackers can operate. 255 | 256 | **Level 3** – Proactively performing security analysis on your organization's most used OSS components and reducing risk to consume malicious packages are the themes of this maturity level. Scanning for malware in OSS before the package is downloaded is key toward preventing compromise. Then, to perform proactive security reviews of OSS requires that an organization can clone the source code to an internal location. Proactive security reviews help you look for the not-yet-discovered vulnerabilities, as well as identifying other threat categories such as detecting backdoors. 257 | 258 | **Level 4** – This level is considered aspirational in most cases. Rebuilding OSS on trusted build infrastructure is a defensive step to ensure that the OSS was not compromised at build time. Build time attacks are performed by the most sophisticated adversaries and do not occur very frequently. Thus, this level of maturity is what's required to defend against the most sophisticated adversaries. Additionally, rebuilding OSS has many subtle technical challenges such as what to name the package to prevent collisions with upstream? How to make sure all developers use the internal package instead of the external? Rebuilding also enables you to implement fixes (if needed) and deploy them at scale across your organization. 259 | 260 | ## How to Assess Where Your Organization is in the Maturity Model? 261 | 262 | Any maturity assessment should be done at the Organization level, so that it assesses multiple different OSS consumption processes from across different development teams. Some teams may have more mature processes than others, even within a single organization, so it's best to perform a company-wide assessment to determine OSS consumption practices across a diverse set of software development teams. The steps to perform a Maturity Assessment are below: 263 | 264 | 1. **Prepare for Assessment**. The first step is to understand the concepts behind the OSS SSC Framework so you feel comfortable engaging with developers and engineers to inquire about their existing tools, capabilities, and workflows. Next, identify a good sample size of diverse development teams from across the company to interview. 265 | 2. **Perform the Assessment**. This is where you assess the organization's degree of maturity in software developer OSS management, security, and consumption processes. Here are a set of example questions that you can ask: 266 | 1. What type of OSS do you consume in your project?(e.g. native C/C++, NuGet, PyPI, npm, etc.) 267 | 2. How are you consuming your OSS into your project? (e.g. Using a Package Cache solution such as Azure Artifacts, commands such as curl or git clone, checking in the OSS into the repo, etc.) 268 | 3. Where do you consume your OSS from? (e.g. NuGet.org, npmjs.com, pypi.org, etc.) 269 | 4. Do you use a mix of internal-only packages and external packages? (_This can make you susceptible to Dependency Confusion attacks_) 270 | 5. Does your package source file (e.g. nuget.config, pom.xml, pip.conf, etc.) contain multiple feeds in its configuration? (_This can make you susceptible to Dependency Confusion attacks_) 271 | 6. Do you do anything custom with how you consume OSS? (e.g. consuming private forks of projects, putting Golang components into a NuGet, etc.) 272 | 7. Does your project use package lock files? (e.g. [packages.lock.json](https://devblogs.microsoft.com/nuget/enable-repeatable-package-restores-using-a-lock-file/) for NuGet, [package-lock.json](https://docs.npmjs.com/cli/v7/configuring-npm/package-lock-json) for NPM, etc.) 273 | 8. How does your team inventory the use of OSS within your project? What tools are used? 274 | 9. How is your team made aware when a vulnerability exists in an OSS component? What tool is used? 275 | 10. At what point in the Software Development Lifecycle (SDLC) are OSS vulnerabilities surfaced? (e.g. after release? During build? As comments in PRs?) 276 | 11. How fast is OSS updated to address known vulnerabilities? (e.g. what is the Mean Time To Remediate) 277 | 12. Is updating OSS a manual or automated process? (e.g. using Dependabot) 278 | 13. Do you perform integration tests of how your software interfaces with the dependencies you have to validate that there are no breaking changes? 279 | 14. Do you scan OSS for malware prior to use? 280 | 15. Is your team able to block ingestion of a known-bad/malicious package? 281 | 16. Does your team clone open source code internally? 282 | 17. Does your team perform any sort of security reviews or scans of OSS before using? 283 | 18. Does your team contribute bug fixes back to the upstream OSS maintainer? 284 | 19. Do you rebuild any of the open source internally? 285 | 20. Do you have an incident response plan or playbook for reacting to an incident of consuming a malicious OSS component? 286 | 287 | 1. **Plan for Improvements.** Based on the interviews and answers you received from across your organization, you should be able to determine where you fall within the OSS SSC Framework Maturity Levels. It's possible that some teams may be ahead of others, so your focus should be on elevating all development teams to a specific Maturity Level. It's suggested that you accomplish this by driving standardization in both process and tooling across your software development teams for consuming OSS. 288 | 289 | The OSS SSC Framework categorizes its requirements into maturity levels to better help you prioritize investments in improvements. Additionally, the OSS SSC Framework recommends tooling with specific capabilities that mitigates against the known supply chain threats, but you probably should make business decisions about which set of tools are right for your business and your security goals. 290 | 291 | ## OSS SSC Framework Requirements 292 | 293 | Below is a table of the requirements mapped to the 8 different practices. Two of the requirements have prerequisites identified that are outside the scope of this document to list as requirements. 294 | 295 | | **Practice** | **Requirement ID** | **Maturity Level** | **Requirement Title** | **Benefit** | 296 | | --- | --- | --- | --- | --- | 297 | | *Ingest it* | ING-1 | L1 | Use package managers trusted by your organization | Your organization benefits from the inherent security provided by the package manager | 298 | | | ING-2 | L1 | Use an OSS binary repository manager solution | Caches a local copy of the OSS artifact and protects against [left-pad](https://www.theregister.com/2016/03/23/npm_left_pad_chaos/) incidents, enabling developers to continue to build even if upstream resources are unavailable | 299 | | | ING-3 | L2 | Have a Deny List capability to block known malicious OSS from being consumed | Prevents ingestion of known malware by blocking ingestion as soon as a critically vulnerable OSS component is identified, such as [colors v 1.4.1](https://security.snyk.io/vuln/SNYK-JS-COLORS-2331906), or if an OSS component is deemed malicious | 300 | | | ING-4 | L3 | Mirror a copy of all OSS source code to an internal location | Business Continuity and Disaster Recovery (BCDR) scenarios. Also enables proactive security scanning, fix it scenarios, and ability to rebuild OSS in a trusted build environment. | 301 | | *Scan It* | SCA-1 | L1 | Scan OSS for known vulnerabilities (i.e. CVEs, GitHub Advisories, etc.) | Able to update OSS to reduce risks | 302 | | | SCA-2 | L1 | Scan OSS for licenses | Ensure your organization remains in compliance with the software license | 303 | | | SCA-3 | L2 | Scan OSS to determine if its end-of-life | For security purposes, no organization should take a dependency on software that is no longer receiving updates | 304 | | | SCA-4 | L3 | Scan OSS for malware | Able to prevent ingestion of malware into your CI/CD environment | 305 | | | SCA-5 | L3 | Perform proactive security review of OSS | Identify zero-day vulnerabilities and confidentially contribute fixes back to the upstream maintainer | 306 | | *Inventory It* | INV-1 | L1 | Maintain an automated inventory of all OSS used in development | Able to respond to incidents by knowing who is using what OSS where. This can also be accomplished by generating SBOMs for your software. | 307 | | | INV-2 | L2 | Have an OSS Incident Response Plan | This is a defined, repeatable process that enables your organization to quickly respond to reported OSS incidents | 308 | | *Update It* | UPD-1 | L1 | Update vulnerable OSS manually | Ability to resolve vulnerabilities | 309 | | | UPD-2 | L2 | Enable automated OSS updates | Improve MTTR to patch faster than adversaries can operate | 310 | | | UPD-3 | L2 | Display OSS vulnerabilities as comments in Pull Requests (PRs).
**Prerequisite**: Two-person PR reviews are enforced. | PR reviewer doesn't want to approve knowing that there are unaddressed vulnerabilities. | 311 | | *Audit It* | AUD-1 | L3 | Verify the provenance of your OSS | Able to track that a given OSS package traces back to a repo | 312 | | | 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 | 313 | | | AUD-3 | L2 | Validate integrity of the OSS that you consume into your build | Validate digital signature or hash match for each component | 314 | | | 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 | 315 | | *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 | 316 | | | 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 | 317 | | *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. | 318 | | | REB-2 | L4 | Digitally sign the OSS you rebuild | Protect the integrity of the OSS you use. | 319 | | | 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 | 320 | | | 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 | 321 | | *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. | 322 | 323 | ## OSS SSC Framework Tooling Availability 324 | 325 | **Comprehensive Tooling available in v1.0 of the OSS SSC Framework:** 326 | 327 | The guidance and tooling in this document are a combination of paid and free tools from both Microsoft and across the industry. 328 | 329 | **Tooling available in future iterations of the OSS SSC Framework:** 330 | 331 | In the future, Microsoft plans on releasing more tools to help organizations secure their software supply chain end-to-end. 332 | 333 | ## Implementing the OSS SSC Framework by Level 334 | 335 | Below is a table of the OSS SSC Framework 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. 336 | 337 | 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 [OSS SSC Framework Requirements](#OSS-SSC-Framework-Requirements) earlier in this document. 338 | 339 | | **Practice name** | **L1** | **L2** | **L3** | **L4** | 340 | | --- | --- | --- | --- | --- | 341 | | **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) | | 342 | | **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/) | | 343 | | **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) | | | 344 | | **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 as comments in 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) | | | 345 | | **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/) | 346 | | **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 OSS SSC Framework.

**Paid Tool**: [Nexus Firewall](https://www.sonatype.com/products/firewall) | | 347 | | **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) | 348 | | **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) | 349 | 350 | # Conclusion 351 | 352 | 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 OSS SSC Framework as defined by the requirements identified in Level 3 of the OSS SSC Framework Maturity Model. 353 | 354 | # Appendix: Relation to SCITT 355 | 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 OSS SSC Framework requirements and store it in SCITT. The format of such attestations is to be determined. 356 | 357 | # Appendix: Mapping OSS SSC Framework Requirements to Other Specifications 358 | 359 | There are many other security frameworks, guides, and controls. This section maps the OSS SSC 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. 360 | 361 | | **Requirement ID** | **Requirement Title** | **References** | 362 | | --- | --- | --- | 363 | | 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 | 364 | | ING-2 | Use an OSS binary repository manager solution | **OWASP SCVS:** 4.1
**CNCF SSC:** Define and prioritize trusted package managers and repositories | 365 | | ING-3 | Have a Deny List capability to block known malicious OSS from being consumed | | 366 | | ING-4 | Mirror a copy of all OSS source code to an internal location | **CNCF SSC:** Build libraries based upon source code | 367 | | 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 | 368 | | 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 | 369 | | 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 | 370 | | SCA-4 | Scan OSS for malware | | 371 | | SCA-5 | Perform proactive security review 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, | 372 | | 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 | 373 | | INV-2 | Have an OSS Incident Response Plan | **SP800218** : RV.2.2
**SP800161** : SA-5, SA-8, SA-10, SA-11, SA-15(7) | 374 | | UPD-1 | Update vulnerable OSS manually | | 375 | | UPD-2 | Enable automated OSS updates | | 376 | | UPD-3 | Display OSS vulnerabilities as comments in Pull Requests (PRs) | | 377 | | AUD-1 | Verify the provenance of your OSS | **CIS SSC SG** : 3.2.4
**OWASP SCVS:** 1.10, 6.1
**SLSA:** Provenance – Dependencies complete | 378 | | AUD-2 | Audit that developers are consuming OSS through the approved ingestion method | **CIS SSC SG** : 4.3.3 | 379 | | 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 | 380 | | AUD-4 | Validate SBOMs of OSS that you consume into your build | **CNCF SSC:** Require SBOM from third party supplier | 381 | | 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 | 382 | | 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 | 383 | | REB-1 | Rebuild the OSS in a trusted build environment, or validate that it is reproducibly built | **CIS SSC SG** : 2.4.4
**SLSA:** Build - Reproducible | 384 | | REB-2 | Digitally sign the OSS you rebuild | **SP800218** : PS.2.1 | 385 | | 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 | 386 | | REB-4 | Digitally sign the SBOMs you produce | **CIS SSC SG** : 2.4.6 | 387 | | 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 | | 388 | 389 | # Appendix: References 390 | 391 | Here is a list of hyperlinks for documents mentioned within this paper: 392 | 393 | - [The Free Software Definition](https://en.wikipedia.org/wiki/The_Free_Software_Definition) 394 | - [The Open Source Definition](https://opensource.org/osd) 395 | - [Supply Chain Risk Management Practices for Federal Information Systems and Organizations (nist.gov)](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-161.pdf) 396 | - [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) 397 | - [CIS WorkBench / Benchmarks (cisecurity.org)](https://workbench.cisecurity.org/benchmarks/7555) 398 | - [OWASP Software Component Verification Standard | OWASP Foundation](https://owasp.org/www-project-software-component-verification-standard/) 399 | - [SLSA • Supply-chain Levels for Software Artifacts](https://slsa.dev/) 400 | - [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) 401 | --------------------------------------------------------------------------------