|
| 1 | +# CloudEvents Security Self-assessment |
| 2 | + |
| 3 | +## Table of contents |
| 4 | + |
| 5 | +* [Metadata](#metadata) |
| 6 | + * [Security links](#security-links) |
| 7 | +* [Overview](#overview) |
| 8 | + * [Actors](#actors) |
| 9 | + * [Actions](#actions) |
| 10 | + * [Background](#background) |
| 11 | + * [Goals](#goals) |
| 12 | + * [Non-goals](#non-goals) |
| 13 | +* [Self-assessment use](#self-assessment-use) |
| 14 | +* [Security functions and features](#security-functions-and-features) |
| 15 | +* [Project compliance](#project-compliance) |
| 16 | +* [Secure development practices](#secure-development-practices) |
| 17 | +* [Security issue resolution](#security-issue-resolution) |
| 18 | +* [Appendix](#appendix) |
| 19 | + |
| 20 | +## Metadata |
| 21 | + |
| 22 | +A table at the top for quick reference information, later used for indexing. |
| 23 | + |
| 24 | +| | | |
| 25 | +| -- | -- | |
| 26 | +| Software | Specification: https://github.com/cloudevents/spec | |
| 27 | +| Security Provider | No. The primary function of the project is NOT to support the security of an integrating system | |
| 28 | +| Languages | n/a | |
| 29 | +| SBOM | n/a | |
| 30 | +| | | |
| 31 | + |
| 32 | +### Security links |
| 33 | + |
| 34 | +Provide the list of links to existing security documentation for the project. |
| 35 | +You may use the table below as an example: |
| 36 | +| Information | URL | |
| 37 | +| -- | -- | |
| 38 | +| Raising security issues information | https://github.com/cloudevents/spec#security-concerns | |
| 39 | + |
| 40 | +## Overview |
| 41 | + |
| 42 | +CloudEvents is a specification for describing common event data in popular |
| 43 | +formats and transports to provide interoperability across services, platforms |
| 44 | +and systems. |
| 45 | + |
| 46 | +While there are SDKs for CloudEvents, they are community driven activities |
| 47 | +and while they are hosted within the CloudEvents github org, the focus of |
| 48 | +the security review should be on the specification itself. It is worth |
| 49 | +mentioning though that the SDKs (and the CloudEvents specification) do not |
| 50 | +introduce (or deal with) any security mechanisms beyond what is available |
| 51 | +as part of whatever transport is used to move an event between actors. |
| 52 | + |
| 53 | +### Background |
| 54 | + |
| 55 | +For more detailed information, please see either the |
| 56 | +[Graduation Proposal](https://github.com/cncf/toc/blob/845ec88ca3908824d6fead0c2840947f8941a355/proposals/graduation/cloudevents.md) |
| 57 | +or the |
| 58 | + [Primer](https://github.com/cloudevents/spec/blob/main/cloudevents/primer.md). |
| 59 | + |
| 60 | + |
| 61 | +### Actors |
| 62 | + |
| 63 | +CloudEvents has 2 main actors: |
| 64 | +1 - an event producer |
| 65 | +2 - an event consumer |
| 66 | + |
| 67 | +There may be additional variants of these, for example, an event intermediary |
| 68 | +that receives events and then forwards them on to another event receiver, or |
| 69 | +an actor the receives and event and generates one or more events. However, |
| 70 | +these could be considered variants of the 2 main actors. |
| 71 | + |
| 72 | +The CloudEvents specification only deals with serialziation of |
| 73 | +Events and their metadata, not the transport (or transport protection) |
| 74 | +mechanisms used to move events between the actors. For that, the specification |
| 75 | +and the users of the transports will rely on the transport-specific |
| 76 | +specifications and implementations. Basically, transport security concerns are |
| 77 | +out of scope for CloudEvents. |
| 78 | + |
| 79 | +### Actions |
| 80 | + |
| 81 | +CloudEvents is just a specification |
| 82 | + |
| 83 | +These are the steps that a project performs in order to provide some service |
| 84 | +or functionality. These steps are performed by different actors in the system. |
| 85 | +Note, that an action need not be overly descriptive at the function call level. |
| 86 | +It is sufficient to focus on the security checks performed, use of sensitive |
| 87 | +data, and interactions between actors to perform an action. |
| 88 | + |
| 89 | +For example, the access server receives the client request, checks the format, |
| 90 | +validates that the request corresponds to a file the client is authorized to |
| 91 | +access, and then returns a token to the client. The client then transmits that |
| 92 | +token to the file server, which, after confirming its validity, returns the file. |
| 93 | + |
| 94 | +### Goals |
| 95 | +The intended goals of the projects including the security guarantees the project |
| 96 | + is meant to provide (e.g., Flibble only allows parties with an authorization |
| 97 | +key to change data it stores). |
| 98 | + |
| 99 | +### Non-goals |
| 100 | +Non-goals that a reasonable reader of the project’s literature could believe may |
| 101 | +be in scope (e.g., Flibble does not intend to stop a party with a key from storing |
| 102 | +an arbitrarily large amount of data, possibly incurring financial cost or overwhelming |
| 103 | + the servers) |
| 104 | + |
| 105 | +## Self-assessment use |
| 106 | + |
| 107 | +This self-assessment is created by the [project] team to perform an internal analysis of the |
| 108 | +project's security. It is not intended to provide a security audit of [project], or |
| 109 | +function as an independent assessment or attestation of [project]'s security health. |
| 110 | + |
| 111 | +This document serves to provide [project] users with an initial understanding of |
| 112 | +[project]'s security, where to find existing security documentation, [project] plans for |
| 113 | +security, and general overview of [project] security practices, both for development of |
| 114 | +[project] as well as security of [project]. |
| 115 | + |
| 116 | +This document provides the CNCF TAG-Security with an initial understanding of [project] |
| 117 | +to assist in a joint-assessment, necessary for projects under incubation. Taken |
| 118 | +together, this document and the joint-assessment serve as a cornerstone for if and when |
| 119 | +[project] seeks graduation and is preparing for a security audit. |
| 120 | + |
| 121 | +## Security functions and features |
| 122 | + |
| 123 | +* Critical. A listing critical security components of the project with a brief |
| 124 | +description of their importance. It is recommended these be used for threat modeling. |
| 125 | +These are considered critical design elements that make the product itself secure and |
| 126 | +are not configurable. Projects are encouraged to track these as primary impact items |
| 127 | +for changes to the project. |
| 128 | +* Security Relevant. A listing of security relevant components of the project with |
| 129 | + brief description. These are considered important to enhance the overall security of |
| 130 | +the project, such as deployment configurations, settings, etc. These should also be |
| 131 | +included in threat modeling. |
| 132 | + |
| 133 | +## Project compliance |
| 134 | + |
| 135 | +* Compliance. List any security standards or sub-sections the project is |
| 136 | + already documented as meeting (PCI-DSS, COBIT, ISO, GDPR, etc.). |
| 137 | + |
| 138 | +## Secure development practices |
| 139 | + |
| 140 | +* Development Pipeline. A description of the testing and assessment processes that |
| 141 | + the software undergoes as it is developed and built. Be sure to include specific |
| 142 | +information such as if contributors are required to sign commits, if any container |
| 143 | +images immutable and signed, how many reviewers before merging, any automated checks for |
| 144 | +vulnerabilities, etc. |
| 145 | +* Communication Channels. Reference where you document how to reach your team or |
| 146 | + describe in corresponding section. |
| 147 | + * Internal. How do team members communicate with each other? |
| 148 | + * Inbound. How do users or prospective users communicate with the team? |
| 149 | + * Outbound. How do you communicate with your users? (e.g. flibble-announce@ |
| 150 | + mailing list) |
| 151 | +* Ecosystem. How does your software fit into the cloud native ecosystem? (e.g. |
| 152 | + Flibber is integrated with both Flocker and Noodles which covers |
| 153 | +virtualization for 80% of cloud users. So, our small number of "users" actually |
| 154 | +represents very wide usage across the ecosystem since every virtual instance uses |
| 155 | +Flibber encryption by default.) |
| 156 | + |
| 157 | +## Security issue resolution |
| 158 | + |
| 159 | +* Responsible Disclosures Process. A outline of the project's responsible |
| 160 | + disclosures process should suspected security issues, incidents, or |
| 161 | +vulnerabilities be discovered both external and internal to the project. The |
| 162 | +outline should discuss communication methods/strategies. |
| 163 | + * Vulnerability Response Process. Who is responsible for responding to a |
| 164 | + report. What is the reporting process? How would you respond? |
| 165 | +* Incident Response. A description of the defined procedures for triage, |
| 166 | + confirmation, notification of vulnerability or security incident, and |
| 167 | +patching/update availability. |
| 168 | + |
| 169 | +## Appendix |
| 170 | + |
| 171 | +* Known Issues Over Time. List or summarize statistics of past vulnerabilities |
| 172 | + with links. If none have been reported, provide data, if any, about your track |
| 173 | +record in catching issues in code review or automated testing. |
| 174 | +* [CII Best Practices](https://www.coreinfrastructure.org/programs/best-practices-program/). |
| 175 | + Best Practices. A brief discussion of where the project is at |
| 176 | + with respect to CII best practices and what it would need to |
| 177 | + achieve the badge. |
| 178 | +* Case Studies. Provide context for reviewers by detailing 2-3 scenarios of |
| 179 | + real-world use cases. |
| 180 | +* Related Projects / Vendors. Reflect on times prospective users have asked |
| 181 | + about the differences between your project and projectX. Reviewers will have |
| 182 | +the same question. |
| 183 | + |
0 commit comments