├── Scope.md ├── License.md ├── Notices.md ├── SECURITY.md ├── README.md ├── Contributing.md ├── Code_of_Conduct.md ├── Governance.md ├── Community_Specification_License-v1.md ├── Specification.md └── images ├── spec ├── Workflow - Self-Attestation.svg └── Standards.svg └── workflow.svg /Scope.md: -------------------------------------------------------------------------------- 1 | # Scope 2 | 3 | The Supply Chain Integrity Model (SCIM) specifies an end-to-end system for validating arbitrary artifacts in terms of supply chains whose integrity has been proven. 4 | 5 | SCIM is applicable to both hardware (objects in the physical world) and software (digital) artifacts. 6 | 7 | SCIM defines minimum standards around the preparation, storage, distribution, consumption, validation and evaluation of arbitrary evidence about artifacts that are critical to maintaining the integrity of supply chains. 8 | 9 | SCIM does not define how artifacts are produced or distributed, nor the methods by which evidence about artifacts is produced prior to preparation for inclusion in SCIM. 10 | 11 | Any changes to this scope are not retroactive. 12 | -------------------------------------------------------------------------------- /License.md: -------------------------------------------------------------------------------- 1 | # Licenses 2 | 3 | ## Specification License 4 | 5 | Specifications in the repository are subject to the **Community Specification License 1.0** available at [https://github.com/CommunitySpecification/1.0](https://github.com/CommunitySpecification/1.0). 6 | 7 | ## Source Code License 8 | 9 | If source code is included in this repository, or for sample or reference code included in the specification itself, that code is subject to the MIT license unless otherwise designated. In the case of any conflict or confusion within this specification repository between the Community Specification License and the MIT or other designated license, the terms of the Community Specification License shall apply. 10 | 11 | If source code is included in this repository, or for sample or reference code included in the specification itself, that code is subject to the MIT license unless otherwise marked. 12 | 13 | In the case of any conflict or confusion within this specification repository between the Community Specification License and the designated source code license, the terms of the Community Specification License shall apply. 14 | -------------------------------------------------------------------------------- /Notices.md: -------------------------------------------------------------------------------- 1 | # Notices 2 | 3 | ## Code of Conduct 4 | 5 | Contact for Code of Conduct issues or inquires: [opencode@microsoft.com](mailto:opencode@microsoft.com) 6 | 7 | 8 | ## License Acceptance 9 | 10 | Per Community Specification License 1.0 Section 2.1.3.3, Licensees may indicate their acceptance of the Community Specification License by issuing a pull request to the Specification’s repository’s Notice.md file, including the Licensee’s name, authorized individuals' names, and repository system identifier (e.g. GitHub ID), and specification version. 11 | 12 | A Licensee may consent to accepting the current Community Specification License version or any future version of the Community Specification License by indicating "or later" after their specification version. 13 | 14 | --------------------------------------------------------------------------------- 15 | 16 | Licensee’s name: 17 | 18 | Authorized individual and system identifier: 19 | 20 | Specification version: 21 | 22 | --------------------------------------------------------------------------------- 23 | 24 | ## Withdrawals 25 | 26 | Name of party withdrawing: 27 | 28 | Date of withdrawal: 29 | 30 | --------------------------------------------------------------------------------- 31 | 32 | ## Exclusions 33 | 34 | This section includes any Exclusion Notices made against a Draft Deliverable or Approved Deliverable as set forth in the Community Specification Development License. Each Exclusion Notice must include the following information: 35 | 36 | - Name of party making the Exclusion Notice: 37 | 38 | - Name of patent owner: 39 | 40 | - Specification: 41 | 42 | - Version number: 43 | 44 | **For issued patents and published patent applications:** 45 | 46 | (i) patent number(s) or title and application number(s), as the case may be: 47 | 48 | (ii) identification of the specific part(s) of the Specification whose implementation makes the excluded claim a Necessary Claim. 49 | 50 | **For unpublished patent applications must provide either:** 51 | 52 | (i) the text of the filed application; or 53 | 54 | (ii) identification of the specific part(s) of the Specification whose implementation makes the excluded claim a Necessary Claim. 55 | 56 | ----------------------------------------------------------------------------------------- 57 | -------------------------------------------------------------------------------- /SECURITY.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | ## Security 4 | 5 | Microsoft takes the security of our software products and services seriously, which includes all source code repositories managed through our GitHub organizations, which include [Microsoft](https://github.com/microsoft), [Azure](https://github.com/Azure), [DotNet](https://github.com/dotnet), [AspNet](https://github.com/aspnet), [Xamarin](https://github.com/xamarin), and [our GitHub organizations](https://opensource.microsoft.com/). 6 | 7 | If you believe you have found a security vulnerability in any Microsoft-owned repository that meets [Microsoft's definition of a security vulnerability](https://aka.ms/opensource/security/definition), please report it to us as described below. 8 | 9 | ## Reporting Security Issues 10 | 11 | **Please do not report security vulnerabilities through public GitHub issues.** 12 | 13 | Instead, please report them to the Microsoft Security Response Center (MSRC) at [https://msrc.microsoft.com/create-report](https://aka.ms/opensource/security/create-report). 14 | 15 | If you prefer to submit without logging in, send email to [secure@microsoft.com](mailto:secure@microsoft.com). If possible, encrypt your message with our PGP key; please download it from the [Microsoft Security Response Center PGP Key page](https://aka.ms/opensource/security/pgpkey). 16 | 17 | You should receive a response within 24 hours. If for some reason you do not, please follow up via email to ensure we received your original message. Additional information can be found at [microsoft.com/msrc](https://aka.ms/opensource/security/msrc). 18 | 19 | Please include the requested information listed below (as much as you can provide) to help us better understand the nature and scope of the possible issue: 20 | 21 | * Type of issue (e.g. buffer overflow, SQL injection, cross-site scripting, etc.) 22 | * Full paths of source file(s) related to the manifestation of the issue 23 | * The location of the affected source code (tag/branch/commit or direct URL) 24 | * Any special configuration required to reproduce the issue 25 | * Step-by-step instructions to reproduce the issue 26 | * Proof-of-concept or exploit code (if possible) 27 | * Impact of the issue, including how an attacker might exploit the issue 28 | 29 | This information will help us triage your report more quickly. 30 | 31 | If you are reporting for a bug bounty, more complete reports can contribute to a higher bounty award. Please visit our [Microsoft Bug Bounty Program](https://aka.ms/opensource/security/bounty) page for more details about our active programs. 32 | 33 | ## Preferred Languages 34 | 35 | We prefer all communications to be in English. 36 | 37 | ## Policy 38 | 39 | Microsoft follows the principle of [Coordinated Vulnerability Disclosure](https://aka.ms/opensource/security/cvd). 40 | 41 | 42 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | ## NOTE: The SCIM effort has a new name and location 2 | - This site is now deprecated. 3 | - Join us instead at https://github.com/ietf-scitt. 4 | 5 | ## Overview 6 | 7 | The Supply Chain Integrity Model (SCIM) supports the ongoing verification of artifacts, including hardware and software components, where the authenticity of entities, evidence, policy, and artifacts can be assured and the actions of entities can be guaranteed to be authorized, non-repudiable, immutable, and auditable. The proposed SCIM will be an industry standard specification, easing the path for uniform data flow across globally distributed supply chains. 8 | 9 | SCIM aligns with an iterative approach to developing and implementing supply chain integrity requirements, allowing for enhancements over time based on evolving threat models and practices. A phased roll out of requirements promotes clarity for supplier planning and engineering and minimize disruptions. 10 | 11 | Note: SCIM describes principles and a proposed model and system for conveying evidence. It does not address what evidence or information for attestation of conformity must be conveyed. 12 | 13 | ## Workflow 14 | 15 | The following diagram depicts the flow of artifacts, evidence and policies between entities in the Supply Chain Integrity Model. 16 | 17 |

