Merge pull request #9 from dasarpjonam/main

[Ready for Review] - claims and evidence

Attestations/en/0x40-Substantiating-Claims-With-Evidence.md

@@ -1,9 +1,46 @@
 # 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. 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:
+
+* `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.
+
+<!-- TODO: Example JSON for Claims and Evidence -->
 
 <div style="page-break-after: always; visibility: hidden">
 \newpage
-</div>
+</div>