├── .github └── CODEOWNERS ├── .gitignore ├── LICENSE ├── README.md ├── docs ├── meetings.md ├── presentations.md ├── roadmap.md ├── supply-chain-maturity.md └── workstream-governance.md ├── poc ├── README.md └── poc_overview.png └── workstreams └── archived └── scmm ├── README.md └── ROADMAP.md /.github/CODEOWNERS: -------------------------------------------------------------------------------- 1 | # These owners will be the default owners for everything in 2 | # the repo. People listed below will be requested for review 3 | # when someone opens a pull request. 4 | * @lmilbaum @fdegir @MarckK @gkunz @vikyol @tracymiranda @mjmckay @mgreau @majinghe @todaywasawesome @bendory @pxp928 @developer-guy 5 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | # OSX leaves these everywhere on SMB shares 2 | ._* 3 | 4 | # OSX trash 5 | .DS_Store 6 | 7 | # Eclipse files 8 | .classpath 9 | .project 10 | .settings/** 11 | 12 | # Files generated by JetBrains IDEs, e.g. IntelliJ IDEA 13 | .idea/ 14 | *.iml 15 | 16 | # Vscode files 17 | .vscode 18 | 19 | # Emacs save files 20 | *~ 21 | \#*\# 22 | .\#* 23 | 24 | # Vim-related files 25 | [._]*.s[a-w][a-z] 26 | [._]s[a-w][a-z] 27 | *.un~ 28 | Session.vim 29 | .netrwhist 30 | 31 | # JUnit test output from ginkgo e2e tests 32 | /junit*.xml 33 | 34 | # Mercurial files 35 | **/.hg 36 | **/.hg* 37 | 38 | # direnv .envrc files 39 | .envrc 40 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Apache License 2 | Version 2.0, January 2004 3 | http://www.apache.org/licenses/ 4 | 5 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 6 | 7 | 1. Definitions. 8 | 9 | "License" shall mean the terms and conditions for use, reproduction, 10 | and distribution as defined by Sections 1 through 9 of this document. 11 | 12 | "Licensor" shall mean the copyright owner or entity authorized by 13 | the copyright owner that is granting the License. 14 | 15 | "Legal Entity" shall mean the union of the acting entity and all 16 | other entities that control, are controlled by, or are under common 17 | control with that entity. For the purposes of this definition, 18 | "control" means (i) the power, direct or indirect, to cause the 19 | direction or management of such entity, whether by contract or 20 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 21 | outstanding shares, or (iii) beneficial ownership of such entity. 22 | 23 | "You" (or "Your") shall mean an individual or Legal Entity 24 | exercising permissions granted by this License. 25 | 26 | "Source" form shall mean the preferred form for making modifications, 27 | including but not limited to software source code, documentation 28 | source, and configuration files. 29 | 30 | "Object" form shall mean any form resulting from mechanical 31 | transformation or translation of a Source form, including but 32 | not limited to compiled object code, generated documentation, 33 | and conversions to other media types. 34 | 35 | "Work" shall mean the work of authorship, whether in Source or 36 | Object form, made available under the License, as indicated by a 37 | copyright notice that is included in or attached to the work 38 | (an example is provided in the Appendix below). 39 | 40 | "Derivative Works" shall mean any work, whether in Source or Object 41 | form, that is based on (or derived from) the Work and for which the 42 | editorial revisions, annotations, elaborations, or other modifications 43 | represent, as a whole, an original work of authorship. For the purposes 44 | of this License, Derivative Works shall not include works that remain 45 | separable from, or merely link (or bind by name) to the interfaces of, 46 | the Work and Derivative Works thereof. 47 | 48 | "Contribution" shall mean any work of authorship, including 49 | the original version of the Work and any modifications or additions 50 | to that Work or Derivative Works thereof, that is intentionally 51 | submitted to Licensor for inclusion in the Work by the copyright owner 52 | or by an individual or Legal Entity authorized to submit on behalf of 53 | the copyright owner. For the purposes of this definition, "submitted" 54 | means any form of electronic, verbal, or written communication sent 55 | to the Licensor or its representatives, including but not limited to 56 | communication on electronic mailing lists, source code control systems, 57 | and issue tracking systems that are managed by, or on behalf of, the 58 | Licensor for the purpose of discussing and improving the Work, but 59 | excluding communication that is conspicuously marked or otherwise 60 | designated in writing by the copyright owner as "Not a Contribution." 61 | 62 | "Contributor" shall mean Licensor and any individual or Legal Entity 63 | on behalf of whom a Contribution has been received by Licensor and 64 | subsequently incorporated within the Work. 65 | 66 | 2. Grant of Copyright License. Subject to the terms and conditions of 67 | this License, each Contributor hereby grants to You a perpetual, 68 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 69 | copyright license to reproduce, prepare Derivative Works of, 70 | publicly display, publicly perform, sublicense, and distribute the 71 | Work and such Derivative Works in Source or Object form. 72 | 73 | 3. Grant of Patent License. Subject to the terms and conditions of 74 | this License, each Contributor hereby grants to You a perpetual, 75 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 76 | (except as stated in this section) patent license to make, have made, 77 | use, offer to sell, sell, import, and otherwise transfer the Work, 78 | where such license applies only to those patent claims licensable 79 | by such Contributor that are necessarily infringed by their 80 | Contribution(s) alone or by combination of their Contribution(s) 81 | with the Work to which such Contribution(s) was submitted. If You 82 | institute patent litigation against any entity (including a 83 | cross-claim or counterclaim in a lawsuit) alleging that the Work 84 | or a Contribution incorporated within the Work constitutes direct 85 | or contributory patent infringement, then any patent licenses 86 | granted to You under this License for that Work shall terminate 87 | as of the date such litigation is filed. 88 | 89 | 4. Redistribution. You may reproduce and distribute copies of the 90 | Work or Derivative Works thereof in any medium, with or without 91 | modifications, and in Source or Object form, provided that You 92 | meet the following conditions: 93 | 94 | (a) You must give any other recipients of the Work or 95 | Derivative Works a copy of this License; and 96 | 97 | (b) You must cause any modified files to carry prominent notices 98 | stating that You changed the files; and 99 | 100 | (c) You must retain, in the Source form of any Derivative Works 101 | that You distribute, all copyright, patent, trademark, and 102 | attribution notices from the Source form of the Work, 103 | excluding those notices that do not pertain to any part of 104 | the Derivative Works; and 105 | 106 | (d) If the Work includes a "NOTICE" text file as part of its 107 | distribution, then any Derivative Works that You distribute must 108 | include a readable copy of the attribution notices contained 109 | within such NOTICE file, excluding those notices that do not 110 | pertain to any part of the Derivative Works, in at least one 111 | of the following places: within a NOTICE text file distributed 112 | as part of the Derivative Works; within the Source form or 113 | documentation, if provided along with the Derivative Works; or, 114 | within a display generated by the Derivative Works, if and 115 | wherever such third-party notices normally appear. The contents 116 | of the NOTICE file are for informational purposes only and 117 | do not modify the License. You may add Your own attribution 118 | notices within Derivative Works that You distribute, alongside 119 | or as an addendum to the NOTICE text from the Work, provided 120 | that such additional attribution notices cannot be construed 121 | as modifying the License. 122 | 123 | You may add Your own copyright statement to Your modifications and 124 | may provide additional or different license terms and conditions 125 | for use, reproduction, or distribution of Your modifications, or 126 | for any such Derivative Works as a whole, provided Your use, 127 | reproduction, and distribution of the Work otherwise complies with 128 | the conditions stated in this License. 129 | 130 | 5. Submission of Contributions. Unless You explicitly state otherwise, 131 | any Contribution intentionally submitted for inclusion in the Work 132 | by You to the Licensor shall be under the terms and conditions of 133 | this License, without any additional terms or conditions. 134 | Notwithstanding the above, nothing herein shall supersede or modify 135 | the terms of any separate license agreement you may have executed 136 | with Licensor regarding such Contributions. 137 | 138 | 6. Trademarks. This License does not grant permission to use the trade 139 | names, trademarks, service marks, or product names of the Licensor, 140 | except as required for reasonable and customary use in describing the 141 | origin of the Work and reproducing the content of the NOTICE file. 142 | 143 | 7. Disclaimer of Warranty. Unless required by applicable law or 144 | agreed to in writing, Licensor provides the Work (and each 145 | Contributor provides its Contributions) on an "AS IS" BASIS, 146 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 147 | implied, including, without limitation, any warranties or conditions 148 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 149 | PARTICULAR PURPOSE. You are solely responsible for determining the 150 | appropriateness of using or redistributing the Work and assume any 151 | risks associated with Your exercise of permissions under this License. 152 | 153 | 8. Limitation of Liability. In no event and under no legal theory, 154 | whether in tort (including negligence), contract, or otherwise, 155 | unless required by applicable law (such as deliberate and grossly 156 | negligent acts) or agreed to in writing, shall any Contributor be 157 | liable to You for damages, including any direct, indirect, special, 158 | incidental, or consequential damages of any character arising as a 159 | result of this License or out of the use or inability to use the 160 | Work (including but not limited to damages for loss of goodwill, 161 | work stoppage, computer failure or malfunction, or any and all 162 | other commercial damages or losses), even if such Contributor 163 | has been advised of the possibility of such damages. 164 | 165 | 9. Accepting Warranty or Additional Liability. While redistributing 166 | the Work or Derivative Works thereof, You may choose to offer, 167 | and charge a fee for, acceptance of support, warranty, indemnity, 168 | or other liability obligations and/or rights consistent with this 169 | License. However, in accepting such obligations, You may act only 170 | on Your own behalf and on Your sole responsibility, not on behalf 171 | of any other Contributor, and only if You agree to indemnify, 172 | defend, and hold each Contributor harmless for any liability 173 | incurred by, or claims asserted against, such Contributor by reason 174 | of your accepting any such warranty or additional liability. 175 | 176 | END OF TERMS AND CONDITIONS 177 | 178 | APPENDIX: How to apply the Apache License to your work. 179 | 180 | To apply the Apache License to your work, attach the following 181 | boilerplate notice, with the fields enclosed by brackets "[]" 182 | replaced with your own identifying information. (Don't include 183 | the brackets!) The text should be enclosed in the appropriate 184 | comment syntax for the file format. We also recommend that a 185 | file or class name and description of purpose be included on the 186 | same "printed page" as the copyright notice for easier 187 | identification within third-party archives. 188 | 189 | Copyright [yyyy] [name of copyright owner] 190 | 191 | Licensed under the Apache License, Version 2.0 (the "License"); 192 | you may not use this file except in compliance with the License. 193 | You may obtain a copy of the License at 194 | 195 | http://www.apache.org/licenses/LICENSE-2.0 196 | 197 | Unless required by applicable law or agreed to in writing, software 198 | distributed under the License is distributed on an "AS IS" BASIS, 199 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 200 | See the License for the specific language governing permissions and 201 | limitations under the License. 202 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # CDF Software Supply Chain SIG - **Archived** 2 | 3 | The work produced by the Software Supply Chain SIG is available in this repository. 4 | 5 | If you are interested in software supply chain and would like to resume the work of this SIG, please reach out to the 6 | CDF's [Technical Oversight Committee](https://cd.foundation/about/toc/). 7 | 8 | ## Quick links 9 | 10 | - [CDF Software Supply Chain SIG](#cdf-software-supply-chain-sig) 11 | - [Quick links](#quick-links) 12 | - [Overview](#overview) 13 | - [Members](#members) 14 | - [New Members](#new-members) 15 | - [Governance](#governance) 16 | - [SIG Workstreams](#sig-workstreams) 17 | - [Communication](#communication) 18 | - [Meetings](#meetings) 19 | 20 | ## Overview 21 | 22 | Recent attacks highlighted the importance of and the need to collaborate on addressing challenges with the Software Supply Chain. 23 | Governments, standards developing organizations, and communities have started focusing on this topic to improve the situation and publishing new announcements, guidelines, and directives. 24 | It is imperative to take actions to ensure security, integrity, and compliance of the Software Supply Chain which includes all source code which is incorporated into an artifact, irrespective of whether it is open source or proprietary software. 25 | Additionally, the systems involved in getting software from developers’ IDEs into the hands of end-users, such as SCM and CI/CD systems, must also be subject to the same level of scrutiny. 26 | 27 | One key consideration to take into account while working with Software Supply Chain is CI/CD. 28 | There are many parts of the software lifecycle that need attention and the focus of this SIG is the CI/CD in order to avoid overlaps and contribute to other initiatives aiming to improve the security posture for the products and production systems from CI/CD perspective. 29 | 30 | The reasons for this is that the practices employed and the technologies used by organizations while establishing software flows heavily depend on CI/CD. 31 | The activities that start, once code contributions leave developer's workstations and land in the production environments serving end users’ needs, are orchestrated by CI/CD systems. 32 | Various industry best practices such as policy driven CD and SBOMs are all important aspects to take into consideration to ensure security, integrity, and compliance for the products that are deployed to production. 33 | 34 | Another critical aspect to highlight is the importance of securing the CI/CD systems themselves as these systems are essentially production systems. 35 | CI/CD systems are also constructed using open source and/or commercial software and any issues with security, integrity, and compliance within these systems could have great impacts on the products produced using them. 36 | In addition to this, CI/CD systems interact with or operate against various environments such as staging and production. 37 | Such environments could be hosted on-premise, private and public clouds which increases the complexity and importance of securing CI/CD systems themselves. 38 | The Software Supply Chain SIG aims to study different aspects of CI/CD systems, securing it to prevent bad actors from exploiting these systems and the products produced and deployed by them for malicious intentions. 39 | 40 | In addition to identifying and working with relevant topics, the SIG will take a practice oriented approach by implementing proof of concepts and sample pipelines using various CI/CD technologies and tools to highlight how such tools could be used in a Software Supply Chain, how good practices could be employed and what kind of opportunities there are. 41 | A critical requirement for success is collaboration between DevOps practitioners and [CDF hosted projects](https://cd.foundation/projects/) such as Tekton and Jenkins. 42 | Additionally, collaborating with the existing CDF SIGs including but not limited to [Interoperability](https://github.com/cdfoundation/sig-interoperability), [Events](https://github.com/cdfoundation/sig-events), and [Best Practices](https://github.com/cdfoundation/sig-best-practices) is critical for the SIG since some of the topics driven by these SIGs such as metadata standardization and events are relevant for the topics this SIG will work on, such as SBOMs and notification of vulnerabilities. 43 | The Software Supply Chain SIG will also look for synergies between CDF and other communities such as [OpenSSF](https://openssf.org/) and projects and working groups hosted by it such as [Sigstore](https://www.sigstore.dev/), [SLSA](https://slsa.dev/), [Security Tooling WG](https://github.com/ossf/wg-security-tooling), and [Supply Chain Integrity WG](https://github.com/ossf/wg-supply-chain-integrity) to ensure CI/CD aspects are not overlooked. 44 | 45 | 46 | ## Members 47 | 48 | * Liora Milbaum ([@lmilbaum](https://github.com/lmilbaum)), Red Hat 49 | * Fatih Degirmenci ([@fdegir](https://github.com/fdegir)), CDF 50 | * Kara de la Marck ([@MarckK](https://github.com/MarckK)), CDF 51 | * Georg Kunz ([@gkunz](https://github.com/gkunz)), Ericsson 52 | * Erhan Vikyol ([@vikyol](https://github.com/vikyol)), Storebrand 53 | * Tracy Miranda ([@tracymiranda](https://github.com/tracymiranda)), Chainguard 54 | * Melissa McKay ([@mjmckay](https://github.com/mjmckay)), JFrog 55 | * Maxime Gréau ([@mgreau](https://github.com/mgreau)), Elastic 56 | * Majinghe ([@majinghe](https://github.com/majinghe)) 57 | * Dan Garfield ([@todaywasawesome](https://github.com/todaywasawesome)), Codefresh 58 | * David Espejo ([davidmirror-ops](https://github.com/davidmirror-ops)), VMware 59 | * Brett Smith ([@xbcsmith](https://github.com/xbcsmith)), SAS Institute Inc. 60 | * David Bendory ([@bendory](https://github.com/bendory)), Google 61 | * Parth Patel ([@pxp928](https://github.com/pxp928)), Kusari 62 | * Batuhan Apaydın ([@developer-guy](https://github.com/developer-guy)), Trendyol Group 63 | 64 | ## New Members 65 | 66 | Membership to the CDF SIG Software Supply Chain is open to the public and self-declared. 67 | 68 | New members are advised to: 69 | 70 | * Join the SIG and CDF TOC maillists. 71 | * Join the SIG Slack Channel and introduce yourself. 72 | * Go through the README.md document. 73 | * Regularly join the SIG Meetings. 74 | * Submit a PR to add yourself to the members list. 75 | * Here are various ways to get involved: 76 | * Share your thoughts by joining the meetings or by posting to maillist and Slack channel. 77 | * Present a project the community you are part of is working on. 78 | * Add a topic you would like to discuss to the agenda. 79 | * Create a new issue to start gathering feedback and collaborating. 80 | * Choose an issue where help is needed and comment on it expressing interest. 81 | * Propose a proof of concept. 82 | 83 | ## Governance 84 | 85 | SIG Software Supply Chain is a [CDF Special Interest Group](https://github.com/cdfoundation/toc/tree/master/sigs). 86 | 87 | The process SIG Software Supply Chain follows can be seen from [here](https://github.com/cdfoundation/toc/blob/master/GROUPS.md#sigs). 88 | 89 | Chairs and the TOC Sponsor of the SIG are 90 | 91 | * Liora Milbaum ([@lmilbaum](https://github.com/lmilbaum)), Red Hat - Co-chair 92 | * David Bendory ([@bendory](https://github.com/bendory)), Google - Co-chair 93 | * Melissa McKay ([@mjmckay](https://github.com/mjmckay)), JFrog - TOC Sponsor 94 | 95 | ### SIG Workstreams 96 | 97 | SIG Software Supply Chain welcomes contributors who take part in the SIG to form workstreams to work on specific areas of interest in a more focused and structured way. 98 | 99 | Workstream governance is [here](./docs/workstream-governance.md). 100 | 101 | Archived workstreams are: 102 | 103 | * [Supply Chain Maturity Model](./workstreams/archived/scmm/README.md) 104 | 105 | ## Communication 106 | 107 | SIG Software Supply Chain communication happens via a public mailing list and everyone is 108 | welcome to join our open discussions. 109 | 110 | SIG Software Supply Chain also uses Slack for additional collaboration opportunities. 111 | 112 | * Maillist: https://lists.cd.foundation/g/sig-software-supply-chain 113 | * Slack Channel: #sig-software-supply-chain on [CDF Slack](https://cdeliveryfdn.slack.com/join/shared_invite/zt-nwc0jjd0-G65oEpv5ynFfPD5oOX5Ogg#/) 114 | 115 | ## Meetings 116 | 117 | SIG Software Supply Chain meets second and fourth Thursdays at 16:00 UTC. (*See your timezone [here](https://time.is/1600_in_UTC)*) 118 | 119 | * Meeting agenda and minutes: [here](./docs/meetings.md) 120 | * Meeting recordings: [here](https://youtube.com/playlist?list=PL2KXbZ9-EY9TT2rKSBv6-BUdKqsJg9rAL) 121 | * Zoom Bridge: [here](https://zoom.us/j/94947282554?pwd=UndPWjFkQTJSUGo4WTRZWjlDaEQvUT09) 122 | * Zoom International dial-in numbers: [here](https://zoom.us/zoomconference) 123 | * CDF Public Calendar (UTC): [here](https://calendar.google.com/calendar/u/0/embed?src=linuxfoundation.org_mhf0kmgedn67ihni8r129avp24@group.calendar.google.com&ctz=UTC) 124 | -------------------------------------------------------------------------------- /docs/meetings.md: -------------------------------------------------------------------------------- 1 | ###### tags: `SIG Software Supply Chain` 2 | 3 | # CDF Software Supply Chain SIG Meetings 4 | 5 | [![HacmKD documents](https://hackmd.io/badge.svg)](https://hackmd.io/HuufSDMaTPyb3qxkyBKg3A?edit) 6 | 7 | ## Quick links 8 | 9 | * [Logistics](#Logistics) 10 | * [Agenda and Notes](#Agenda-and-Notes) 11 | * [2022-09-22 Meeting](#September-22-2022) 12 | * [2022-09-08 Meeting](#September-8-2022) 13 | * [2022-08-25 Meeting](#August-25-2022) 14 | * [2022-08-11 Meeting](#August-11-2022) 15 | * [2022-07-28 Meeting](#July-28-2022) - ***Cancelled*** 16 | * [2022-07-14 Meeting](#July-14-2022) - ***Cancelled*** 17 | * [2022-06-23 Meeting](#June-23-2022) 18 | * [2022-06-09 Meeting](#June-9-2022) 19 | * [2022-05-26 Meeting](#May-26-2022) 20 | * [2022-05-12 Meeting](#May-12-2022) 21 | * [2022-04-28 Meeting](#April-28-2022) 22 | * [2022-04-14 Meeting](#April-14-2022) 23 | * [2022-03-24 Meeting](#March-24-2022) 24 | * [2022-03-10 Meeting](#March-10-2022) 25 | 26 | ## Logistics 27 | 28 | * **Meeting notes on HackMD**: https://hackmd.io/MX4W9EE0RBeO3xfJ9wDi_Q 29 | * **When**: Second and fourth Thursdays at 15:00UTC (*See your timezone [here](https://time.is/1500_in_UTC)*) 30 | * **Zoom Bridge**: https://zoom.us/j/94947282554?pwd=UndPWjFkQTJSUGo4WTRZWjlDaEQvUT09 31 | * **Zoom International dial-in numbers**: https://zoom.us/zoomconference 32 | * **Meeting Recordings**: [CDF Youtube Channel SIG Software Supply Chain Playlist](https://youtube.com/playlist?list=PL2KXbZ9-EY9TT2rKSBv6-BUdKqsJg9rAL) 33 | * **Presentation Schedule**: https://hackmd.io/l1BfXp1kQKGKSaKLbl6xJw 34 | * **CDF Public Calendar**: [here](https://calendar.google.com/calendar/embed?src=linuxfoundation.org_mhf0kmgedn67ihni8r129avp24%40group.calendar.google.com&ctz=UTC) 35 | 36 | ## Agenda and Notes 37 | 38 | Meeting agenda and notes are kept on [HackMD.io](https://hackmd.io/MX4W9EE0RBeO3xfJ9wDi_Q) where everyone can add new topics to the agenda for upcoming meetings or take notes during the meetings. Please click edit button to edit the document. 39 | 40 | ### September 22, 2022 41 | 42 | #### Participants 43 | 44 | * Brett Smith, SAS Institute 45 | * Terry Cox 46 | * David Espejo 47 | * Georg Kunz 48 | * Grant Buskey 49 | * Jill 50 | * Parth Patel 51 | * Fatih Degirmenci 52 | * Justin Abrahms, eBay/CDF 53 | * Kara de la Marck 54 | * Osama Magdy 55 | * David Bendory 56 | 57 | #### Agenda and Notes 58 | 59 | * CI/CD Pipeline at SAS, Brett Smith 60 | * Supply Chain Maturity Model Workstream, All 61 | * [Announcement Blog Post](https://cd.foundation/blog/2022/09/22/software-supply-chain-sig-launches-maturity-model-workstream/) 62 | * Meetings: Every other Tuesday at 16:00 UTC (details [here](https://github.com/cdfoundation/sig-software-supply-chain/tree/main/workstreams/scmm#meetings)), starting October 4 63 | 64 | #### Action Items 65 | 66 | * None 67 | 68 | #### Meeting Recording 69 | 70 | * \ 71 | 72 | ### September 8, 2022 73 | 74 | #### Participants 75 | 76 | * Osama Magdy, Jenkins X 77 | * Kara de la Marck, CDF 78 | * Parth Patel, Kusari 79 | * Rajat Gupta, Jenkins X 80 | * Fatih Degirmenci, CDF 81 | * Georg Kunz, Ericsson 82 | * David Espejo, VMWare 83 | * Brad Beck 84 | * Andrea Frittoli, IBM 85 | * Ankit Mohapatra, Berkshire grey 86 | * Justin Abrahms, eBay, CDF TOC/Board/SIG-Interoperability 87 | 88 | #### Agenda and Notes 89 | 90 | * Action Item Review, All 91 | * [FRSCA](https://github.com/buildsec/frsca), Parth Patel, Kusari 92 | * Supply Chain Maturity Model Workstream, David Bendory, Google 93 | * [Workstream Readme](https://github.com/cdfoundation/sig-software-supply-chain/tree/main/workstreams/scmm) 94 | * [Doodle Poll to find meeting time](https://doodle.com/meeting/participate/id/dG5MZ45a) 95 | 96 | #### Action Items 97 | 98 | * None 99 | 100 | #### Meeting Recording 101 | 102 | * \ 103 | 104 | ### August 25, 2022 105 | 106 | #### Participants 107 | 108 | * Ankit, Berkshire grey 109 | * Osama Magdy, Jenkins X 110 | * Rajat Gupta, Jenkins X 111 | * Justin Abrahms, eBay, CDF TOC/Board/SIG-Interoperability 112 | * Brett Smith, SAS 113 | * Emil Bäckmark, Ericsson, CDEvents 114 | * Fatih Degirmenci, CDF 115 | * Kara de la Marck, CDF 116 | * Rajat Gupta 117 | * Tharwat Abou-Helal 118 | * David Bendory, Google 119 | * David Espejo, 120 | * Hergy Tchuinkou, 121 | * Parth Patel, Kusari 122 | * Georg Kunz, Ericsson 123 | 124 | #### Agenda and Notes 125 | 126 | * Action Item Review, All 127 | * Supply Chain Security Journey for Jenkins X - Now and Beyond, Osama Magdy, Jenkins X 128 | * Supply Chain Maturity Model, David Bendory, Google 129 | * Context: [slack msg](https://cdeliveryfdn.slack.com/archives/C0333C92VTR/p1660740646761439) 130 | * https://github.com/ossf/scorecard 131 | * **C**ode **H**ealth **P**roject **S**core ("CHiPS" and SLSA) (hat/tip -- thanks to Billy Lynch for the clever name!) 132 | * Parth -- runtime attestations ("is my application only reaching out to known destinations") 133 | * Justin -- this sounds like policies that provide metrics around maturity 134 | 135 | #### Action Items 136 | 137 | * ~~Interested in Supply Chain Maturity Model / "CHiPS"? Please contact David Bendory on Slack to get involved.~~ 138 | * ~~From Zoom: Brett, Justin, Ankit, and Parth stated their interest to take part in the effort on Zoom chat~~ 139 | 140 | #### Meeting Recording 141 | 142 | * https://www.youtube.com/watch?v=Txe1wBt0pcM 143 | 144 | ### August 11, 2022 145 | 146 | #### Participants 147 | 148 | * Fatih Degirmenci, CDF 149 | * Tracy Ragan, DeployHub, Ortelius and OpenSSF Board Member, CDF TOC 150 | * Justin Abrahms, eBay, CDF TOC/Board/SIG-Interoperability 151 | * Terry Cox, Bootstrap 152 | * Kara de la Marck, CDF 153 | * David Bendory, Google 154 | * Chuang Wang, Google 155 | * Yongxuan Zhang, Google 156 | * Prakash Jagatheesan, Google 157 | * Ronan, Google 158 | * Tim Miller, Kusari 159 | * Alex Misdorp 160 | * Michael Lieberman, Kusari 161 | * Parth Patel, Kusari 162 | * Andrea Frittoli, IBM, CDF TOC/Board/SIG-Events 163 | * Brett Smith, SAS 164 | * Charles Tudor, SAS 165 | * Eric Wimmer, SAS 166 | * Su Johnson, SAS 167 | * Scott Todd, SAS 168 | * Jill Madritch, SAS 169 | * Ankit D Mohapatra, berkshire grey 170 | * Rajat Gupta, Jenkins X 171 | * Osama Magdy, Jenkins X 172 | * Terry Cox 173 | * David Espejo 174 | * Georg Kunz 175 | * Juliane 176 | 177 | #### Agenda and Notes 178 | 179 | * Binary Authorization, David Bendory, Google 180 | * [Binary Authorization on Borg Whitepaper](http://cloud.google.com/security/binary-authorization-for-borg/) 181 | * [Binary Authorization on Google Cloud](http://cloud.google.com/binary-authorization/) 182 | * [Scripted Demo of Binary Authorization on GCP](https://github.com/bendory/tekton-on-gcp) 183 | * More about [Container Security at Google](http://cloud.google.com/containers/security) 184 | * CDF Reference Architecture, All 185 | * Aligning our efforts to contribute to the CDF Reference Architecture from Software Supply Chain perspective 186 | * The deck used to kick off the discussion around the CDF is available [here](https://docs.google.com/presentation/d/1SSSHPLSXEUgg0vu644zrZPvCW9sUYSBwzSCDO_fZtF8/edit) 187 | * The work started within SIG Best Practices which meets 2nd and 4th Mondays of every month at 16:00 UTC. Meeting logistics available [here](https://github.com/cdfoundation/sig-best-practices#meetings). 188 | * The initial work can be seen by CDF Best Practices website preview [here](https://deploy-preview-23--prod-bp-cdf.netlify.app/architecture/). 189 | * The contributions can be made to https://github.com/cdfoundation/best-practices-site/tree/refarch1 190 | 191 | #### Action Items 192 | 193 | * AI: David Bendory to figure out if he can share the data points (e.g. proto or yaml) for the sbom/provenance they capture. 194 | * Response: https://slsa.dev/provenance exactly matches Google internal format in some places, while in others it is similar information but the schema is different. 195 | 196 | #### Meeting Recording 197 | 198 | * https://www.youtube.com/watch?v=WQm0bJy3N6Y 199 | 200 | ### July 28, 2022 201 | 202 | Cancelled due to vacation period. 203 | 204 | ### June 14, 2022 205 | 206 | Cancelled due to vacation period. 207 | 208 | ### June 23, 2022 209 | 210 | #### Participants 211 | 212 | * Fatih Degirmenci, CDF 213 | * Brett Smith, SAS 214 | * Ankit, BG, Jenkins X 215 | * Terry Cox, Bootstrap 216 | * Andrew Larsen, SAS 217 | * Sudhindra Rao, JFrog 218 | * Stephen Chin, JFrog 219 | 220 | 221 | #### Agenda and Notes 222 | 223 | * [Pyrsia](https://pyrsia.io/) Presentation, Sudhindra Rao [Presentation](https://docs.google.com/presentation/d/18HnAVTWMIj8HAXepjXPQloDPNRZd4Dqy/edit?usp=sharing&ouid=101931522664284912957&rtpof=true&sd=true) 224 | 225 | #### Action Items 226 | 227 | * None 228 | 229 | #### Meeting Recording 230 | 231 | * https://www.youtube.com/watch?v=5SNKO8Fysbc 232 | 233 | ### June 9, 2022 234 | 235 | Cancelled due to [cdCon 2022](https://events.linuxfoundation.org/cdcon/). 236 | 237 | ### May 26, 2022 238 | 239 | #### Participants 240 | 241 | * Stephen Levine, VMWare 242 | * Ciro da Silva Costa, VMWare 243 | * Terry Cox 244 | * David Espejo, VMWare 245 | * Joshua Winters 246 | * Kara de la Marck 247 | * Rasheed Abdul-Aziz 248 | * Sam Coward 249 | * Scott Rosenberg 250 | * Waciuma 251 | * Fatih Degirmenci 252 | * Ankit Mohapatra, Dexai Robotics, Jenkins X 253 | 254 | #### Agenda and Notes 255 | 256 | * Action Item Review, All 257 | * Open PRs discussion on SIG PoC, All 258 | * PR on SIG PoC is open for feedback: https://github.com/cdfoundation/sig-software-supply-chain/pull/12 259 | * PR on Pipeline Stages is open for feedback: https://github.com/cdfoundation/sig-interoperability/pull/97 260 | * [Cartographer](https://cartographer.sh/) Presentation, Stephen Levine and Ciro da Silva Costa 261 | 262 | #### Action Items 263 | 264 | * None 265 | 266 | #### Meeting Recording 267 | 268 | * https://www.youtube.com/watch?v=6DkKBGauYh0 269 | 270 | ### May 12, 2022 271 | 272 | #### Participants 273 | 274 | * Georg Kunz, Ericsson 275 | * Erhan Vikyol, Storebrand 276 | * Daniel Krivelevich, Cider Security 277 | * Omer Gil, Cider Security 278 | * Terry Cox 279 | * Ann Marie Fred, Red Hat 280 | * Asaf Greenholts 281 | * David Espejo 282 | * Kara de la Marck, CDF 283 | * Moïse 284 | * Fatih Degirmenci, Ericsson Software Technology 285 | * Ankit Mohapatra, Dexai Robotics, Jenkins X 286 | 287 | #### Agenda and Notes 288 | 289 | * Action Item Review, All 290 | * Top 10 CI/CD Security Risks and CI/CD Goat, Daniel Krivelevich, Omer Gil, Cider Security 291 | * [Top 10 CI/CD Security Risks (PDF)](https://www.cidersecurity.io/wp-content/uploads/2022/03/Top-10-CICD-Security-Risks-.pdf) 292 | * [Top 10 CI/CD Security Risks (GitHub)](https://github.com/cider-security-research/top-10-cicd-security-risks) 293 | * [CI/CD Goat (GitHub)](https://github.com/cider-security-research/cicd-goat) 294 | * Continue discussion on [SIG PoC](https://hackmd.io/U6q685gFTdWRrkWZechvGw?view), All 295 | * Isn't it still valuable to establish pipelines to demonstrate the activities to perform and stages/steps to create? 296 | * CI/CD Terminology for Supply Chain Stages/Steps, All 297 | * Contributing to SIG Interoperability Pipeline [Stages](https://github.com/cdfoundation/sig-interoperability/blob/master/docs/vocabulary.md#pipeline-stages)/[Steps](https://github.com/cdfoundation/sig-interoperability/blob/master/docs/vocabulary.md#pipeline-step-types) terminology 298 | * The initial PR: https://github.com/cdfoundation/sig-interoperability/pull/97 299 | * This will be useful as an input to [SIG PoC](https://hackmd.io/U6q685gFTdWRrkWZechvGw?view) 300 | 301 | #### Action Items 302 | 303 | * None 304 | 305 | #### Meeting Recording 306 | 307 | * https://www.youtube.com/watch?v=qFag1LrDBcg 308 | 309 | ### April 28, 2022 310 | 311 | #### Participants 312 | 313 | * Fatih Degirmenci, Ericsson Software Technology 314 | * Kara de la Marck, CDF 315 | * Thomas Schuetz, Dynatrace 316 | * Josh Gavant, Red Hat ([@joshgav](https://github.com/joshgav)) 317 | * Terry Cox 318 | * David Espejo, VMware 319 | * Maxime Gréau, Elastic 320 | * Emil Bäckmark, Ericsson 321 | * Georg Kunz, Ericsson 322 | 323 | #### Agenda and Notes 324 | 325 | * Action Item Review, All 326 | * [CNCF TAG App Delivery](https://github.com/cncf/tag-app-delivery) and [podtato-head](https://github.com/podtato-head/podtato-head), Thomas Schuetz (Dynatrace) and Josh Gavant (Red Hat) 327 | * The work that is done by TAG App Delivery and Pod-tato has potential to be used as part of [CDF SIG Software Supply Chain Proof of Concept](https://hackmd.io/U6q685gFTdWRrkWZechvGw?view) to look at runtime aspects of Software Supply Chain. 328 | * Issue about documenting how to propose new scenarios/patterns and development frameworks: https://github.com/cncf/tag-app-delivery/issues/167 329 | * Similar ideas 330 | * OpenTel: 331 | * SIG Events POC: 332 | * CI/CD Terminology for Supply Chain Stages/Steps, All 333 | * Contributing to SIG Interoperability Pipeline [Stages](https://github.com/cdfoundation/sig-interoperability/blob/master/docs/vocabulary.md#pipeline-stages)/[Steps](https://github.com/cdfoundation/sig-interoperability/blob/master/docs/vocabulary.md#pipeline-step-types) terminology 334 | * The initial PR: https://github.com/cdfoundation/sig-interoperability/pull/97 335 | * This will be useful as an input to [SIG PoC](https://hackmd.io/U6q685gFTdWRrkWZechvGw?view) 336 | 337 | #### Action Items 338 | 339 | * None 340 | 341 | #### Meeting Recording 342 | 343 | * https://www.youtube.com/watch?v=9mi8C106J28 344 | 345 | ### April 14, 2022 346 | 347 | #### Participants 348 | 349 | * Jason Hall (Red Hat) 350 | * Maxime Gréau (Elastic) 351 | * Ankit (Dexai Robotics) 352 | * Kara de la Marck (CDF) 353 | * Fatih Degirmenci (Ericsson Software Technology) 354 | * Terry Cox 355 | * Priya Wadhwa (Chainguard) 356 | * Liora Milbaum (Red Hat) 357 | 358 | #### Agenda and Notes 359 | 360 | * Action Item Review, All 361 | * Meeting Time Change, All 362 | * Meeting time changed to [15:00 UTC](https://time.is/1500_in_UTC) 363 | * Meeting invite sent to the SIG's maillist - https://lists.cd.foundation/g/sig-software-supply-chain 364 | * Setting the scope for the SIG PoC, All 365 | * PoC Document: https://hackmd.io/U6q685gFTdWRrkWZechvGw?view 366 | * [TektonCD Chains](https://github.com/tektoncd/chains) Presentation/Demo,Priya Wadhwa, Chainguard 367 | 368 | #### Action Items 369 | 370 | * None 371 | 372 | #### Meeting Recording 373 | 374 | * https://www.youtube.com/watch?v=U4-sRRAOTRA 375 | 376 | ### March 24, 2022 377 | 378 | #### Participants 379 | 380 | * David Espejo [VMware] 381 | * Georg Kunz, Ericsson 382 | * Mike Lieberman [Citi, CNCF Supply Chain Security WG] 383 | * Billy Lynch [Google, Tekton] 384 | * Ankit Mohapatra [Dexai Robotics, Jenkins X] 385 | * Kara de la Marck, CDF 386 | * Erhan Vikyol, Storebrand 387 | * Liora Milbaum, Red Hat 388 | * Fatih Degirmenci, Ericsson Software Technology 389 | * Terry Cox 390 | * Andrea Frittoli, IBM 391 | * Ann Marie Fred, Red Hat 392 | * Enric Forn 393 | * Maor Kuriel 394 | * Moïse Kameni 395 | * Parth Patel 396 | * Praneetha Manthravadi 397 | * Timothy Miller 398 | 399 | #### Agenda and Notes 400 | 401 | * Action Item Review 402 | * Meeting Time Change 403 | * Meeting time will change to 15:00 UTC starting from next meeting on April 14th 404 | * Meeting invite will be sent to the SIG's maillist - https://lists.cd.foundation/g/sig-software-supply-chain 405 | * Upcoming Presentations 406 | * The schedule is available [here](https://hackmd.io/l1BfXp1kQKGKSaKLbl6xJw?view) 407 | * [TektonCD Chains](https://github.com/tektoncd/chains), Priya Wadhwa, Chainguard, 2022-04-14, 15:00 UTC 408 | * CNCF TAG App Delivery and [Pod-tato Head](https://github.com/podtato-head/podtato-head), Thomas Schuetz, Dynatrace, 2022-04-28, 15:00 UTC 409 | * [Cartographer](https://cartographer.sh/), James Rawlings, 2022-05-12, 15:00 UTC 410 | * Secure Software Factory Reference Architecture and SSF Presentation/Demo/Discussion, Michael Lieberman 411 | * Secure Software Factory Reference Architecture: https://docs.google.com/document/d/15M_Mzfqy634E_sqoslmOXsZJl4TedpbXpBjOfz-hnXk/edit 412 | * SSF Reference Implementation: https://github.com/buildsec/ssf 413 | 414 | #### Action Items 415 | 416 | * None 417 | 418 | #### Meeting Recording 419 | 420 | * https://www.youtube.com/watch?v=9SXcXk2cO3c 421 | 422 | ### March 10, 2022 423 | 424 | #### Participants 425 | 426 | * Fatih Degirmenci, Ericsson Software Technology 427 | * Maxime Gréau, Elastic 428 | * Ann Marie Fred, Red Hat 429 | * Erhan Vikyol, Storebrand 430 | * Tracy Miranda, Chainguard 431 | * Kara de la Marck, CDF 432 | * Ankit D Mohapatra, Dexai Robotics 433 | * Melissa McKay, JFrog 434 | * Andrea Frittoli, IBM 435 | * Georg Kunz, Ericsson 436 | * Terry Cox 437 | * Liora Milbaum, Red Hat 438 | 439 | #### Agenda and Notes 440 | 441 | * Welcome and Introductions 442 | * What is SIG Software Supply Chain and Why? 443 | * Approach of the SIG 444 | * SIG Logistics 445 | * SIG Roadmap 446 | * Initial Topics for the SIG Roadmap 447 | * Knowledge Transfer 448 | * Next Meeting on March 24, 2022 449 | * March 24th falls between when NA and EMEA makes the summer time change 450 | * If we meet at [16:00 UTC](https://time.is/compare/1600_24_Mar_2022_in_UTC/CET/PT), the meeting time will remain same for EMEA but will be 1h later for NA 451 | * If we meet at [15:00 UTC](https://time.is/compare/1500_24_Mar_2022_in_UTC/CET/PT), the meeting time will remain same for NA but will be 1h earlier for EMEA 452 | * Or we skip the meeting to keep things simple - our next meeting would be on April 14, 2022 453 | * Open Discussion 454 | * References 455 | * [Meeting Presentation](https://docs.google.com/presentation/d/1-nt-1Pe4WwiKoDT-ooWAxKPDunSoqeES9Qb3WTEkE9M/edit) 456 | * [CDF SIG Software Supply Chain Charter](https://github.com/cdfoundation/sig-software-supply-chain#overview) 457 | * [CNCF TAG Security, Software Supply Chain Best Practices Whitepaper](https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf) 458 | * Secure Software Factory 459 | * [Website](https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf) 460 | * [GitHub](https://github.com/buildsec/ssf) 461 | * [RFC](https://docs.google.com/document/d/15M_Mzfqy634E_sqoslmOXsZJl4TedpbXpBjOfz-hnXk/edit) 462 | * [TektonCD Chains](https://github.com/tektoncd/chains) 463 | * [CNCF TAG App Delivery Pod Tato Head](https://github.com/podtato-head/podtato-head) 464 | * CDF SIG Interoperability Terminology Work and Quality Gates Discussion 465 | * [PR on Pipeline Stage Terminology](https://github.com/cdfoundation/sig-interoperability/pull/76) 466 | * [PR on Pipeline Step Types](https://github.com/cdfoundation/sig-interoperability/pull/81) 467 | * [Quality Gates Discussion](https://github.com/cdfoundation/sig-interoperability/discussions/83) 468 | 469 | #### Action Items 470 | 471 | * None 472 | 473 | #### Meeting Recording 474 | 475 | * https://www.youtube.com/watch?v=3i6pcPr09Uk -------------------------------------------------------------------------------- /docs/presentations.md: -------------------------------------------------------------------------------- 1 | ###### tags: `SIG Software Supply Chain` 2 | 3 | # CDF Software Supply Chain SIG Presentations 4 | 5 | [![HacmKD documents](https://hackmd.io/badge.svg)](https://hackmd.io/l1BfXp1kQKGKSaKLbl6xJw?edit) 6 | 7 | ## Quick links 8 | 9 | * [Notes](#Notes) 10 | * [Presentation Schedule](#Presentation-Schedule) 11 | * [Presentation Backlog](#Presentation-Backlog) 12 | 13 | ## Notes 14 | 15 | This document is developed on [HackMD.io](https://hackmd.io/l1BfXp1kQKGKSaKLbl6xJw) collaboratively. 16 | 17 | Please click edit button (*the pen icon on the upper right corner*) to edit the document. 18 | 19 | ## Presentation Schedule 20 | 21 | | Topic of Presentation | Type of Presentation | Presenter | Date & Time | Slides & Recording | 22 | | --------------------- | -------------------- | --------- | ----------- | ------------------ | 23 | | SSF (Secure Software Factory) | Project/Initiative | Michael Lieberman | 2022-03-24, 16:00 UTC | TBD | 24 | | TektonCD Chains | Project/Initiative | Priya Wadhwa, Chainguard | 2022-04-14, 15:00 UTC | TBD | 25 | | CNCF TAG App Delivery and Pod-tato Head | Project/Initiative | Thomas Schuetz, Dynatrace| 2022-04-28, 15:00 UTC | TBD | 26 | 27 | 28 | ## Presentation Backlog 29 | 30 | | Topic of Presentation | Presenter | Status | Links | 31 | | --------------------- | --------- | ------ | ----- | 32 | | TBD | TBD | TBD | TBD | -------------------------------------------------------------------------------- /docs/roadmap.md: -------------------------------------------------------------------------------- 1 | # CDF SIG Software Supply Chain Roadmap 2 | 3 | ## Quick Links 4 | 5 | - [Overview](#overview) 6 | - [Charter](#charter) 7 | - [Outcomes](#outcomes) 8 | - [Roadmap](#roadmap) 9 | - [Contributors](#contributors) 10 | 11 | ## Overview 12 | 13 | This document outlines the roadmap for the Continuous Delivery Foundation (CDF) 14 | Software Supply Chain Special Interest Group (SIG). The roadmap represents the 15 | initiatives of the open source collaborations. The roadmap does not specify 16 | timelines or delivery dates, but rather uses time horizons (now, next, later). 17 | 18 | ## Charter 19 | 20 | The Software Supply Chain SIG aims to study different aspects of CI/CD systems and 21 | share best practices for CI/CD with a focus on securing it to prevent bad actors from 22 | exploiting these systems and the products produced and deployed by them for malicious 23 | intentions. 24 | 25 | Please see the SIG charter from [this link](https://github.com/cdfoundation/sig-software-supply-chain/blob/main/README.md). 26 | 27 | ## Outcomes  28 | 29 | The group will work towards a number of outcomes  30 | 31 | 1. **Knowledge Transfer of Software Supply Chain:** We share information 32 | about open source Software Supply Chain tools, technologies, frameworks 33 | as well as the initiatives that are undertaken by the CDF and sister 34 | communities in order to cross-collaborate and pollinate across projects 35 | and communities. 36 | 2. **End User Requirements:** We capture the concerns, considerations, use cases 37 | the end users have with regards to Software Supply Chain and CI/CD and the 38 | challenges they are facing and the pain points they are experiencing. 39 | 3. **Shared Vocabulary:** We work on contributing to shared vocabulary from Software 40 | Supply Chain perspective. 41 | 4. **Promote Best Practices:** We work on identifying, contributing, and promoting 42 | best practices that can help organizations the develop, build, and deliver software 43 | in a secure manner. 44 | 45 | ## RoadMap 46 | 47 | ![](https://lh5.googleusercontent.com/5F-b4dHm1MMqn47PNzMx9Br7h6N62fEnZU3xp60E9LksEo-MmOK8Ok0PqjyAet4oevSk4vXcgfdi7wg8V4gRuvklCDoO57km-r6DKZS7w4IFhlquyq4_KCHrcYVZNXR1EIRTyDxO) 48 | 49 | Reference: Janna Bastow (https://twitter.com/simplybastow/status/1168531737766432768?s=20) 50 | 51 | ### Now  52 | 53 | #### Knowledge Transfer 54 | 55 | The CDF SIG Software Supply Chain holds regular presentations to enable knowledge sharing about 56 | open source Software Supply Chain tools, technologies, frameworks as well as the techniques used 57 | by organizations and the initiatives that are undertaken by the CDF and sister communities in order 58 | to cross-collaborate and pollinate across project, communities, and organizations. 59 | 60 | #### End User Requirements 61 | 62 | End users will share use cases, challenges, and the work they are doing within 63 | their organizations with the community in order to enable dialog and further 64 | collaboration. 65 | 66 | In addition to end users presenting to the SIG, [the CDF User Stories Program](https://cd.foundation/blog/2023/02/07/launching-cdf-user-stories-first-up-fidelity-investments/) 67 | features end user organizations to share their requirements, use cases, challenges, and the initiatives 68 | they have are in order to share them with the communities on an ongoing basis. 69 | 70 | #### Supply Chain Maturity 71 | 72 | Supply Chain Maturity metrics are supplemental to the many details [Dora](https://www.devops-research.com/research.html) 73 | elides and are helpful in identifying gaps in the supply chain that will improve Dora metrics. 74 | Supply Chain Maturity metrics provide milestones like automated rollout, automated rollback, and deployment 75 | tracking that provide the tooling and insights needed to minimize recovery time. 76 | 77 | The initial version of the [Supply Chain Maturity metrics](https://github.com/cdfoundation/sig-software-supply-chain/blob/main/docs/supply-chain-maturity.md) 78 | has been developed by the SIG in a collaborative manner and contributions are expected and welcomed in 79 | order to improve it. 80 | 81 | ### Next 82 | 83 | #### Establishing Shared Vocabulary 84 | 85 | Various groups within the CDF such as [SIG Interoperability](https://github.com/cdfoundation/sig-interoperability) 86 | and [SIG Events](https://github.com/cdfoundation/sig-events) have been working on 87 | developing a shared vocabulary to help enable the further developments in corresponding 88 | areas. The work is done within the SIG Interoperability repository and the community is 89 | encouraged to contribute to corresponding documents listed below. 90 | 91 | * [SIG Interoperability Tools Vocabulary](https://github.com/cdfoundation/sig-interoperability/blob/main/docs/tools-terminology.md) 92 | * [SIG Interoperability Pipelines Vocabulary](https://github.com/cdfoundation/sig-interoperability/blob/main/docs/pipelines-terminology.md) 93 | 94 | The vocabulary documents currently lack terminology around Software Supply Chain and the SIG 95 | Software Supply Chain could potentially look into contributing to the shared vocabulary. 96 | 97 | #### Supply Chain Security 98 | 99 | Supply Chain Security is a critical aspect with regards to Continuous Delivery, from the 100 | software that goes through the pipelines (e.g., source code, artifacts) as well as the 101 | pipelines themselves. 102 | 103 | The SIG Software Supply Chain charter explicitly states that the SIG aims to contribute 104 | Software Supply Chain efforts and security is one of the key areas. 105 | 106 | ### Later 107 | 108 | #### Events Standardizations 109 | 110 | CDF [CDEvents](https://cdevents.dev) project works on creating a common specification for 111 | Continuous Delivery events in order to achieve interoperability within the CD ecosystem. 112 | The current version of the specification does not have Software Supply Chain related 113 | events and the SIG Software Supply Chain could look for ways to contribute such events 114 | to the project. 115 | 116 | Please note that this work depends on the earlier work, Establishing Shared Vocabulary. 117 | 118 | 119 | ## Contributors to this Document 120 | 121 | Please add yourself to the list in order to credit your contributions. 122 | 123 | Please note that the list of contributors are listed alphabetically. 124 | 125 | * 126 | -------------------------------------------------------------------------------- /docs/supply-chain-maturity.md: -------------------------------------------------------------------------------- 1 | # Supply Chain Maturity Metrics 2 | 3 | * **Author:** [David Bendory (Google/Tekton)](https://github.com/bendory) 4 | * **Contributors:** Justin Abrahms (eBay) 5 | * **This public document is part of the [CDF’s Supply Chain Maturity Model workstream](https://github.com/cdfoundation/sig-software-supply-chain/blob/main/workstreams/scmm/README.md).** 6 | * **History:** This file was imported from the original [source doc](https://docs.google.com/open?id=1CDSbQezqauwL2BaFob7o2ztLk6dTQGZqZCMZ_szNhW8&resourcekey=0-ooiOpNu2gyR-KOlMNOCcDA). 7 | 8 | 9 | ## Objective 10 | 11 | The goal of this document is to describe Supply Chain Maturity Metrics. For each metric, we seek a definition and description that clarifies its purpose and reason for inclusion. 12 | 13 | The metrics herein are lifted from a [previous brainstorming doc](https://docs.google.com/document/u/0/d/1rGvQv2GH8HYbQUZxg89LmWsYe8-MyeTEcj08nwULitw/view). 14 | 15 | 16 | ### Background 17 | 18 | The most common question asked about Supply Chain Maturity Metrics is: “How is this different from [Dora Metrics](https://www.devops-research.com/research.html)?” 19 | 20 | Dora identifies five key metrics, four of which focus on software delivery. These metrics “provide a high-level systems view of software delivery and performance and predict an organization’s ability to achieve its goals.” The Dora metrics are: 21 | 22 | * Software Delivery Performance metrics 23 | * Lead time for changes 24 | * Deployment frequency 25 | * Time to restore service (when there is an outage) 26 | * Change failure rate 27 | * Operational Performance metric 28 | * Reliability 29 | 30 | Supply Chain Maturity metrics are supplemental to the many details Dora elides and are helpful in identifying gaps in the supply chain that will improve Dora metrics. For example: 31 | 32 | * Dora is silent about how to improve change failure rate. Supply Chain Maturity metrics provide numerous milestone metrics around everything from linting and static analysis to code coverage to pre- and post-commit events and integrations -- all of which contribute toward preventing failures and thus reducing the change failure rate. 33 | * Dora is silent about how to lower the time to restore service in the event of an outage. Supply Chain Maturity metrics provide milestones like automated rollout, automated rollback, and deployment tracking that provide the tooling and insights needed to minimize recovery time. 34 | 35 | One way to think about this is: “Good Dora metrics result from Supply Chain Maturity (and other practices).” If your Supply Chain is more mature, your Dora metrics will improve. When it is unclear how to improve Dora metrics, Supply Chain Maturity provides areas of focus and best practices that will contribute to improvements in Dora metrics. 36 | 37 | 38 | ## Source Code Management 39 | 40 | A supply chain without robust source code management quickly degenerates into an ongoing series of non-repeatable, untraceable deployments of unidentifiable software. Thus the first measures of maturity are around Source Code Management. 41 | 42 | Once Source Code Management exists -- and existence is agnostic to the specific system chosen for use -- the following metrics measure maturity of use: 43 | 44 | 45 | ### Source Code Management Required 46 | 47 | While developers must be free to build arbitrary software, the ability to deploy software built from outside the Source Code Management system must be disallowed in a mature supply chain. Assets deployed into production must be identifiably built from code in the Source Code Management system. If an emergency break-glass procedure exists, it must track the deployment of any software that has bypassed this control and a procedure must be followed to restore integrity between managed source code and software deployed in production. 48 | 49 | 50 | ### Review Requirements 51 | 52 | The organization has defined review requirements for submitted code. Ideally, no code can be submitted for inclusion in a deployable artifact without an independent review from another software engineer, manager or other appropriate party. Highly sensitive code _may_ require more than one approval. More reviews is not necessarily more mature -- that is an organizational decision that must be aligned with organizational goals and requirements. 53 | 54 | 55 | ### Linting and Static Analysis 56 | 57 | Source code must be regularly analyzed for bugs, errors, and best-practices that are detectable from static software analysis. Standard tools like `pylint` and `go vet` can be used and augmented by custom, per-organization standards and requirements. Static analyzers include auto-formatters that ensure that all code adheres to organizational style guides and coding standards. 58 | 59 | Linters and Static Analyzers are best run both nightly and via triggered events. 60 | 61 | 62 | #### Nightly Analysis 63 | 64 | A nightly analysis will pick up any changes to code standards -- thus existing code in the repository that was committed before the standard existed (or before it was updated) can be flagged for update. 65 | 66 | 67 | #### Pre-Commit Triggers 68 | 69 | A pre-commit trigger will flag violations before code is committed to the repository and _may_ be configured to prevent submission. Organizations will have different standards for blocking and non-blocking issues. 70 | 71 | 72 | ### Code Management [cdevents](https://cdevents.dev/docs/source-code-version-control/) 73 | 74 | Source Code Manager events can be used to trigger pipelines that verify the integrity of software. 75 | 76 | 77 | #### Pre-Commit Events 78 | 79 | Pre-commit triggers run on proposed changes (pull requests, merge requests, etc.). In increasing levels of maturity, pre-commit pipelines will confirm that proposed changes pass static analysis, merge cleanly, build, pass unit tests, and pass integration tests. 80 | 81 | 82 | #### Post-Commit Events 83 | 84 | Post-commit triggers launch CICD pipelines on each commit. In addition to confirmations run by pre-commit triggers, post-commit triggers may additionally trigger automatic deployment of software to an integrated testing environment and beyond. Note that different pipelines may be triggered by different branches, tags, etc. 85 | 86 | 87 | ##### Detection of Bad Commits 88 | 89 | A mature testing framework will identify bad commits and emit events that may notify the developer who committed the code, the build team, or adjacent teams. A mature system may auto-generate a request for rollback or automatically roll back the bad commit. 90 | 91 | 92 | ## Build Maturity 93 | 94 | Build maturity seeks to measure the maturity of build processes. For the purposes of this document, a “build” is a CICD process -- which may be a single task or a pipeline of tasks -- that either results in an artifact that will be tested or deployed or verifies the readiness of an artifact for deployment. 95 | 96 | 97 | ### Build Automation 98 | 99 | An automated build process is typically the first step toward CICD automation, and its stable existence unblocks all further automation. An automated build is repeatable. 100 | 101 | 102 | #### Pre-Merge CI 103 | 104 | Pre-merge continuous integration is used to verify software integrity of an individual proposed change and can prevent a single change from breaking the shared integration environment. Pre-merge CI minimally ensures that proposed changes build properly; ideally, some set of integrity tests (at least unit tests) are performed as well. 105 | 106 | 107 | #### Post-Merge CI 108 | 109 | Post-merge integration and testing verifies that committed software remains deployable. Artifacts from post-merge integration may proceed to deployment to a shared integration environment. 110 | 111 | 112 | #### Nightly Build 113 | 114 | A nightly build-from-scratch ensures that software can be bootstrapped at any time. A nightly build is typically the first step toward a nightly automated deployment to a shared QA environment. 115 | 116 | 117 | #### Build Metrics 118 | 119 | Collecting build metrics in a time series enables tracking of build latency and the rate of acceptance of breaking changes. Time-to-repair for a broken build can provide a Dora insight for the health of the development and/or integration environment. 120 | 121 | 122 | ### [SLSA Level](https://slsa.dev/spec/v0.1/levels) 123 | 124 | SLSA Levels measure the integrity of built assets, demonstrating traceability of build inputs and output artifacts. Higher SLSA levels enforce more mature dependency management. A more mature CICD will feature greater automation including the audit trail enabled by SLSA provenance generation and reproducible builds. Security features such as hermetic builds further ensure the integrity of deployed assets. 125 | 126 | 127 | ### Dependency Management 128 | 129 | “Dependencies” here means “anything needed to recreate our production environment.” In most organizations, this will mean source code in the Source Code Management system, Open Source, and potentially built artifacts in a repository such as a Docker registry or Python repo. 130 | 131 | More mature organizations will include lower-level details as “dependencies” -- such as the build tool versions and even the OS version and installed OS packages. 132 | 133 | Highly sensitive organizations may go even further to specify hardware requirements and dependencies. 134 | 135 | This document assumes that “dependencies” has been defined appropriately for the organization’s desired goals. 136 | 137 | 138 | #### Dependency Inventory 139 | 140 | A mature supply chain has an exhaustive list of its build dependencies, hence the existence of a Dependency Inventory and the completeness thereof both demonstrate and contribute to supply chain maturity. A dependency inventory is a pre-requisite for higher SLSA levels that have requirements like “reproducible builds” and “hermetic builds.” 141 | 142 | 143 | #### Package Managers 144 | 145 | As dependencies grow in number, package managers become essential to dependency management. A mature supply chain will not arbitrarily take in dependencies but rather will track dependencies, verify them, scan for vulnerabilities and take steps to avoid malicious software. 146 | 147 | 148 | #### License Management 149 | 150 | Dependencies must be monitored to align license requirements with intended use and avoid license violations. 151 | 152 | 153 | #### EOL Management 154 | 155 | Every dependency must be monitored for ongoing support and maintenance and sunset as end-of-life approaches. 156 | 157 | 158 | #### Security Updates 159 | 160 | Each dependency should be monitored for known CVEs and remediation should be pursued. Counts of vulnerabilities and severity levels should be tracked over time as well as time to remediation -- which could take the form of taking a newer version, removing the dependency, or verifying that the vulnerability does not apply given the use of the dependency. 161 | 162 | 163 | ## Testing Maturity 164 | 165 | Engineering confidence in built artifacts is highly dependent on test automation in CICD pipelines. We break testing into three realms with different metrics for each. 166 | 167 | 168 | ### Unit Tests 169 | 170 | Unit tests are typically run in response to an event (like the addition of new code to the repository or the upgrade of a dependency) or a schedule (like a nightly build). 171 | 172 | 173 | #### Code coverage metrics 174 | 175 | Code coverage is indicative of the quantitative reach of unit tests, but by itself may not be indicative of the quality of unit tests. Good unit tests will have high code coverage metrics, but high coverage in itself may not be indicative of good testing. Also note that there is a law of diminishing returns with code coverage; not all organizations should make high-cost investments in improving code coverage beyond some “good enough” point that supports the reliability of deployed software in alignment with desired goals for Dora metrics and organizational outcomes. 176 | 177 | 178 | #### Pre-merge testing and gating 179 | 180 | Pre-merge unit tests (passing tests as a gate prior to acceptance of proposed code changes) help keep mainline development in an “always green” state. Pre-merge coverage metrics help maintain coverage by giving an indication of the coverage of newly added code and can be used to prevent addition of untested code. 181 | 182 | 183 | #### Post-merge testing 184 | 185 | Post-merge tests can detect breakage or regressions early in the CICD cycle and enable identification of breaking changes. 186 | 187 | 188 | #### Nightly Testing 189 | 190 | Nightly test runs commonly verify main line integrity; in some implementations they are used to gate the creation of nightly deployment candidates. 191 | 192 | 193 | #### Unit Test Metrics 194 | 195 | Unit test metrics create a time series that tracks: 196 | 197 | * Changes in latency 198 | * Changes in code coverage 199 | * Historic pass/fail rate -- enabling flake detection 200 | 201 | 202 | ### Integration Testing 203 | 204 | Integration testing is typically “larger” than unit testing, either because it requires interaction with an external dependency like a database or microservice or requires the existence of multiple deployable artifacts (like components of a data processing pipeline). 205 | 206 | 207 | #### Event-driven Integration Tests 208 | 209 | Integration tests are typically triggered by the creation of a new deployable artifact. Integration tests are used to verify artifact functionality in relation to other deployable artifacts and to gate deployments. 210 | 211 | 212 | #### Forwards / Backwards Compatibility Testing 213 | 214 | An integration environment is often the first point where different components can run against each other in a version compatibility matrix to ensure forward and backward compatibility, essential requirements for smooth rollouts. 215 | 216 | 217 | #### Integration Test Metrics 218 | 219 | As with unit tests, integration test metrics create a time series that tracks: 220 | 221 | * Changes in latency 222 | * Historic pass/fail rate -- enabling flake detection as well as failure rate for integrated changes 223 | 224 | 225 | ### Deployment Testing and Probes 226 | 227 | A mature supply chain includes constant operational monitoring of production. Deployment tests and probes may in fact be identical to integration tests (or a subset thereof). Their existence enables monitoring of production integrity, deployment health checks, Canary testing, automated rollbacks, blue/green rollouts, and additional signals all of which contribute to higher levels of rollout automation and rollout confidence. 228 | 229 | 230 | ### Security Testing 231 | 232 | Software integrity testing may include penetration testing and fuzz testing. 233 | 234 | 235 | ### Load Testing 236 | 237 | A mature supply chain provides signal on how deployed artifacts perform under bursts of traffic, including measures of maximum load, verification of graceful degradation prior to complete failure, and testing of load-handling strategies such as traffic shedding and auto-scaling. 238 | 239 | Proper load testing contributes to reliability in production. 240 | 241 | 242 | ## Deployment Maturity 243 | 244 | Measures of deployment maturity are likely to be highly correlated with Dora metrics as higher levels of deployment automation and management enable more frequent rollouts and faster time to repair when outages occur. 245 | 246 | Some organizations will prefer a fully-automated deployment process with no human interaction except in failure scenarios, while others will prefer manual gating whereby a human decides when to launch each stage of the rollout. Neither answer is inherently more correct; the choice is dependent on organizational needs. 247 | 248 | 249 | ### Automated Rollout 250 | 251 | Even with manual gating, rollouts themselves are automated such that the manual gate consists of a human hitting some variation of an “OK to proceed” button. Automation ensures reproducible rollouts that are verifiable via deployment health checks (see Deployment Testing above). Automation should include automated rollback -- which may be achieved by simply rolling out a previous candidate or may involve some other strategy such as traffic splitting. 252 | 253 | 254 | ### Rollout Strategies 255 | 256 | Each organization will choose a rollout strategy suitable to its stability and velocity needs. Possibilities include gradual rollouts, blue/green deployments, canary testing, and traffic-splitting. A similar strategy should be in place for automated rollback. 257 | 258 | 259 | ### Break-Glass Process 260 | 261 | The existence of a defined robust “break-glass” process can allow more rapid emergency fixes (potentially including manual repair), but a mature process will track break-glass use for later post-incident analysis. This ensures both later integration of the production reparation intervention with the existing CICD as well as operational analysis of the need for and security around break-glass. 262 | 263 | 264 | ### Feature Gating 265 | 266 | Mature organizations often separate software deployment from feature release, gating features behind feature flags that enable and disable new functionality. This often makes rollout/rollback of the feature as simple as restarting the deployed production process with a changed flag value (--enable-my-new-feature / --disable-my-new-feature). This more fine-grained control over feature enablement can change software deployments from “all-or-none” rollouts that are rolled back on failure to smoother software no-op (or “small change”) software deployments followed by a series of incremental flag-flips to enable new features -- keeping enabled only the features that are found to work successfully in production. This approach can improve stability, enable very rapid rollback when needed, and drastically reduce change failure rates. 267 | 268 | 269 | ### Deployment Tracking 270 | 271 | A mature deployment system enables the creation of both a live state of production as well as a historical audit trail of deployed artifacts. This in turn enables security tracing, an audit of bugs and malicious code, and analysis of historic existence of newly-discovered but long-existing bugs and security vulnerabilities in production. 272 | 273 | 274 | ### Deployment Metrics 275 | 276 | Deployment metrics include: 277 | 278 | * Latency from merge to candidate creation 279 | * Latency from merge to QA deployment 280 | * Latency from merge to production deployment (Dora metric) 281 | * Release frequency (Dora metric) 282 | 283 | Note that the latencies from merge to candidate creation and QA deployment are pieces of the Dora metric for latency from merge to production deployment. 284 | 285 | 286 | ## Configuration Management 287 | 288 | A mature Supply Chain treats configuration as code -- whether that configuration controls the build system (that creates production artifacts) or controls the running of production aritfacts themselves (like feature-gating flags above). 289 | 290 | Treating configuration as code demonstrates robust change management over all production controls, from artifact creation to runtime flags and configuration parameters. These may include hardware requirements like CPU, memory, available free disk, or the availability of specific hardware such as GPUs. 291 | 292 | Configuration management provides more granular traceability and an audit trail for answering questions like “what was running in production at this time” or “was feature X enabled or disabled when the failure occurred?” 293 | 294 | The treatment of configuration as code means that configuration is included in (nearly?) all of the above maturity measures. 295 | 296 | 297 | ## Production Security 298 | 299 | Organizationally, the “Supply Chain” _may_ be considered complete once the artifact is in production. Thus Production Security maturity and subsequent metrics might be considered Operational Maturity rather than Supply Chain Maturity. That said, so long as the artifact lives in production, it’s the final link in the Supply Chain, and thus this document includes Production Security and subsequent measures of maturity as well. 300 | 301 | 302 | ### Environment Isolation 303 | 304 | A mature supply chain includes controls segregating developer environments from production deployments. Some organizations may place restrictions on the ability of non-production software to access production assets and vice-versa, while for others a less strict boundary may be sufficient. These restrictions ideally isolate every environment from every other environment in accordance with legal, business, and regulatory requirements. Technical considerations include the dangers of code in a non-production environment reading or changing production information as well as the possibility of production software accessing non-production data. 305 | 306 | 307 | ### Production Lockdown 308 | 309 | Production lockdown ensures the integrity of deployed artifacts by preventing unauthorized changes in production. Ideally, only the automated rollout system can change production, though in the real world a break-glass procedure is often required. A mature supply chain will have controls over human access to production -- whether read or write access. 310 | 311 | Proper production lockdown both enables and requires deployment automation. 312 | 313 | Workload identity and policy enforcement restrict inappropriate artifacts from running in production at all. 314 | 315 | 316 | ### Access Tracking 317 | 318 | Tracking of production access -- even read access -- creates an essential audit trail in maintaining supply chain integrity. Post-incident analysis of production access ensures that manual fixes in production are properly reflected in the software supply chain itself. Read access tracking enables assessment of the extent of compromise in a breach as well as compliance with regulatory requirements around data privacy. 319 | 320 | 321 | ### Vulnerability Scanning 322 | 323 | A secure production environment requires vulnerability identification in all artifacts. Scans ideally occur not only prior to deployment to prevent release of vulnerable software but also on an ongoing basis to identify newly-identified vulnerabilities in currently-running software. 324 | 325 | The first step is the existence and integration of artifact scanning for deployable artifacts. The ability to identify new vulnerabilities in existing production assets depends on accurate [Deployment Tracking](#bookmark=id.qfm3s8qrc324). 326 | 327 | Vulnerability metrics include both the number and severity of vulnerabilities as well as latency of time to mitigate newly-discovered vulnerabilities. For critical vulnerabilities, time to mitigation of a severe vulnerability might be incorporated into Dora measures of time-to-mitigation of an outage. 328 | 329 | 330 | ### Policy Enforcement 331 | 332 | Ongoing policy enforcement in production can be used to ensure that only verified assets in compliance with organizational policies are permitted to run in production. This can prevent execution of malicious software that has bypassed normal rollout procedures, block deployment of inappropriate assets, and provide continuous verification of existing assets vs. new policies. 333 | 334 | 335 | ## Lifecycle and Audit Trail 336 | 337 | Lifecycle management of production assets can be incorporated into a complete audit trail, easing compliance with regulatory and internal audits. Auditable assets include: 338 | 339 | * CICD log lifecycle 340 | * Deployment event logging lifecycle 341 | * License inventory for all dependencies 342 | * Production access log lifecycle 343 | * Artifact freshness, potentially including build horizon and sunsetting of assets by age 344 | * Artifact history and life cycle tracking 345 | 346 | Appropriate time horizons must be established for all audit trails based on organizational needs. 347 | 348 | 349 | ## Out of Scope 350 | 351 | This document completes its scope with the deployment of software assets produced and managed by an organization; thus the below areas -- which may be considered part of the Supply Chain -- are considered out of scope for this document. 352 | 353 | 354 | ### Platform Management 355 | 356 | This document is limited to the software delivered but does not include the platform where it runs. All of the metrics herein can be applied to the underlying platform down to the OS itself. 357 | 358 | Note that if the platform itself is the artifact produced and deployed by an organization, then all the metrics herein can be applied to said asset. 359 | 360 | [Additional information around this topic](https://docs.google.com/document/d/1UDL3E5BqPyDdzV1wek9o8xR-nLJQXEEMU1qIMCgq5cI/view#heading=h.g2ibuwx8cji2) is available from the CNCF Platforms Working Group. 361 | 362 | 363 | ### Hardware Verification / Hardware Management 364 | 365 | Hardware supply goes a level deeper than Platform Management and is similarly considered out-of-scope for this document. 366 | 367 | -------------------------------------------------------------------------------- /docs/workstream-governance.md: -------------------------------------------------------------------------------- 1 | # Software Supply Chain Workstreams 2 | 3 | ## Overview and Motivations 4 | 5 | Project and user representatives who take part in the Software Supply Chain SIG are welcome to form a workstream to work on specific areas of interest in a more focused and structured way. 6 | 7 | The expectations from workstreams would vary depending on the area of focus. Workstreams could focus on collecting the state of things in a specific area from within the ecosystem and contribute that to the domain, or come up with a proposal to address some of the needs in a more structured way in order to socialize their ideas further and increase the awareness. 8 | 9 | Workstreams should, at a regular cadence, share their progress with the rest of the SIG. Workstreams could liase with the Software Supply Chain SIG to present ideas per area on CDF TOC level in order to gather feedback. 10 | 11 | ## Lifecycle 12 | 13 | Workstreams are temporary in nature. They are formed to focus on specific goals and can be archived after reaching their goals. Upon formation, leads for the workstreams are choosen by the workstream participants. When leads step down, they can be replaced by [lazy concensus](https://wiki.openoffice.org/wiki/Documentation/FAQ/ProjectLevel/CommunityQuestions/What_is_%22Lazy_Consensus%22%3F). However, working groups can also be disbanded if there is no longer a lead for the working group (within an 8 week grace period). 14 | 15 | ## Proposing a new Workstream 16 | 17 | We welcome proposals for new workstreams. 🎉 18 | 19 | Proposals for new workstreams can be made via a [PR](https://github.com/cdfoundation/sig-software-supply-chain/pulls) on the Software Supply Chain SIG repo, for discussion and feedback. 20 | 21 | Please create a directory in the [workstreams directory](../workstreams/) with a README providing information about the workstream's focus, goals, membership, and meeting logistics. 22 | 23 | Add your proposal, and a link to your PR, to our [meeting notes](https://hackmd.io/MX4W9EE0RBeO3xfJ9wDi_Q) as an agenda item to discuss at the next SIG meeting. Discussion during the SIG is a great way to gather further feedback and support and attract additional collaborators. 24 | 25 | ## Current Workstreams 26 | 27 | Current workstreams can be found in the [workstreams directory](../workstreams/). 28 | 29 | ## Archived Workstreams 30 | 31 | * [Supply Chain Maturity Model](../workstreams/scmm/README.md) 32 | 33 | ## Example Workstreams 34 | 35 | * [SIG Interoperability Events in CICD](https://github.com/cdfoundation/sig-interoperability/tree/main/workstreams/archived/events_in_cicd) (*archived*) 36 | -------------------------------------------------------------------------------- /poc/README.md: -------------------------------------------------------------------------------- 1 | # CDF Software Supply Chain Proof of Concept 2 | 3 | # Quick links 4 | 5 | * [Introduction](#Introduction) 6 | * [Objectives](#Objectives) 7 | * [Scope](#Scope) 8 | * [Activities](#Activities) 9 | * [Technologies](#Technologies) 10 | * [Environments](#Environments) 11 | * [Resource Requirements](#Resource-Requirements) 12 | * [PoC Team](#PoC-Team) 13 | * [References](#References) 14 | 15 | 16 | # Introduction 17 | 18 | [CDF Special Interest Group (SIG) Software Supply Chain](https://github.com/cdfoundation/sig-software-supply-chain) aims to contribute overall efforts to improve the state of software supply chain from CI/CD perspective. The way the SIG aims to achieve this is to brainstorm around the software supply chain topics that are relevant to CI/CD space and take a practical and experimental approach to identify process and technology aspects that are beneficial for organizations. 19 | 20 | This document aims to start discussion around the practical and experimental approach within the SIG and heavily (re)uses information from CDF and sister communities that are referenced at the end of the document. Reusing outcome of the other initiatives is important in order to make sure we don't reinvent the wheel and instead look for opportunities to collaborate with and contribute to those efforts. 21 | 22 | Another important aspect to highlight is non-Cloud Native projects and products (e.g., mobile, embedded) and the CI/CD pipelines for those. It is important to include this as part of the work. 23 | 24 | # Objectives 25 | 26 | The objectives of this PoC are 27 | 28 | * Identify CI/CD activities, stages, and steps that are critical for software supply chain 29 | * Demonstrate key software supply chain activities, stages, and steps both from product perspective as well as from CI/CD technology and pipelines perspectives 30 | * Use different CI/CD tools and technologies while establishing CI/CD pipelines to demonstrate capabilities provided by them 31 | * Demonstrate the differences across the pipelines running on on-premises vs cloud based environments 32 | 33 | # Scope 34 | 35 | Based on the objectives of the PoC, the three areas to include in the scope are 36 | 37 | * Activities 38 | * Technologies 39 | * Environments 40 | 41 | Due to the size and complexity of these areas, it may be necessary to split the PoC to multiple phases. However, if the community desires to look into multiple areas in conjunction with each other, it is possible to do that as well, assuming CDF could provide compute resources. 42 | 43 | ## Activities 44 | 45 | One of the initial steps to take is to identify the activities and corresponding pipelines to be demonstrated by the PoC. Some activities are documented here in order to get the conversation started. 46 | 47 | Activities referred here are the activities that are deemed critical for security, compliance, and authenticity of the software produced by the organizations as well as third party code (e.g., open source software). The focus of this part of the PoC is on Open Source Software (OSS) due to practical reasons however most of the activities listed in this section should be applicable also to software produced by the organization. 48 | 49 | Some example activities are listed below in order to start the conversation around what activities the PoC should demonstrate. Please note that these activities documented here require to be synched with and contributed to ongoing work under other groups such as SIG Interoperability stage and step work, SIG Best Practices, and so on. 50 | 51 | ### Development 52 | 53 | ![PoC Overview](poc_overview.png "PoC Overview") 54 | 55 | #### OSS Introduction 56 | 57 | This activity deals with introduction and vetting of the OSS that is about to be used by the organization for development purposes. 58 | 59 | Inputs to this activity are 60 | 61 | * Public/upstream URL to source code repository of the primary OSS 62 | * Version of the primary OSS 63 | * Policies 64 | 65 | The tasks that could be performed under this activity/by corresponding pipeline(s) are 66 | 67 | * Community Assessment (e.g., no of contributors) 68 | * Metadata gathering (e.g., version, date) 69 | * Fetching community generated SBOM 70 | * License/copyright identification 71 | * Vulnerability analysis 72 | * Malware scanning 73 | * Quality checks (e.g., static analysis) 74 | * Policy enforcement/compliance (e.g., provenance, license, vulnerability) 75 | 76 | Outputs of this activity are 77 | 78 | * Metadata, records, logs, SBOM 79 | * Evaluation result/score based on policies 80 | 81 | Please note that the analysis/scanning tasks listed in this activity capture the state of the OSS component in that point of time when the tasks are run. However, it is possible that new issues and vulnerabilities may be disclosed over time, making the outcome of evaluation for already introduced (versions of) components outdated so it is important to run such tasks in a continuous manner to reevaluate components and address issues by updating their versions of replacing them with other components. 82 | 83 | #### OSS Storage 84 | 85 | The purpose of this activity is to store the primary OSS and its dependencies from its origin on internal/secure/trusted repositories for further activities as well as for making it available for consumption by the rest of the development organization. 86 | 87 | Inputs to this activity are 88 | 89 | * Public/upstream URL to source code repository of the primary OSS 90 | * Version of the primary OSS 91 | * Policies 92 | 93 | The tasks that could be performed under this activity/by corresponding pipeline(s) are 94 | 95 | * Download and storage of primary OSS source code 96 | * Source code based SBOM generation and analysis 97 | * Dependency analysis 98 | * Download and storage of dependencies 99 | * Delta report generation 100 | * Policy enforcement/compliance 101 | 102 | Outputs of this activity are 103 | 104 | * Metadata, records, reports, logs, delta report, SBOM 105 | * Evaluation result/score based on policies 106 | * Source code of the primary OSS on internal/secure/trusted repository 107 | * Source code of the dependencies on internal/secure/trusted repository 108 | 109 | #### OSS Consumption 110 | 111 | In most cases, organizations download and use (pre-built) artifacts/binaries of the primary OSS and its dependencies from the internet. However, this is not considered secure so building artifacts in a secure environment by using the source code stored on internal/secure/trusted repositories is a critical capability to demonstrate. 112 | 113 | Inputs to this activity are 114 | 115 | * Internal URL to source code repository of the primary OSS 116 | * Version of the primary OSS 117 | * Internal URL to source code repository of the dependencies 118 | * Policies 119 | 120 | The tasks that could be performed under this activity/by corresponding pipeline(s) are 121 | 122 | * Build 123 | * Build SBOM generation and analysis 124 | * Delta report generation 125 | * Artifact signing 126 | * Storage of binaries 127 | * Policy enforcement/compliance 128 | 129 | Outputs of this activity are 130 | 131 | * Metadata, records, reports, logs, delta report, build SBOM 132 | * Evaluation result/score based on policies 133 | * Signed artifacts/binaries of the primary OSS 134 | 135 | ### Production 136 | 137 | TBD 138 | 139 | ## Technologies 140 | 141 | The proposed PoC requires technology selections to be made in order to create the CI/CD pipelines for the activities documented in the previous chapter. 142 | 143 | ### Technology Selections 144 | 145 | \ 146 | 147 | Various communities such as CNCF and OpenSSF are actively working on reference architecture and reference implementation so the PoC is proposed to use one of them as a base. The initiatives that are proposed to be used as part of the PoC are 148 | 149 | * CNCF TAG Security Secure Software Factory Reference Architecture 150 | * OpenSSF SSF Reference Implementation (still pending to be accepted to OpenSSF) 151 | 152 | The SSF uses certain tools and technologies (e.g., Tekton Pipelines, Kyverno). However, the PoC can evolve the SSF further by introducing new technologies such as Open Policy Agent (OPA) or replacing the used technologies with others such as Jenkins X to demonstrate how one can use different technologies to have different capabilities. 153 | 154 | ### Security and Compliance of Technologies and Pipelines 155 | 156 | Another critical aspect to take into consideration is the security and compliance of the technologies and pipelines themselves so they cannot be abused by actors with malicious intentions. The activities that can be demonstrated to ensure the technologies used while establishing CI/CD systems and pipelines are similar to those used for the primary OSS however there are additional concerns to think about from pipelines perspective such as 157 | 158 | * Is the pipeline supposed to do what it is doing 159 | * Are the credentials secured 160 | * Privilege levels 161 | * Observability of pipelines 162 | 163 | ## Environments 164 | 165 | The environments used by the organizations while establishing their CI/CD pipelines differ due to various reasons and the potential risks and challenges need to be identified and demonstrated. 166 | 167 | ### On Premise 168 | 169 | Organizations that establish and run CI/CD pipelines on on-premise environments must take necessary steps to make sure their pipelines are secure and compliant. 170 | 171 | ### Cloud 172 | 173 | CI/CD services established by public cloud providers require additional aspects to be taken into consideration since the users may not have same control over the environments, technologies, and pipelines. 174 | 175 | # Resource Requirements 176 | 177 | TBD 178 | 179 | # PoC Team 180 | 181 | TBD 182 | 183 | # References 184 | 185 | * [CDF SIG Software Supply Chain Charter](https://github.com/cdfoundation/sig-software-supply-chain/blob/main/README.md) 186 | * [CDF SIG Software Supply Chain Kick Off Meeting Presentation](https://docs.google.com/presentation/d/1-nt-1Pe4WwiKoDT-ooWAxKPDunSoqeES9Qb3WTEkE9M/edit#slide=id.g1195d02e4a0_2_57) 187 | * [CDF SIG Interoperability Pipeline Stage Terminology PR](https://github.com/cdfoundation/sig-interoperability/pull/76) 188 | * [CDF SIG Interoperability Pipeline Steps PR](https://github.com/cdfoundation/sig-interoperability/pull/81) 189 | * [CDF SIG Interoperability Quality Gates Discussion](https://github.com/cdfoundation/sig-interoperability/discussions/83) 190 | * [CNCF Secure Software Factory Reference Architecture RFC](https://docs.google.com/document/d/15M_Mzfqy634E_sqoslmOXsZJl4TedpbXpBjOfz-hnXk/edit) 191 | * [CNCF TAG Security Cloud Native Security Whitepaper](https://github.com/cncf/tag-security/blob/main/security-whitepaper/CNCF_cloud-native-security-whitepaper-Nov2020.pdf) 192 | * [CNCF TAG Security Supply Chain Best Practices](https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf) 193 | * [OpenSSF SSF Reference Implementation](https://github.com/buildsec/ssf) (*proposed as a project*) 194 | * [CNCF Podtato Head](https://github.com/podtato-head/podtato-head) 195 | * [Cider Security Top 10 CI/CD Security Risks](https://www.cidersecurity.io/wp-content/uploads/2022/03/Top-10-CICD-Security-Risks-.pdf) 196 | * [CI/CD Goat](https://github.com/cider-security-research/cicd-goat) 197 | -------------------------------------------------------------------------------- /poc/poc_overview.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cdfoundation/sig-software-supply-chain/8cbb2cda64e2694bfe6ceea2726d7505128fe711/poc/poc_overview.png -------------------------------------------------------------------------------- /workstreams/archived/scmm/README.md: -------------------------------------------------------------------------------- 1 | # Supply Chain Maturity Model Workstream 2 | 3 | **Note! This workstream achieved the desirable outcome and it is now archived. Followup conversations will take place in [SIG Software Supply Chain](../../../README.md)** 4 | 5 | The Supply Chain Maturity Model workstream was proposed on 6 | [August 25, 2022](https://github.com/cdfoundation/sig-software-supply-chain/blob/main/docs/meetings.md#August-25-2022) 7 | and continued until January 2023. 8 | 9 | The workstream produced a [Supply Chain Maturity 10 | Guide](https://github.com/cdfoundation/sig-software-supply-chain/blob/main/docs/supply-chain-maturity.md) which is included this repository. 11 | 12 | The below details are maintained for historical purposes. 13 | 14 | ## Scope 15 | 16 | The workstream will cover CICD beyond build and deploy. 17 | 18 | ## Mission 19 | 20 | The workstream seeks to define industry standards for Supply Chain Maturity that 21 | augment [SLSA](http://slsa.dev). Where SLSA covers the supply chain from code 22 | through artifact, maturity covers the artifact lifecycle, including deployments, 23 | rollouts, testing, rollbacks, and more. 24 | 25 | The workstream seeks to define an industry standard to augment [SLSA](http://slsa.dev). 26 | 27 | Proposed names so far include: 28 | * Code Health Project Score ("CHiPS") (but it conflicts with [CHIPS 29 | Alliance](https://chipsalliance.org/) under the Linux Foundation) 30 | * Guide for Understanding Application Concerns ("GUAC") (but it conflicts with the [GUAC project](https://github.com/guacsec/guac) from Google/Kusari/Purdue/Citi)) 31 | 32 | For current goals, see our [roadmap](ROADMAP.md). 33 | 34 | ## Members 35 | Current members: 36 | * David Bendory, Google 37 | * Justin Abrahms, eBay/CDF 38 | * Ankit D Mohapatra, Berkshire Grey 39 | * Parth Patel, Kusari 40 | * Kara de la Marck, CDF 41 | * David Espejo, VMware 42 | * 43 | 44 | Membership to this workstream is open and self-declared. 45 | 46 | New members are invited to: 47 | * Join the [#wg-supply-chain-maturity on CDF 48 | Slack](https://cdeliveryfdn.slack.com/archives/C03V8R6C64C) and introduce 49 | yourself. 50 | * Regularly join the [workstream meetings](#supply-chain-maturity-workstream-meetings) 51 | * Join our Google Group at https://groups.google.com/g/cdf-scm -- for access to shared documents. 52 | 53 | ## Communication Channels 54 | 55 | **This workstream slack channel is no longer active.** 56 | 57 | Please join the main SIG slack discussion instead. 58 | 59 | ## Meetings 60 | 61 | **This workstream no longer meets.** 62 | 63 | Historic meeting notes are available 64 | [here](https://hackmd.io/xq6lH4F7RUWmqZhluMcgLw). 65 | -------------------------------------------------------------------------------- /workstreams/archived/scmm/ROADMAP.md: -------------------------------------------------------------------------------- 1 | # Roadmap 2 | 3 | **This workstream is no longer active; the below is maintained for historical 4 | purposes.** 5 | 6 | ## Mission: Define industry standards for Supply Chain Maturity. 7 | 8 | The Working Group seeks to define standards for measuring supply chain maturity. 9 | 10 | Supply chain maturity metrics will cover artifact creation and management, 11 | testing, rollouts, deployments, rollbacks, and more. Defined maturity levels will 12 | enable practitioners to identify growth areas and improve their supply chain management 13 | using measurable best practices with defined goals and benefits. 14 | 15 | ### Related Work 16 | 17 | [SLSA](http://slsa.dev) covers the supply chain from code through artifact enabling 18 | better supply chain integrity and security by ensuring reliable provenance for built 19 | artifacts. SLSA serves as an input to Supply Chain Maturity; the existence of similar 20 | levels and definitions across the supply chain will shape our maturity ladder. 21 | 22 | ## Identified Roadmap Goals 23 | 24 | Currently identified goals: 25 | 26 | * [ ] Identify a clever acronym to capture "Supply Chain Maturity" 27 | * [x] Define Metrics to assess Supply Chain Maturity 28 | * [x] Brainstorm metrics [doc](https://docs.google.com/document/d/1rGvQv2GH8HYbQUZxg89LmWsYe8-MyeTEcj08nwULitw/edit?pli=1#) 29 | * [x] Draft metrics explanation [doc](https://docs.google.com/document/d/1CDSbQezqauwL2BaFob7o2ztLk6dTQGZqZCMZ_szNhW8/edit?resourcekey=0-ooiOpNu2gyR-KOlMNOCcDA) 30 | * [x] Working Group adopts draft 31 | * [ ] Draft [best practices assessment](https://bestpractices.cd.foundation/learn/assess/) 32 | * [ ] Working Group adopts draft 33 | * [ ] Contribute content to Best Practices SIG and website 34 | * [ ] Identify tooling to measure and assess metrics 35 | * [ ] Provide guidance for instrumenting common CICD tooling for assessment 36 | * [ ] Demonstrate a reference implementation 37 | --------------------------------------------------------------------------------