18 | 19 | A Supplier creates an Artifact (a). An Attester creates Evidence (b) and submits to a Store for logging, query, and retrieval. The Supplier and Attester may be the same entity. A Policy Manager creates Policy (c) and submits to a Store where it is recorded and made available for query and retrieval. A User Agent receives an Artifact, retrieves Evidence and Policy, and verifies the Artifact (d). 20 | 21 | ## Example Application 22 | 23 | The diagram below shows an example application of SCIM to the Software Development Lifecycle (SDLC). 24 | 25 |

26 | 27 | ## Specifications 28 | 29 | The table below maps proposed SCIM specifications to existing industry specifications. 30 | 31 | SCIM | Existing 32 | ---- | -------- 33 | The SCIM-Evidence specification defines an extensible data model and exchange format for providing all types of evidence (bills of materials, build information, configuration settings, security assurances, certifications, vulnerabilities, end of life information) for all types of artifacts (hardware, software, services, machine learning models, etc.). | [SWID](https://nvd.nist.gov/products/swid), [SPDX](https://spdx.dev), [CycloneDX](https://cyclonedx.org), [in-toto](https://in-toto.io), [RATS](https://datatracker.ietf.org/doc/html/draft-ietf-rats-architecture-10), and others 34 | The SCIM-Policy specification defines a data model and exchange format for providing policy for use in evaluating artifacts for a specified use. | [in-toto](https://in-toto.io), [RATS](https://datatracker.ietf.org/doc/html/draft-ietf-rats-architecture-10), and others 35 | The SCIM-Store specification defines a rich, graph-aware storage API that allows read, write and query of Evidence and Policy. | [DBOM](https://dbom-project.readthedocs.io/en/latest), [Grafeas](https://grafeas.io), [RATS](https://datatracker.ietf.org/doc/html/draft-ietf-rats-architecture-10), [CCF](https://github.com/microsoft/ccf) and others 36 | 37 | ## Roadmap 38 | 39 | - Phase 1 40 | - Organizations use existing tools and specifications to begin implementing [US Cyber EO](https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/) Section 4 requirements, including SBOMs. 41 | - SCIM community organized for the development of end-to-end standards. 42 | 43 | - Phase 2 44 | - Organizations begin adopting SCIM specifications, which encompass and extend existing initiatives. 45 | - SCIM specifications proposed to international standards bodies. 46 | 47 | - Phase 3 48 | - SCIM specifications ratified by international standards bodies. 49 | - Widespread adoption of end-to-end model across globally distributed supply chains. 50 | 51 | ## Contributing 52 | 53 | Community Meetings: 54 | - SCIM community meetings are held each Monday at 8:05 AM Pacific. Email kayw@microsoft.com to be added to the meeting invitation. 55 | 56 | Technical Meetings: 57 | - SCIM technical meetings are held each Tuesday and Thursday at 8:00 AM Pacific. Email marieche@microsoft.com to be added to the meeting invitation. 58 | 59 | Meeting Agenda and Minutes (both community and technical meetings): 60 | - https://docs.google.com/document/d/1vf-EliXByhg5HZfgVbTqZhfaJFCmvMdQuZ4tC-Eq6wg/edit?usp=sharing 61 | 62 | Meeting Videos (both community and technical meetings): 63 | - https://www.youtube.com/playlist?list=PL6EgWS5xrcg4J3vYdv9SL8MyZMp14DxBv 64 | 65 | SCIM Vision 66 | - https://docs.google.com/document/d/1UnpSIVJuw3dha3twRCzzwgeyul9qKNoAhQ1whfzUto0/edit?usp=sharing 67 | -------------------------------------------------------------------------------- /Contributing.md: -------------------------------------------------------------------------------- 1 | # Community Specification Contribution Policy 1.0 2 | 3 | This document provides the contribution policy for specifications and other documents developed using the Community Specification process in a repository (each a “Working Group”). Additional or alternate contribution policies may be adopted and documented by the Working Group. 4 | 5 | ## 1. Contribution Guidelines. 6 | 7 | This Working Group accepts contributions via pull requests. The following section outlines the process for merging contributions to the specification 8 | 9 | **1.1. Issues.** Issues are used as the primary method for tracking anything to do with this specification Working Group. 10 | 11 | **1.1.1. Issue Types.** There are three types of issues (each with their own corresponding label): 12 | 13 | **1.1.1.1. Discussion.** These are support or functionality inquiries that we want to have a record of for future reference. Depending on the discussion, these can turn into "Spec Change" issues. 14 | 15 | **1.1.1.2. Proposal.** Used for items that propose a new ideas or functionality that require a larger discussion. This allows for feedback from others before a specification change is actually written. All issues that are proposals should both have a label and an issue title of "Proposal: [the rest of the title]." A proposal can become a "Spec Change" and does not require a milestone. 16 | 17 | **1.1.1.3. Spec Change:** These track specific spec changes and ideas until they are complete. They can evolve from "Proposal" and "Discussion" items, or can be submitted individually depending on the size. Each spec change should be placed into a milestone. 18 | 19 | ## 2. Issue Lifecycle. 20 | 21 | The issue lifecycle is mainly driven by the Maintainer. All issue types follow the same general lifecycle. Differences are noted below. 22 | 23 | **2.1. Issue Creation.** 24 | 25 | **2.2. Triage.** 26 | 27 | o The Editor in charge of triaging will apply the proper labels for the issue. This includes labels for priority, type, and metadata. 28 | 29 | o (If needed) Clean up the title to succinctly and clearly state the issue. Also ensure that proposals are prefaced with "Proposal". 30 | 31 | **2.3. Discussion.** 32 | 33 | o "Spec Change" issues should be connected to the pull request that resolves it. 34 | 35 | o Whoever is working on a "Spec Change" issue should either assign the issue to themselves or make a comment in the issue saying that they are taking it. 36 | 37 | o "Proposal" and "Discussion" issues should stay open until resolved. 38 | 39 | **2.4. Issue Closure.** 40 | 41 | ## 3. How to Contribute a Patch. 42 | 43 | The Working Group uses pull requests to track changes. To submit a change to the specification: 44 | 45 | **3.1 Fork the Repo, modify the Specification to Address the Issue.** 46 | 47 | **3.2. Submit a Pull Request.** 48 | 49 | ## 4. Pull Request Workflow. 50 | 51 | The next section contains more information on the workflow followed for Pull Requests. 52 | 53 | **4.1. Pull Request Creation.** 54 | 55 | o We welcome pull requests that are currently in progress. They are a great way to keep track of important work that is in-flight, but useful for others to see. If a pull request is a work in progress, it should be prefaced with "WIP: [title]". You should also add the wip label Once the pull request is ready for review, remove "WIP" from the title and label. 56 | 57 | o It is preferred, but not required, to have a pull request tied to a specific issue. There can be circumstances where if it is a quick fix then an issue might be overkill. The details provided in the pull request description would suffice in this case. 58 | 59 | **4.2. Triage** 60 | 61 | o The Editor in charge of triaging will apply the proper labels for the issue. This should include at least a size label, a milestone, and awaiting review once all labels are applied. 62 | 63 | **4.3. Reviewing/Discussion.** 64 | 65 | o All reviews will be completed using the review tool. 66 | 67 | o A "Comment" review should be used when there are questions about the spec that should be answered, but that don't involve spec changes. This type of review does not count as approval. 68 | 69 | o A "Changes Requested" review indicates that changes to the spec need to be made before they will be merged. 70 | 71 | o Reviewers should update labels as needed (such as needs rebase). 72 | 73 | o When a review is approved, the reviewer should add LGTM as a comment. 74 | 75 | o Final approval is required by a designated Editor. Merging is blocked without this final approval. Editors will factor reviews from all other reviewers into their approval process. 76 | 77 | **4.4. Responsive.** Pull request owner should try to be responsive to comments by answering questions or changing text. Once all comments have been addressed, the pull request is ready to be merged. 78 | 79 | **4.5. Merge or Close.** 80 | 81 | o A pull request should stay open until a Maintainer has marked the pull request as approved. 82 | 83 | o Pull requests can be closed by the author without merging. 84 | 85 | o Pull requests may be closed by a Maintainer if the decision is made that it is not going to be merged. 86 | -------------------------------------------------------------------------------- /Code_of_Conduct.md: -------------------------------------------------------------------------------- 1 | # Contributor Covenant Code of Conduct 2 | 3 | ## Our Pledge 4 | 5 | We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation. 6 | 7 | We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community. 8 | 9 | ## Our Standards 10 | 11 | Examples of behavior that contributes to a positive environment for our community include: 12 | 13 | * Demonstrating empathy and kindness toward other people 14 | * Being respectful of differing opinions, viewpoints, and experiences 15 | * Giving and gracefully accepting constructive feedback 16 | * Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience 17 | * Focusing on what is best not just for us as individuals, but for the overall community 18 | 19 | Examples of unacceptable behavior include: 20 | 21 | * The use of sexualized language or imagery, and sexual attention or 22 | advances of any kind 23 | * Trolling, insulting or derogatory comments, and personal or political attacks 24 | * Public or private harassment 25 | * Publishing others' private information, such as a physical or email 26 | address, without their explicit permission 27 | * Other conduct which could reasonably be considered inappropriate in a 28 | professional setting 29 | 30 | ## Enforcement Responsibilities 31 | 32 | Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful. 33 | 34 | Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate. 35 | 36 | ## Scope 37 | 38 | This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. 39 | 40 | ## Enforcement 41 | 42 | Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement as set forth in the repository's Notice.md file. All complaints will be reviewed and investigated promptly and fairly. 43 | 44 | All community leaders are obligated to respect the privacy and security of the reporter of any incident. 45 | 46 | ## Enforcement Guidelines 47 | 48 | Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct: 49 | 50 | ### 1. Correction 51 | 52 | **Community Impact**: Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community. 53 | 54 | **Consequence**: A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested. 55 | 56 | ### 2. Warning 57 | 58 | **Community Impact**: A violation through a single incident or series of actions. 59 | 60 | **Consequence**: A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban. 61 | 62 | ### 3. Temporary Ban 63 | 64 | **Community Impact**: A serious violation of community standards, including sustained inappropriate behavior. 65 | 66 | **Consequence**: A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban. 67 | 68 | ### 4. Permanent Ban 69 | 70 | **Community Impact**: Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals. 71 | 72 | **Consequence**: A permanent ban from any sort of public interaction within the project community. 73 | 74 | ## Attribution 75 | 76 | This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 2.0, 77 | available at https://www.contributor-covenant.org/version/2/0/code_of_conduct.html. 78 | 79 | Community Impact Guidelines were inspired by [Mozilla's code of conduct enforcement ladder](https://github.com/mozilla/diversity). 80 | 81 | [homepage]: https://www.contributor-covenant.org 82 | 83 | For answers to common questions about this code of conduct, see the FAQ at 84 | https://www.contributor-covenant.org/faq. Translations are available at https://www.contributor-covenant.org/translations. 85 | -------------------------------------------------------------------------------- /Governance.md: -------------------------------------------------------------------------------- 1 | # Community Specification Governance Policy 1.0 2 | 3 | This document provides the governance policy for specifications and other documents developed using the Community Specification process in a repository (each a “Working Group”). Each Working Group and must adhere to the requirements in this document. 4 | 5 | ## 1. Roles. 6 | 7 | Each Working Group may include the following roles. Additional roles may be adopted and documented by the Working Group. 8 | 9 | **1.1. Maintainer.** “Maintainers” are responsible for organizing activities around developing, maintaining, and updating the specification(s) developed by the Working Group. Maintainers are also responsible for determining consensus and coordinating appeals. Each Working Group will designate one or more Maintainer for that Working Group. A Working Group may select a new or additional Maintainer(s) upon Approval of the Working Group Participants. 10 | 11 | **1.2. Editor.** “Editors” are responsible for ensuring that the contents of the document accurately reflect the decisions that have been made by the group, and that the specification adheres to formatting and content guidelines. Each Working Group will designate an Editor for that Working Group. A Working Group may select a new Editor upon Approval of the Working Group Participants. 12 | 13 | **1.3. Participants.** “Participants” are those that have made Contributions to the Working Group subject to the Community Specification License. 14 | 15 | ## 2. Decision Making. 16 | 17 | **2.1. Consensus-Based Decision Making.** Working Groups make decisions through a consensus process (“Approval” or “Approved”). While the agreement of all Participants is preferred, it is not required for consensus. Rather, the Maintainer will determine consensus based on their good faith consideration of a number of factors, including the dominant view of the Working Group Participants and nature of support and objections. The Maintainer will document evidence of consensus in accordance with these requirements. 18 | 19 | **2.2. Appeal Process.** Decisions may be appealed be via a pull request or an issue, and that appeal will be considered by the Maintainer in good faith, who will respond in writing within a reasonable time. 20 | 21 | ## 3. Ways of Working. 22 | 23 | Inspired by [ANSI’s Essential Requirements for Due Process](https://share.ansi.org/Shared%20Documents/Standards%20Activities/American%20National%20Standards/Procedures,%20Guides,%20and%20Forms/2020_ANSI_Essential_Requirements.pdf), Community Specification Working Groups must adhere to consensus-based due process requirements. These requirements apply to activities related to the development of consensus for approval, revision, reaffirmation, and withdrawal of Community Specifications. Due process means that any person (organization, company, government agency, individual, etc.) with a direct and material interest has a right to participate by: a) expressing a position and its basis, b) having that position considered, and c) having the right to appeal. Due process allows for equity and fair play. The following constitute the minimum acceptable due process requirements for the development of consensus. 24 | 25 | **3.1. Openness.** Participation shall be open to all persons who are directly and materially affected by the activity in question. There shall be no undue financial barriers to participation. Voting membership on the consensus body shall not be conditional upon membership in any organization, nor unreasonably restricted on the basis of technical qualifications or other such requirements. Membership in a Working Group’s parent organization, if any, may be required. 26 | 27 | **3.2. Lack of Dominance.** The development process shall not be dominated by any single interest category, individual or organization. Dominance means a position or exercise of dominant authority, leadership, or influence by reason of superior leverage, strength, or representation to the exclusion of fair and equitable consideration of other viewpoints. 28 | 29 | **3.3. Balance.** The development process should have a balance of interests. Participants from diverse interest categories shall be sought with the objective of achieving balance. 30 | 31 | **3.4. Coordination and Harmonization.** Good faith efforts shall be made to resolve potential conflicts between and among deliverables developed under this Working Group and existing industry standards. 32 | 33 | **3.5. Consideration of Views and Objections.** Prompt consideration shall be given to the written views and objections of all Participants. 34 | 35 | **3.6. Written procedures.** This governance document and other materials documenting the Community Specification development process shall be available to any interested person. 36 | 37 | ## 4. Specification Development Process. 38 | 39 | **4.1. Pre-Draft.** Any Participant may submit a proposed initial draft document as a candidate Draft Specification of that Working Group. The Maintainer will designate each submission as a “Pre-Draft” document. 40 | 41 | **4.2. Draft.** Each Pre-Draft document of a Working Group must first be Approved to become a” Draft Specification”. Once the Working Group approves a document as a Draft Specification, the Draft Specification becomes the basis for all going forward work on that specification. 42 | 43 | **4.3. Working Group Approval.** Once a Working Group believes it has achieved the objectives for its specification as described in the Scope, it will Approve that Draft Specification and progress it to “Approved Specification” status. 44 | 45 | **4.4. Publication and Submission.** Upon the designation of a Draft Specification as an Approved Specification, the Maintainer will publish the Approved Specification in a manner agreed upon by the Working Group Participants (i.e., Working Group Participant only location, publicly available location, Working Group maintained website, Working Group member website, etc.). The publication of an Approved Specification in a publicly accessible manner must include the terms under which the Approved Specification is being made available under. 46 | 47 | **4.5. Submissions to Standards Bodies.** No Draft Specification or Approved Specification may be submitted to another standards development organization without Working group Approval. Upon reaching Approval, the Maintainer will coordinate the submission of the applicable Draft Specification or Approved Specification to another standards development organization. Working Group Participants that developed that Draft Specification or Approved Specification agree to grant the copyright rights necessary to make those submissions. 48 | 49 | ## 5. Non-Confidential, Restricted Disclosure. 50 | 51 | Information disclosed in connection with any Working Group activity, including but not limited to meetings, Contributions, and submissions, is not confidential, regardless of any markings or statements to the contrary. Notwithstanding the foregoing, if the Working Group is collaborating via a private repository, the Participants will not make any public disclosures of that information contained in that private repository without the Approval of the Working Group. 52 | -------------------------------------------------------------------------------- /Community_Specification_License-v1.md: -------------------------------------------------------------------------------- 1 | # Community Specification License 1.0 2 | 3 | **The Purpose of this License.** This License sets forth the terms under which 1) Contributor will participate in and contribute to the development of specifications, standards, best practices, guidelines, and other similar materials under this Working Group, and 2) how the materials developed under this License may be used. It is not intended for source code. Capitalized terms are defined in the License’s last section. 4 | 5 | **1. Copyright.** 6 | 7 | **1.1. Copyright License.** Contributor grants everyone a non-sublicensable, perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as expressly stated in this License) copyright license, without any obligation for accounting, to reproduce, prepare derivative works of, publicly display, publicly perform, and distribute any materials it submits to the full extent of its copyright interest in those materials. Contributor also acknowledges that the Working Group may exercise copyright rights in the Specification, including the rights to submit the Specification to another standards organization. 8 | 9 | **1.2. Copyright Attribution.** As a condition, anyone exercising this copyright license must include attribution to the Working Group in any derivative work based on materials developed by the Working Group. That attribution must include, at minimum, the material’s name, version number, and source from where the materials were retrieved. Attribution is not required for implementations of the Specification. 10 | 11 | **2. Patents.** 12 | 13 | **2.1. Patent License.** 14 | 15 | **2.1.1. As a Result of Contributions.** 16 | 17 | **2.1.1.1. As a Result of Contributions to Draft Specifications.** Contributor grants Licensee a non-sublicensable, perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as expressly stated in this License) license to its Necessary Claims in 1) Contributor’s Contributions and 2) to the Draft Specification that is within Scope as of the date of that Contribution, in both cases for Licensee’s Implementation of the Draft Specification, except for those patent claims excluded by Contributor under Section 3. 18 | 19 | **2.1.1.2. For Approved Specifications.** Contributor grants Licensee a non-sublicensable, perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as expressly stated in this License) license to its Necessary Claims included the Approved Specification that are within Scope for Licensee’s Implementation of the Approved Specification, except for those patent claims excluded by Contributor under Section 3. 20 | 21 | **2.1.2. Patent Grant from Licensee.** Licensee grants each other Licensee a non-sublicensable, perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as expressly stated in this License) license to its Necessary Claims for its Implementation, except for those patent claims excluded under Section 3. 22 | 23 | **2.1.3. Licensee Acceptance.** The patent grants set forth in Section 2.1 extend only to Licensees that have indicated their agreement to this License as follows: 24 | 25 | **2.1.3.1. Source Code Distributions.** For distribution in source code, by including this License in the root directory of the source code with the Implementation; 26 | 27 | **2.1.3.2. Non-Source Code Distributions.** For distribution in any form other than source code, by including this License in the documentation, legal notices, via notice in the software, and/or other written materials provided with the Implementation; or 28 | 29 | **2.1.3.3. Via Notices.md.** By issuing pull request or commit to the Specification’s repository’s Notices.md file by the Implementer’s authorized representative, including the Implementer’s name, authorized individual and system identifier, and Specification version. 30 | 31 | **2.1.4. Defensive Termination.** If any Licensee files or maintains a claim in a court asserting that a Necessary Claim is infringed by an Implementation, any licenses granted under this License to the Licensee are immediately terminated unless 1) that claim is directly in response to a claim against Licensee regarding an Implementation, or 2) that claim was brought to enforce the terms of this License, including intervention in a third-party action by a Licensee. 32 | 33 | **2.1.5. Additional Conditions.** This License is not an assurance (i) that any of Contributor’s copyrights or issued patent claims cover an Implementation of the Specification or are enforceable or (ii) that an Implementation of the Specification would not infringe intellectual property rights of any third party. 34 | 35 | **2.2. Patent Licensing Commitment.** In addition to the rights granted in Section 2.1, Contributor agrees to grant everyone a no charge, royalty-free license on reasonable and non-discriminatory terms to Contributor’s Necessary Claims that are within Scope for: 36 | 1) Implementations of a Draft Specification, where such license applies only to those Necessary Claims infringed by implementing Contributor's Contribution(s) included in that Draft Specification, and 37 | 2) Implementations of the Approved Specification. 38 | 39 | This patent licensing commitment does not apply to those claims subject to Contributor’s Exclusion Notice under Section 3. 40 | 41 | **2.3. Effect of Withdrawal.** Contributor may withdraw from the Working Group by issuing a pull request or commit providing notice of withdrawal to the Working Group repository’s Notices.md file. All of Contributor’s existing commitments and obligations with respect to the Working Group up to the date of that withdrawal notice will remain in effect, but no new obligations will be incurred. 42 | 43 | **2.4. Binding Encumbrance.** This License is binding on any future owner, assignee, or party who has been given the right to enforce any Necessary Claims against third parties. 44 | 45 | **3. Patent Exclusion.** 46 | 47 | **3.1. As a Result of Contributions.** Contributor may exclude Necessary Claims from its licensing commitments incurred under Section 2.1.1 by issuing an Exclusion Notice within 45 days of the date of that Contribution. Contributor may not issue an Exclusion Notice for any material that has been included in a Draft Deliverable for more than 45 days prior to the date of that Contribution. 48 | 49 | **3.2. As a Result of a Draft Specification Becoming an Approved Specification.** Prior to the adoption of a Draft Specification as an Approved Specification, Contributor may exclude Necessary Claims from its licensing commitments under this Agreement by issuing an Exclusion Notice. Contributor may not issue an Exclusion Notice for patents that were eligible to have been excluded pursuant to Section 3.1. 50 | 51 | **4. Source Code License.** Any source code developed by the Working Group is solely subject the source code license included in the Working Group’s repository for that code. If no source code license is included, the source code will be subject to the MIT License. 52 | 53 | **5. No Other Rights.** Except as specifically set forth in this License, no other express or implied patent, trademark, copyright, or other rights are granted under this License, including by implication, waiver, or estoppel. 54 | 55 | **6. Antitrust Compliance.** Contributor acknowledge that it may compete with other participants in various lines of business and that it is therefore imperative that they and their respective representatives act in a manner that does not violate any applicable antitrust laws and regulations. This License does not restrict any Contributor from engaging in similar specification development projects. Each Contributor may design, develop, manufacture, acquire or market competitive deliverables, products, and services, and conduct its business, in whatever way it chooses. No Contributor is obligated to announce or market any products or services. Without limiting the generality of the foregoing, the Contributors agree not to have any discussion relating to any product pricing, methods or channels of product distribution, division of markets, allocation of customers or any other topic that should not be discussed among competitors under the auspices of the Working Group. 56 | 57 | **7. Non-Circumvention.** Contributor agrees that it will not intentionally take or willfully assist any third party to take any action for the purpose of circumventing any obligations under this License. 58 | 59 | **8. Representations, Warranties and Disclaimers.** 60 | 61 | **8.1. Representations, Warranties and Disclaimers.** Contributor and Licensee represents and warrants that 1) it is legally entitled to grant the rights set forth in this License and 2) it will not intentionally include any third party materials in any Contribution unless those materials are available under terms that do not conflict with this License. IN ALL OTHER RESPECTS ITS CONTRIBUTIONS ARE PROVIDED "AS IS." The entire risk as to implementing or otherwise using the Contribution or the Specification is assumed by the implementer and user. Except as stated herein, CONTRIBUTOR AND LICENSEE EXPRESSLY DISCLAIM ANY WARRANTIES (EXPRESS, IMPLIED, OR OTHERWISE), INCLUDING IMPLIED WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT, FITNESS FOR A PARTICULAR PURPOSE, CONDITIONS OF QUALITY, OR TITLE, RELATED TO THE CONTRIBUTION OR THE SPECIFICATION. IN NO EVENT WILL ANY PARTY BE LIABLE TO ANY OTHER PARTY FOR LOST PROFITS OR ANY FORM OF INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER FROM ANY CAUSES OF ACTION OF ANY KIND WITH RESPECT TO THIS AGREEMENT, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDING NEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT THE OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Any obligations regarding the transfer, successors in interest, or assignment of Necessary Claims will be satisfied if Contributor or Licensee notifies the transferee or assignee of any patent that it knows contains Necessary Claims or necessary claims under this License. Nothing in this License requires Contributor to undertake a patent search. If Contributor is 1) employed by or acting on behalf of an employer, 2) is making a Contribution under the direction or control of a third party, or 3) is making the Contribution as a consultant, contractor, or under another similar relationship with a third party, Contributor represents that they have been authorized by that party to enter into this License on its behalf. 62 | 63 | **8.2. Distribution Disclaimer.** Any distributions of technical information to third parties must include a notice materially similar to the following: “THESE MATERIALS ARE PROVIDED “AS IS.” The Contributors and Licensees expressly disclaim any warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to the materials. The entire risk as to implementing or otherwise using the materials is assumed by the implementer and user. IN NO EVENT WILL THE CONTRIBUTORS OR LICENSEES BE LIABLE TO ANY OTHER PARTY FOR LOST PROFITS OR ANY FORM OF INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER FROM ANY CAUSES OF ACTION OF ANY KIND WITH RESPECT TO THIS DELIVERABLE OR ITS GOVERNING AGREEMENT, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDING NEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT THE OTHER MEMBER HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.” 64 | 65 | **9. Definitions.** 66 | 67 | **9.1. Affiliate.** “Affiliate” means an entity that directly or indirectly Controls, is Controlled by, or is under common Control of that party. 68 | 69 | **9.2. Approved Specification.** “Approved Specification” means the final version and contents of any Draft Specification designated as an Approved Specification as set forth in the accompanying Governance.md file. 70 | 71 | **9.3. Contribution.** “Contribution” means any original work of authorship, including any modifications or additions to an existing work, that Contributor submits for inclusion in a Draft Specification, which is included in a Draft Specification or Approved Specification. 72 | 73 | **9.4. Contributor.** “Contributor” means any person or entity that has indicated its acceptance of the License 1) by making a Contribution to the Specification, or 2) by entering into the Community Specification Contributor License Agreement for the Specification. Contributor includes its Affiliates, assigns, agents, and successors in interest. 74 | 75 | **9.5. Control.** “Control” means direct or indirect control of more than 50% of the voting power to elect directors of that corporation, or for any other entity, the power to direct management of such entity. 76 | 77 | **9.6. Draft Specification.** “Draft Specification” means all versions of the material (except an Approved Specification) developed by this Working Group for the purpose of creating, commenting on, revising, updating, modifying, or adding to any document that is to be considered for inclusion in the Approved Specification. 78 | 79 | **9.7. Exclusion Notice.** “Exclusion Notice” means a written notice made by making a pull request or commit to the repository’s Notices.md file that identifies patents that Contributor is excluding from its patent licensing commitments under this License. The Exclusion Notice for issued patents and published applications must include the Draft Specification’s name, patent number(s) or title and application number(s), as the case may be, for each of the issued patent(s) or pending patent application(s) that the Contributor is excluding from the royalty-free licensing commitment set forth in this License. If an issued patent or pending patent application that may contain Necessary Claims is not set forth in the Exclusion Notice, those Necessary Claims shall continue to be subject to the licensing commitments under this License. The Exclusion Notice for unpublished patent applications must provide either: (i) the text of the filed application; or (ii) identification of the specific part(s) of the Draft Specification whose implementation makes the excluded claim a Necessary Claim. If (ii) is chosen, the effect of the exclusion will be limited to the identified part(s) of the Draft Specification. 80 | 81 | **9.8. Implementation.** “Implementation” means making, using, selling, offering for sale, importing or distributing any implementation of the Specification 1) only to the extent it implements the Specification and 2) so long as all required portions of the Specification are implemented. 82 | 83 | **9.9. License.** “License” means this Community Specification License. 84 | 85 | **9.10. Licensee.** “Licensee” means any person or entity that has indicated its acceptance of the License as set forth in Section 2.1.3. Licensee includes its Affiliates, assigns, agents, and successors in interest. 86 | 87 | **9.11. Necessary Claims.** “Necessary Claims” are those patent claims, if any, that a party owns or controls, including those claims later acquired, that are necessary to implement the required portions (including the required elements of optional portions) of the Specification that are described in detail and not merely referenced in the Specification. 88 | 89 | **9.12. Specification.** “Specification” means a Draft Specification or Approved Specification included in the Working Group’s repository subject to this License, and the version of the Specification implemented by the Licensee. 90 | 91 | **9.13. Scope.** “Scope” has the meaning as set forth in the accompanying Scope.md file included in this Specification’s repository. Changes to Scope do not apply retroactively. If no Scope is provided, each Contributor’s Necessary Claims are limited to that Contributor’s Contributions. 92 | 93 | **9.14. Working Group.** “Working Group” means this project to develop specifications, standards, best practices, guidelines, and other similar materials under this License. 94 | 95 | 96 | 97 | *The text of this Community Specification License is Copyright 2020 Joint Development Foundation and is licensed under the Creative Commons Attribution 4.0 International License available at https://creativecommons.org/licenses/by/4.0/.* 98 | 99 | SPDX-License-Identifier: CC-BY-4.0 100 | -------------------------------------------------------------------------------- /Specification.md: -------------------------------------------------------------------------------- 1 | 10 | 11 | 12 | ## Supply Chain Integrity Model 13 | 14 | ### Version 1.0 PRE-DRAFT 15 | 16 | 17 | 18 | © The SCIM Maintainers 19 | 20 | This specification is subject to the Community Specification License 1.0, available at [https://github.com/CommunitySpecification/1.0](https://github.com/CommunitySpecification/1.0). 21 | 22 |   23 | ## Contents 24 | 25 | [Foreword](#Foreword) 26 | 27 | [Introduction](#Introduction) 28 | 29 | [1 Scope](#1%20%20%20Scope) 30 | 31 | [2 Normative references](#2%20%20%20Normative%20references) 32 | 33 | [3 Terms and definitions](#3%20%20%20Terms%20and%20definitions) 34 | 35 | [4 Workflows](#4%20%20%20Workflows) 36 | 37 | [4.1 Reference Use Cases](#4.1%20%20%20Reference%20Use%20Cases) 38 | 39 | [5 Standards](#5%20%20%20Standards) 40 | 41 | 44 | 45 | 46 | ## Foreword 47 | 48 | Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. No party shall not be held responsible for identifying any or all such patent rights. 49 | 50 | Any trade name used in this document is information given for the convenience of users and does not constitute an endorsement. 51 | 52 | This document was prepared by the SCIM maintainers. 53 | 54 | 57 | 58 | Known patent licensing exclusions are available in the specification’s repository’s Notices.md file. 59 | 60 | Any feedback or questions on this document should be directed to specifications repository, located at [https://github.com/microsoft/scim](https://github.com/microsoft/scim). 61 | 62 | THESE MATERIALS ARE PROVIDED “AS IS.” The Contributors and Licensees expressly disclaim any warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to the materials. The entire risk as to implementing or otherwise using the materials is assumed by the implementer and user. IN NO EVENT WILL THE CONTRIBUTORS OR LICENSEES BE LIABLE TO ANY OTHER PARTY FOR LOST PROFITS OR ANY FORM OF INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER FROM ANY CAUSES OF ACTION OF ANY KIND WITH RESPECT TO THIS DELIVERABLE OR ITS GOVERNING AGREEMENT, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDING NEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT THE OTHER MEMBER HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 63 | 64 | ## Introduction 65 | In the exchange of artifacts across a supply chain, it is often the case that receiving entities require evidence in order to verify the suitability of an artifact for an intended use. Such verification requires evaluating evidence against requirements. Requirements are typically defined by policy manager entities. 66 | 67 | Because evidence about artifacts can change over time, for example defects may be identified, artifacts may reach end-of-life status, and suppliers may go out of business, receiving entities must continuously verify evidence and respond to changes. 68 | 69 | At each step in the supply chain, careless or malicious parties may perform actions that diminish artifact integrity. To uphold integrity, policy manager entities must be able to enforce that all entities, artifacts, evidence and policy in the supply chain are authentic. Additionally they must be able to enforce that all actions are authorized, transparent, immutable and auditable. 70 | 71 | This specification describes a model for the exchange of evidence and policy to support the ongoing verification of artifacts where the authenticity of entities, evidence, policy and artifacts can be assured and the actions of entities can be guaranteed to be authorized, transparent, immutable and auditable. 72 | 73 | 74 | ## Supply Chain Integrity Model - Workflows and Standards 75 | ### 1   Scope 76 | 77 | The Supply Chain Integrity Model (SCIM) specifies an end-to-end system for validating arbitrary artifacts in terms of supply chains whose integrity has been proven. 78 | 79 | SCIM is applicable to both hardware (objects in the physical world) and software (digital) artifacts. 80 | 81 | SCIM defines minimum standards around the preparation, storage, distribution, consumption, validation and evaluation of arbitrary evidence about artifacts that are critical to maintaining the integrity of supply chains. 82 | 83 | SCIM does not define how artifacts are produced or distributed, nor the methods by which evidence about artifacts is produced prior to preparation for inclusion in SCIM. 84 | 85 | ### 2   Normative references 86 | 87 | 98 | There are no normative references in this document. 99 | 100 | ### 3   Terms and definitions 101 | 102 | For the purposes of this document, the following terms and definitions apply. 103 | 104 | ISO and IEC maintain terminological databases for use in standardization at the following addresses: 105 | 106 | — ISO Online browsing platform: available at https://www.iso.org/obp 107 | 108 | — IEC Electropedia: available at http://www.electropedia.org/ 109 | 110 | #### 3.1 111 | 112 | **Artifact** 113 | 114 | An item exchanged in a supply chain. Examples of Artifacts include hardware components, software components, IoT devices, cloud service endpoints, consumer products and data. 115 | 116 | #### 3.2 117 | 118 | **Evidence** 119 | 120 | Believable information about an Artifact. At a minimum, Evidence includes supplier and artifact identity. Evidence may also include the results of evaluations such as security scans, regulatory audits, quality test suites, and notices of product defects, vulnerabilities, and end of support. 121 | 122 | #### 3.3 123 | 124 | **Policy** 125 | 126 | A set of rules that informs how a User Agent uses Evidence to verify the suitability of an Artifact for an intended use. 127 | 128 | #### 3.4 129 | 130 | **Supplier** 131 | 132 | An entity that provides an Artifact. 133 | 134 | #### 3.5 135 | 136 | **Attester** 137 | 138 | An entity that provides Evidence about an Artifact. 139 | 140 | #### 3.6 141 | 142 | **Policy Manager** 143 | 144 | An entity that provides Policy for verifying Artifacts using Evidence. 145 | 146 | #### 3.7 147 | 148 | **User Agent** 149 | 150 | An entity that uses Evidence to verify Artifacts against Policy. 151 | 152 | #### 3.8 153 | 154 | **Store** 155 | 156 | A data store that enables the storage, query, subscription and retrieval of certified Evidence and Policy by authorized Users. 157 | 158 | ### 4   Workflows 159 | 160 | The Supply Chain Integrity Model (SCIM) describes a set of specifications enabling one or more entities ("Attesters") to produce believable information ("Evidence") about an item in the supply chain ("Artifact"). Attesters submit Evidence to a web service ("Store") where it is certified and made available to receiving entities ("User Agents"). The Evidence enables other entities ("User Agents") to verify whether the Artifact conforms to management policies ("Policy"). 161 | 162 | The diagram depicts the flow of artifacts between entities in the Supply Chain Integrity Workflow. 163 | 164 |

