Commit as of todays meeting

Signed-off-by: steve.springett <[email protected]>

Attestations/en/0x20-Standards.md

@@ -28,6 +28,12 @@ TODO
 ## OWASP Software Assurance Maturity Model (SAMM) 
 TODO
 
+
+
+TODO / Add table that lists standards and the CDX version of those standards
+
+TODO / Include example standard snippet
+
 <div style="page-break-after: always; visibility: hidden">
 \newpage
 </div>

Attestations/en/0x30-Making-Attestations.md

@@ -2,7 +2,20 @@
 TODO
 
 ## Claims
-TODO
+
+Claims are the way organizations can articulate their argument for meeting a particular requirement. You can break the requirement down into a set of claims that tackle some part of the overall requirement. There are many ways to structure your claims, but generally the simplest and most straightforward arguments are best.
+
+For example, you may want to create a claim about each major module in a complex system. Or you might make claims about several separate aspects of a security defense. In some cases, a single claim is enough to cover the entire requirement.
+
+A `Claim` is simply a statement that captures at least one aspect of how a certain requirement has been satisfied. A claim has two key parts, a target and a predicate. Claims often restate the requirement using specific terms related to the defenses in the system.
+
+* `Target:` Each claim has a `target` that is the subject of the claim. The target might be the specific name of entire system, a module, a process, a team, a business unit, or an entire company. In many cases, the target is simply an interpretation of the requirement for the current attestation. For example, the specifi might be "Acme Corporation" or "The Mxyzptlk Module."
+
+* `Predicate:` Each claim also has a `predicate` that states what is being claimed about the target. Once again, this is often a specific interpretation of the requirement that details exactly what was done to meet the requirement.  For example,
+
+For example, consider the requirement, "All developers must receive security training." An appropriate claim might be that "All members of the Acme development team have taken the HackMe Secure Coding for Java training course and received a passing grade on the final test." The target is "All members of the Acme development team" and the predicate is "have taken the HackMe Secure Coding for Java training course and received a passing grade on the final test."
+
+// TODO Small snippet for Claims
 
 <div style="page-break-after: always; visibility: hidden">
 \newpage

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

@@ -2,24 +2,10 @@
 
 CycloneDX Attestations is a standard that enables organizations to build an argument explaining how they meet security requirements. Organizations can start this process very early in development, using attestations to plan their security strategy for meeting each requirement and capturing the general reasoning that will be used.
 
-As the system is built and tested, the team can capture the details of their implmentation with specific claims. Ultimately, they can complete the argument by generating and gathering evidence to support each claim and creating specific reasoning that explains how the evidence demonstrates the claims are well supported and that the overall requirement has been met.
+As the system is built and tested, the team can capture the details of their implementation with specific claims. Ultimately, they can complete the argument by generating and gathering evidence to support each claim and creating specific reasoning that explains how the evidence demonstrates the claims are well supported and that the overall requirement has been met.
 
 Let's explore the claims, evidence and reasoning that attest to how a requirement has been satisfied. Remember, a single requirement may be supported by multiple claims and a claim may be supported by many different pieces of evidence, tied together by some reasoning.
 
-## Claims
-
-Claims are the way organizations can articulate their argument for meeting a particular requirement. You can break the requirement down into a set of claims that tackle some part of the overall requirement. There are many ways to structure your claims, but generally the simplest and most straightforward arguments are best.
-
-For example, you may want to create a claim about each major module in a complex system. Or you might make claims about several separate aspects of a security defense. In some cases, a single claim is enough to cover the entire requirement.
-
-A `Claim` is simply a statement that captures at least one aspect of how a certain requirement has been satisfied. A claim has two key parts, a target and a predicate. Claims often restate the requirement using specific terms related to the defenses in the system.
-
-* `Target:` Each claim has a `target` that is the subject of the claim. The target might be the specific name of entire system, a module, a process, a team, a business unit, or an entire company. In many cases, the target is simply an interpretation of the requirement for the current attestation. For example, the specifi might be "Acme Corporation" or "The Mxyzptlk Module."
-
-* `Predicate:` Each claim also has a `predicate` that states what is being claimed about the target. Once again, this is often a specific interpretation of the requirement that details exactly what was done to meet the requirement.  For example, 
-
-For example, consider the requirement, "All developers must receive security training." An appropriate claim might be that "All members of the Acme development team have taken the HackMe Secure Coding for Java training course and received a passing grade on the final test." The target is "All members of the Acme development team" and the predicate is "have taken the HackMe Secure Coding for Java training course and received a passing grade on the final test."
-
 ## Evidence
 
 Once we have a specific claim, we can consider the types of evidence that might support that claim. The best evidence directly supports the target and predicate in the claim.  Indirect evidence is valuable, but generally can't stand alone and will need more explanation in the reasoning section below. For example, it's better to know that the software was extensively tested for SQL Injection than it would be to know that SQL Injection is covered in the organization's secure coding guide.  
@@ -30,6 +16,8 @@ Once we have a specific claim, we can consider the types of evidence that might
 
 * `Mitigation Strategy:` If the evidence is not compelling or counter evidence is present, the producer can detail their plans for improving conformance in this section. Ideally, the strategy should detail the change or enhancement, the rough schedule, and the expected effect on the evidence supporting the claim.
 
+// TODO Small snippet for Evidence
+
 ## Reasoning
 
 Simply providing claims and evidence is not sufficient to determine whether the claim was satisfied. We need some reasoning that explains how all the evidence, counter evidence, and mitigation strategy work together to support the claim. The best reasoning is simple and direct, and ties back to the claim as a straighforward argument.
@@ -38,12 +26,16 @@ Simply providing claims and evidence is not sufficient to determine whether the
 
 Your reasoning for a claim about not being susceptible to SQL injection might tie together several pieces of evidence (and address any counter evidence). For example, a strong argument would be that "Acme corporation policy, secure coding guidelines, and training progam ensure that developers are aware of SQL injection and how to prevent it. All database access is performed through Hibernate which uses parameterized SQL queries in most cases. We test our software for all types of SQL injection using IAST and have remediated all instances discovered. Finally, we use RASP in production to detect SQL injection attacks and prevent exploitation."
 
+// TODO Small snippet for Reasoning
+
 ## Other
 
 * `External References:` A claim can reference any systems, sites, and information that may be relevant, but are not included with the BOM. They may also establish specific relationships within or external to the BOM.
 
 * `Signature:` Enveloped signature in [JSON Signature Format (JSF)](https://cyberphone.github.io/doc/security/jsf.html).
 
+// TODO Small snippet that ties everything together
+
 ## Another Example
 
 Claim: The software component complies with the SLSA framework.