From 85888ebceac5604f8eb42452a1aa267ef5bc768e Mon Sep 17 00:00:00 2001 From: Jeff Williams Date: Tue, 24 Oct 2023 20:44:31 -0400 Subject: [PATCH 1/3] First draft Signed-off-by: Jeff Williams --- Attestations/en/0x10-Introduction.md | 32 +++++++++++++++++++++------- 1 file changed, 24 insertions(+), 8 deletions(-) diff --git a/Attestations/en/0x10-Introduction.md b/Attestations/en/0x10-Introduction.md index 25a92c3..be8d5f4 100644 --- a/Attestations/en/0x10-Introduction.md +++ b/Attestations/en/0x10-Introduction.md @@ -1,19 +1,35 @@ # Introduction +CycloneDX Attestations is a modern standard for security compliance. CycloneDX Attestations enables organizations with a machine-readable format for communication about security standards, claims about security requirements, and attestations to the veracity and completeness of those claims. You can think of Attestations as a way to manage "compliance as code." The Attestations project began in 2023 as part of the broader CycloneDX project. + CycloneDX is a modern standard for the software supply chain. At its core, CycloneDX is a general-purpose Bill of -Materials (BOM) standard capable of representing software, hardware, services, and other types of inventory. The CycloneDX -standard began in 2017 in the Open Worldwide Application Security Project (OWASP) community. CycloneDX is an OWASP -flagship project, has a formal standardization process and governance model, and is supported by the global information -security community. +Materials (BOM) standard capable of representing software, hardware, services, and other types of inventory. The CycloneDX standard began in 2017 in the Open Worldwide Application Security Project (OWASP) community. CycloneDX is an OWASP flagship project, has a formal standardization process and governance model, and is supported by the global information security community. ## Intended Audience -TODO +CycloneDX Attestations is intended for use by: +* Software development teams that want to meet security requirements and automate security evidence generation and communication +* Security teams that want to ensure the security and compliance of software projects being created, and manage the compliance process with assessors. +* Executives who are required to attest to their compliance with security standards. +* Security assessors that want to have a standard way of processing compliance documentation and tracking compliance. +* Security tool providers that build software for managing compliance processes. +* Security standard creators that want to create a machine-readable version of their requirements. ## Problem Statement -TODO +Currently, organizations use a variety of paper and non-standard electronic documents to communicate about security requirements, evidence, and attestation. The labor required to create, process, manage, update, and track these documents is expensive and overwhelming. And, unfortunately, the results are underwhelming. There are often large gaps between what the original requirement envisioned and the argument presented by the software producer. Similarly, assessors often misinterpret requirements and focus on minutae instead of the broader security posture. + +The problem is so bad there are endless [articles](https://www.google.com/search?q=compliance+is+not+security) explaining why compliance is not the same as security. This is unfortunate. If the security requirements really represented the shared security interests of all stakeholders, then security and compliance would be aligned. + +At the core, this problem is a communications problem. There is often a disconnect between a set of security requirements and the expected threats for a particular system and its corresponding defenses. Further, security requirements are never specific enough for development organizations to clearly understand what they must do with their particular system and technologies. At the same time, assessors often have difficulty understanding complex technologies to ensure that requirements are met. + +Our challenge is to encourage builders and assessors to communicate effectively about how to ensure that the *intent* of each requirement is applied appropriately to a particular product or system and achieved with confidence. -## How CycloneDX Addresses Challenge -TODO +## How CycloneDX Attestations Addresses Challenge +CycloneDX Attestations can't solve this problem entirely. However, by allowing all parties to communicate in a standard machine-readable format, we hope to encourage more productive interaction and far less paperwork. We believe that machine-readable standards will encourage faster and deeper understanding by all parties. We also believe that the claims and evidence approach will allow development organizations to articulate their compliance rationale quickly and clearly. And we are optimistic that Attestations will enable all forms of assessors, certifiers, and accreditors to more quickly evaluate compliance and provide feedback to producers. + +Over time, we expect better tools for managing all aspects of security attestation to emerge. As a producer, imagine being able to select appropriate standards for a project, eliminate duplication, articulate compliance rationales, automatically generate and include supporting evidence, manage reviews, and digitally sign attestations. From the assessor point of view, imagine being able to quickly evaluate claims and evidence, easily identify changes, point out gaps, and digitally sign approvals. + +If you are interested in using CycloneDX Attestations or want to help us realize our vision, please join us!
\newpage
+ From 131a662e9caee723118d01d886e90c7f68e1b2cb Mon Sep 17 00:00:00 2001 From: "DASARPJONAM\\dasarpjonam" Date: Tue, 31 Oct 2023 09:11:58 -0700 Subject: [PATCH 2/3] first draft of claims and evidence --- ...x40-Substantiating-Claims-With-Evidence.md | 41 ++++++++++++++++++- 1 file changed, 39 insertions(+), 2 deletions(-) diff --git a/Attestations/en/0x40-Substantiating-Claims-With-Evidence.md b/Attestations/en/0x40-Substantiating-Claims-With-Evidence.md index cbc52c4..e1e4e04 100644 --- a/Attestations/en/0x40-Substantiating-Claims-With-Evidence.md +++ b/Attestations/en/0x40-Substantiating-Claims-With-Evidence.md @@ -1,8 +1,45 @@ # Substantiating Claims With Evidence -TODO + +## Claims +`Claims` in the CycloneDX Attestation specification refer to statements about the attestation, such as the identity of the component, the identity of the entity that created the attestation, and the date and time of the attestation. Claims can also be made about the specific aspects of the component that are being attested to, such as its provenance, integrity, and security. + +Claims are important because they provide context for the attestation and help consumers to understand what the attestation is saying. For example, a consumer can use the claims to determine whether or not the attestation is relevant to their needs, and whether or not they can trust the entity that created the attestation. Consumers of CycloneDX Attestations can use the claims to assess the trustworthiness of the attestation and to determine whether or not the attestation meets their needs. + +Some examples of claims that can be made in a CycloneDX Attestation: + +* `Component:` The identity of the software component that is being attested to, such as its name, version, and hash value. +* `Attestor:` The identity of the entity that created the attestation, such as its name and public key. +* `Date:` The date and time of the attestation. +* `Scopes:` A list of scopes that the attestation covers, such as provenance, integrity, and security. +* `Provenance:` A statement about the provenance of the software component, such as the identity of the software supply chain participants that contributed to its development. +* `Integrity:` A statement about the integrity of the software component, such as the fact that it has been signed with a digital certificate or that it has been scanned for vulnerabilities. +* `Security:` A statement about the security of the software component, such as the fact that it has been developed using secure coding practices or that it has been tested for security vulnerabilities. ## Evidence -TODO +`Evidence` in the CycloneDX Attestation specification refers to the data that supports the `claims` made in an attestation. For example, a claim that a software component has been built from source code that is available in a public repository can be supported by evidence such as a link to the repository or a hash of the source code. + +Without `evidence`, `claims` are meaningless. A software component could claim to be attested to using the SLSA framework, but without evidence to support this claim, there is no way to verify that the claim is true. + +The evidence in an attestation can include a variety of data, such as: + +* `Test results:` These can provide evidence that a component has passed certain tests, validating claims about its functionality or performance. +* `Code reviews:` These can provide evidence that a component has been reviewed and meets certain quality standards. +* `Security scans:` These can provide evidence that a component does not contain known security vulnerabilities. + +## Substantiating Claims with Evidence +Consumers of CycloneDX Attestations should carefully evaluate the evidence to ensure that it is sufficient to support the claims that are being made. + +Claim: The software component has been attested to using the SLSA framework. + +Evidence: + + A cryptographic signature of the software component, generated using a digital certificate issued by a trusted certificate authority. + A code review report that was generated by a qualified code reviewer. + A build log that shows that the software component was built using a secure build system. + +The evidence in this example provides support for the claim that the software component has been attested to using the SLSA framework. The cryptographic signature provides evidence that the attestation was created by a trusted entity. The code review report provides evidence that the source code of the software component has been reviewed by a qualified person. The build log provides evidence that the software component was built using a secure build system. + +
\newpage From 2a2a97e44b91a317d8fee9927d917ac210cfb38c Mon Sep 17 00:00:00 2001 From: Manoj Prasad Date: Tue, 31 Oct 2023 13:10:23 -0700 Subject: [PATCH 3/3] requirements are now referenced in claims --- Attestations/en/0x40-Substantiating-Claims-With-Evidence.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Attestations/en/0x40-Substantiating-Claims-With-Evidence.md b/Attestations/en/0x40-Substantiating-Claims-With-Evidence.md index e1e4e04..5410db0 100644 --- a/Attestations/en/0x40-Substantiating-Claims-With-Evidence.md +++ b/Attestations/en/0x40-Substantiating-Claims-With-Evidence.md @@ -3,7 +3,7 @@ ## Claims `Claims` in the CycloneDX Attestation specification refer to statements about the attestation, such as the identity of the component, the identity of the entity that created the attestation, and the date and time of the attestation. Claims can also be made about the specific aspects of the component that are being attested to, such as its provenance, integrity, and security. -Claims are important because they provide context for the attestation and help consumers to understand what the attestation is saying. For example, a consumer can use the claims to determine whether or not the attestation is relevant to their needs, and whether or not they can trust the entity that created the attestation. Consumers of CycloneDX Attestations can use the claims to assess the trustworthiness of the attestation and to determine whether or not the attestation meets their needs. +Claims are important because they provide context for the attestation and help consumers to understand what the attestation is saying. For example, a consumer can use the claims to determine whether or not the attestation is relevant to their needs, and whether or not they can trust the entity that created the attestation. The needs of a consumer are encoded in the form of `requirements` in CycloneDX Attestation. The claims are made against the requirements i.e. claims in an attestation references the requirements they satisfy. The consumer of the attestation can use the referenced requirements in the claim to verify if a claim satifies their needs. Some examples of claims that can be made in a CycloneDX Attestation: @@ -43,4 +43,4 @@ The evidence in this example provides support for the claim that the software co
\newpage -
\ No newline at end of file +