165 |
166 | Figure 4.1 -- Supply Chain Integrity Model Workflow 167 |

168 | 169 | A Supplier creates an Artifact (a) and an Attester creates Evidence (b) about an Artifact. The Supplier and the Attester may be the same entity. The Attester submits Evidence to a Store where it is certified and made available for query and retrieval. 170 | 171 | A Policy Manager creates Policy (c) and submits it to a Store where it is certified and made available for query and retrieval. 172 | 173 | A User Agent (d) receives an Artifact, and retrieves Evidence and Policy. The User Agent uses Evidence to verify the Artifact against Policy. 174 | 175 | #### 4.1   Reference Use Cases 176 | 177 | This section covers a number of representative use cases for supply chain integrity, independent of specific solutions. The purpose is to provide motivation for various aspects of the architecture presented in this document. Many other use cases exist, and this document does not intend to have a complete list, only to have a set of use cases that collectively cover all the functionality required in the architecture. 178 | 179 | Each use case includes a description followed by a summary of the Attester and Relying Party roles. 180 | 181 | #### 4.1.1   Self-Attestation 182 | 183 | In the most basic use case for supply chain integrity, a Supplier serves a dual role as Supplier and Attester, providing Evidence about an Artifact. At a minimum, Evidence includes globally unique identifiers for both Supplier and Artifact. Evidence may include additional information such as the following: 184 | 185 | - information allowing the Artifact to be verified (e.g. a cryptographic hash for software) 186 | - information about subcomponents of the Artifact 187 | - information about how the Artifact was created 188 | - information about restrictions on the legal use of the Artifact 189 | - information about security and quality evaluations performed on the Artifact 190 | - information about defects identified in the Artifact 191 | - references to related Artifacts or Evidence 192 | 193 | A Supplier creates an Artifact (a) and Evidence (b). A Policy Manager provides Policy (c). A User Agent (d) obtains Artifact (a) and Evidence (b), and uses Policy (c) to verify suitability of Artifact (a) for the intended use. 194 | 195 |

