You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: Attestations/en/0x20-Standards.md
+4-5
Original file line number
Diff line number
Diff line change
@@ -11,20 +11,19 @@ In CDXA every requirement has:
11
11
* External References
12
12
13
13
## Creating Your Own Standard
14
-
In CDXA, you're free to create your own security standard. It could be a subset or superset of an existing standard. There are a lot of good reasons to tailor a security standard to your particular system. But remember, you may be required to follow one or more external security standards. As we move into making claims and substantiating those claims in CDXA, you'll see how you can capture your approach to existing requirements to show compliance.
14
+
In CDXA, you're free to create your own security standard. It could be a subset or superset of an existing standard.
15
+
There are a lot of good reasons to tailor a security standard to your particular system. But remember, you may be
16
+
required to follow one or more external security standards. As we move into making claims and substantiating those
17
+
claims in CDXA, you'll see how you can capture your approach to existing requirements to show compliance.
15
18
16
-
# TODO - add links for CDXA versions of PCI SSS and OWASP SAMM
17
19
| Original Standard | CDXA Version |
18
20
| --- | --- |
19
21
|[NIST Secure Software Development Framework (SSDF)](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-218.pdf)|[CDXA-SSDF](https://github.com/CycloneDX/official-3rd-party-standards/blob/main/standards/NIST/SSDF/nist_secure-software-development-framework_1.1.cdx.json)|
|[Build Security In Maturity Model (BSIMM)](https://www.synopsys.com/software-integrity/resources/analyst-reports/bsimm.html)|[CDXA-BSIMM](https://github.com/CycloneDX/official-3rd-party-standards/blob/main/standards/BSIMM/bsimm-v13.cdx.json)|
23
24
|[OWASP Application Security Verification Standard (ASVS)](https://github.com/OWASP/ASVS/raw/v4.0.3/4.0/OWASP%20Application%20Security%20Verification%20Standard%204.0.3-en.pdf)|[CDXA-OWASP-ASVS](https://github.com/CycloneDX/official-3rd-party-standards/blob/main/standards/OWASP/ASVS/asvs-4.0.3.cdx.json)|
24
25
|[OWASP Mobile Application Security Verification Standard (MASVS)](https://github.com/OWASP/owasp-masvs/releases/latest/download/OWASP_MASVS.pdf)|[CDXA-OWASP-MASVS](https://github.com/CycloneDX/official-3rd-party-standards/blob/main/standards/OWASP/MASVS/masvs-2.0.0.cdx.json)|
25
26
|[OWASP Software Component Verification Standard (SCVS)](https://scvs.owasp.org/scvs/)|[CDXA-OWASP-SCVS](scvs-1.0.0.cdx.json)|
26
-
|[OWASP Software Assurance Maturity Model (SAMM)](https://drive.google.com/file/d/1cI3Qzfrly_X89z7StLWI5p_Jfqs0-OZv/view?usp=sharing)|[CDXA-OWASP-SAMM](http://link.com)|
Copy file name to clipboardexpand all lines: Attestations/en/0x30-Making-Attestations.md
+40-8
Original file line number
Diff line number
Diff line change
@@ -1,18 +1,50 @@
1
1
# Making Attestations
2
-
TODO
2
+
CycloneDX Attestations (CDXA) represent a automated approach to enhancing security and compliance across various
3
+
standards. CycloneDX facilitates the representation of any standard—whether security-focused or otherwise—along with
4
+
the specific requirements associated with that standard. This capability ensures a broad applicability across different
5
+
domains and compliance needs.
6
+
7
+
Building upon this foundational support, CycloneDX further empowers organizations by enabling them to make formal
8
+
attestations against these defined standards and requirements. These attestations are comprised of claims that are
9
+
supported by concrete evidence, providing a robust mechanism for demonstrating compliance or security posture.
10
+
Importantly, CycloneDX acknowledges the complexity of real-world scenarios by also accommodating counter-claims and
11
+
counter-evidence, thus fostering a comprehensive and nuanced view of compliance and security assessments.
12
+
13
+
In instances where a requirement is not being fully met, CycloneDX's versatile framework allows for the specification of
14
+
mitigation strategies. This feature ensures that organizations can transparently communicate their efforts to address
15
+
potential shortcomings, thereby maintaining trust and integrity in the face of compliance challenges. Through these
16
+
capabilities, CycloneDX Attestations serve as a powerful tool for organizations striving to navigate the complex
17
+
compliance landscape with confidence and clarity.
3
18
4
19
## Claims
5
-
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.
20
+
Claims serve as the medium through which organizations can articulate their argument for meeting a specific requirement. You can dissect the requirement into a series of claims that address some part of the overall requirement. There are numerous ways to structure your claims, but it's important to remember that the simplest and most straightforward arguments often prove to be the most effective.
21
+
22
+
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. Sometimes, a single claim is enough to cover the entire requirement.
23
+
24
+
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.
6
25
7
-
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.
26
+
*`Target:` Each claim has a `target` that is the subject of the claim. The target might be the specific name of an entire system, a module, a process, a team, a business unit, or a company. In many cases, the target is simply an interpretation of the requirement for the current attestation. For example, the target might be "Acme Corporation" or "The Mxyzptlk Module."
8
27
9
-
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.
28
+
*`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,
10
29
11
-
*`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."
30
+
The following table details the makeup of a claim.
12
31
13
-
*`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,
| bom-ref | An identifier, unique to the CDXA document, that identifies the claim. |
35
+
| target | The bom-ref to a target representing a specific system, application, API, module, team, person, process, business unit, company, etc... that this claim is being applied to. |
36
+
| predicate | The specific statement or assertion about the target. |
37
+
| mitigationStrategies | The list of bom-ref to the evidence provided describing the mitigation strategies. Each mitigation strategy should include an explanation of how any weaknesses in the evidence will be mitigated. |
38
+
| reasoning | The written explanation of why the evidence provided substantiates the claim. |
39
+
| evidence | The list of bom-ref to evidence that supports this claim. |
40
+
| counterEvidence | The list of bom-ref to counterEvidence that supports this claim. |
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."
47
+
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."
16
48
17
49
```json
18
50
"claims": [
@@ -35,4 +67,4 @@ For example, consider the requirement, "All developers must receive security tra
Copy file name to clipboardexpand all lines: Attestations/en/0x40-Substantiating-Claims-With-Evidence.md
+45-3
Original file line number
Diff line number
Diff line change
@@ -16,7 +16,51 @@ Once we have a specific claim, we can consider the types of evidence that might
16
16
17
17
*`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.
18
18
19
-
// TODO Small snippet for Evidence
19
+
The following table details the makeup of evidence.
| bom-ref | An identifier, unique to the CDXA document, that identifies the evidence. |
24
+
| propertyName | The reference to the property name as defined in the CycloneDX Property Taxonomy. |
25
+
| description | The written description of what this evidence is and how it was created. |
26
+
| data | The output or analysis that supports claims. |
27
+
| created | The date and time (timestamp) when the evidence was created. |
28
+
| expires | The optional date and time (timestamp) when the evidence is no longer valid. |
29
+
| author | The author of the evidence. |
30
+
| reviewer | The reviewer of the evidence. |
31
+
32
+
33
+
```json
34
+
"evidence": [
35
+
{
36
+
"bom-ref": "evidence-1",
37
+
"propertyName": "internal.com.acme.someProperty",
38
+
"description": "Description here",
39
+
"data": [
40
+
{
41
+
"name": "Name of the data",
42
+
"contents": {
43
+
"attachment": {
44
+
"content": "Evidence here",
45
+
"contentType": "text/plain"
46
+
}
47
+
},
48
+
"classification": "PII",
49
+
"sensitiveData": [ "Describe sensitive data here" ]
50
+
}
51
+
],
52
+
"created": "2023-04-25T00:00:00+00:00",
53
+
"expires": "2023-05-25T00:00:00+00:00",
54
+
"author": { "name": "Mary" },
55
+
"reviewer": { "name": "Sanford" },
56
+
"signature": {
57
+
"algorithm": "ES256",
58
+
"certificatePath": [ "MIIB...", "MIID..." ],
59
+
"value": "tqIT..."
60
+
}
61
+
}
62
+
]
63
+
```
20
64
21
65
## Reasoning
22
66
@@ -26,15 +70,13 @@ Simply providing claims and evidence is not sufficient to determine whether the
26
70
27
71
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."
28
72
29
-
// TODO Small snippet for Reasoning
30
73
31
74
## Other
32
75
33
76
*`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.
34
77
35
78
*`Signature:` Enveloped signature in [JSON Signature Format (JSF)](https://cyberphone.github.io/doc/security/jsf.html).
36
79
37
-
// TODO Small snippet that ties everything together
0 commit comments