196 |
197 | Figure 4.1.1.1 -- Self-Attestation Workflow 198 |

199 | 200 | #### 4.1.2   Private/Public Attestation 201 | 202 | In this use case, a Supplier creates an Artifact (a), private Evidence (b), and private Policy (c). A Build Verifier (d) uses these to verify Artifact (A) prior to release. At release, the Supplier provides a summarized version of Evidence (e) for public users. 203 | 204 |

205 |
206 | Figure 4.1.2.1 -- Private/Public Attestation Workflow 207 |

208 | 209 | On the User side, a Policy Manager creates Policy (f), and a User Agent (g) obtains Artifact (a) and uses Policy (f) to verify suitability of Artifact (a) for the intended use. 210 | 211 | #### 4.1.3   Multi-Party Attestation 212 | 213 | To increase trust in Artifacts, Policy Managers may require independent Evidence from multiple third-party Attesters. For example in a software supply chain, a Policy Manager may require that all code commits be approved by two qualified reviewers, or that software be independently rebuilt by multiple parties with matching build Artifacts. 214 | 215 | In the Multi-Party Attestation workflow, the User Agent obtains an Artifact from the Supplier and Evidence (a) and (b) from Attesters.The User Agent verifies the Artifact against Policy, which specifies allowed Attesters, the number of Attesters required, and any additional requirements. 216 | 217 |

218 |
219 | Figure 4.1.3.1 -- Multi-Party Attestation Workflow 220 |

221 | 222 | #### 4.1.4   Subcomponent Verification 223 | 224 | Often a Policy Manager requires that a final component (Artifact) and all sub-components (Artifacts) conform to Policy, for example that a component and all subcomponents are free from critical defects. 225 | 226 | In this workflow, Subcomponent Suppliers provide Artifacts (a) and (b) and Evidence (a) and (b) to the Component Supplier, who in turn provides Artifact (c) and Evidence (c) to the User Agent. Evidence (c) includes Evidence (a) and (b) either inline, or by reference. The User Agent verifies Artifact (c) against Policy, which specifies requirements for the component and all nested subcomponents. 227 | 228 |

229 |
230 | Figure 4.1.4.1 -- Subcomponent Verification Workflow 231 |

232 | 233 | #### 4.1.5   Continuous Verification 234 | 235 | Policy Managers often require corrective action when changes occur in Artifact status, such as when critical security issues are reported, when legal licences are modified, and when Artifacts become obsolete. Additionally, Policy Managers may require corrective action when changes occur in Policy, for example to respond to updated business or regulatory requirements. Thus, User Agents must continuously monitor and respond to changes in both Evidence and Policy. In some cases, such as the case of critical security issues, the response must be rapid. 236 | 237 | In this workflow, the User Agent obtains Evidence (a) and Policy (a) and uses these to verify an Artifact. 238 | 239 | Later, when a critical security issue is reported against the Artifact by a Defect Reporting Service, the User Agent receives Evidence (b) and re-verifies the artifact, rapidly performing corrective action. 240 | 241 | Later still, business conditions require the Policy Manager to modify policy. At this time, the User Agent receives Policy (b) and re-verifies the Artifact, performing corrective action as needed. 242 | 243 | Eventually, when the Supplier determines to discontinue support for the Artifact, it provides new evidence, Evidence (c) indicating the Artifact’s pending obsolescence. The user receives the new evidence, re-verifies the Artifact, and performs corrective action as needed. 244 | 245 |

246 |
247 | Figure 4.1.5.1 -- Continuous Verification Workflow 248 |

249 | 250 | #### 4.1.6   Runtime Integrity Verification 251 | 252 | Policy Managers often require verification that Artifacts are not tampered with after deployment to production environments.. 253 | 254 | The diagram below depicts a workflow in which software is received from a Supplier, verified and installed by an Installer, and monitored for runtime tampering by a Runtime Monitor. 255 | 256 | Initially, the Installer obtains the Artifact and Evidence and uses the evidence, in this case a cryptographic hash of the Artifact, to verify Artifact integrity prior to installation. Post installation, the Installer submits new Evidence, including a cryptographic hash for each installed file, to a local Store. 257 | 258 | Thereafter, a Runtime Monitor such as a background process or application loader continuously verifies installed files against the Evidence (cryptographic hashes) in the local Store. 259 | 260 |

261 |
262 | Figure 4.1.6.1 -- Runtime Integrity Verification Workflow 263 |

264 | 265 | ### 5   Standards 266 | 267 | The diagram below shows standards that comprise the Supply Chain Integrity Model. 268 | 269 |

270 |
271 | Figure 5.1 -- Standards within the Supply Chain Integrity Model 272 |

273 | 274 | **SCIM-Evidence**. The SCIM-Evidence standard defines a data model and exchange format for providing evidence about artifacts. Add requirements for SCIM-Evidence standard. 275 | 276 | **SCIM-Policy**. The SCIM-Policy standard defines a data model and exchange format for providing policy for use in evaluating artifacts for a specified.use. 277 | 278 | **SCIM-Store**. The SCIM-Store standard provides a definition for a service that allows publishing and subscribing to Evidence and Policy. The SCIM-Store provides backing storage for both Evidence and Policy. The SCIM-Store service definition provides a uniform application programming model that allows: 279 | - Distributed identity management. 280 | - Verification and certification of published evidence and policy. 281 | - Transparent, immutable, non-repudiable logging of transactions. 282 | - Rich, graph-aware query of evidence and policy. 283 | - Notifications of new transactions in the data store (to support continuous verification) 284 | 285 | 308 | -------------------------------------------------------------------------------- /images/spec/Workflow - Self-Attestation.svg: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /images/spec/Standards.svg: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /images/workflow.svg: -------------------------------------------------------------------------------- 1 | --------------------------------------------------------------------------------