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/0x02-Preface.md
+21-9
Original file line number
Diff line number
Diff line change
@@ -1,14 +1,26 @@
1
1
# Preface
2
2
3
-
Secure supply chains are the foundational building block of modern cyber security. Without being able to describe a system’s components in a machine-consumable way, organizations and software consumers are in the dark if they are at risk of exploitation of known defects or vulnerabilities.
4
-
5
-
Innovation drives the evolution of Software Bill of Materials (SBOM). I was lucky enough to attend one of the meetings held between the CycloneDX and SPDX teams at a Linux Foundation conference moderated by the fine folks at CISA. The drivers for CycloneDX 1.5 include improvements in interoperability and transparency.
6
-
7
-
Software authors, from hobbyists to software vendors, can quickly adopt CycloneDX in their tooling, producing artifacts that will help consumers understand and manage the risk of the multitude of software that most organizations rely on daily.
8
-
9
-
A few years ago, I was involved in a project to review 1700 business-critical applications in 90 days for known software vulnerabilities. If the organization had access to CycloneDX SBOMs, this would have been a trivial task, time that could have been more usefully spent on remediation rather than discovery. Sadly, most of the time was spent working out what software had old faulty components rather than addressing the very real risk of known software vulnerabilities. We were plagued with false positives from the tooling we used simply because scanning software without SBOMs is a heuristic-driven discovery process that is inefficient and wastes a great deal of time we didn’t have. SBOMs resolve these issues, reduce costs, and reduce risk to all involved.
10
-
11
-
I commend the CycloneDX team for a highly polished revision of their standard, one that evolves the state of the art.
3
+
Welcome to the Authoritative Guide series by the OWASP Foundation and OWASP CycloneDX. In this series, we aim to
4
+
provide comprehensive insights and practical guidance, ensuring that security professionals, developers, and
5
+
organizations alike have access to the latest best practices and methodologies.
6
+
7
+
At the heart of the OWASP Foundation lies a commitment to inclusivity and openness. We firmly believe that everyone
8
+
deserves a seat at the table when it comes to shaping the future of cybersecurity standards. Our collaborative
9
+
model fosters an environment where diverse perspectives converge to drive innovation and excellence.
10
+
11
+
In line with this ethos, the OWASP Foundation has partnered with Ecma International to create an inclusive,
12
+
community-driven ecosystem for security standards development. This collaboration empowers individuals to contribute
13
+
their expertise and insights, ensuring that standards like CycloneDX reflect the collective wisdom of the global
14
+
cybersecurity community.
15
+
16
+
One standout example of this partnership is OWASP CycloneDX, which is on track to becoming an Ecma International
17
+
standard through Technical Committee 54 (TC54). By leveraging the strengths of both organizations, CycloneDX is poised
18
+
to become a cornerstone of security best practices, providing organizations with a universal standard for software and
19
+
system transparency.
20
+
21
+
As you embark on your journey through this Authoritative Guide, we encourage you to engage actively with the content
22
+
and join us in shaping the future of cybersecurity standards. Together, we can build a safer and more resilient digital
Copy file name to clipboardexpand all lines: Attestations/en/0x10-Introduction.md
+13-22
Original file line number
Diff line number
Diff line change
@@ -1,35 +1,35 @@
1
1
# Introduction
2
-
CycloneDX Attestations is a modern standard for security compliance. CycloneDX Attestations enable organizations with a machine-readable format for communication about security standards, claims and evidence 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.
2
+
CycloneDX Attestations is a modern standard for security compliance. It enables organizations to use a machine-readable format for communication about security standards, claims, and evidence about security requirements, as well as 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.
3
3
4
-
CycloneDX Attestations is a part of the OWASP CycloneDX project. CycloneDX is an OWASP flagship project, has a formal standardization process and governance model, and is supported by the global information security community.
4
+
CycloneDX Attestations is part of OWASP CycloneDX. CycloneDX is an OWASP flagship project with a formal standardization process and governance model and is supported by the global information security community.
5
5
6
6
## Intended Audience
7
7
CycloneDX Attestations is intended for use by:
8
-
* Software development teams that want to meet security requirements and automate security evidence generation and communication
9
-
* Security teams that want to ensure the security and compliance of software projects being created, and manage the compliance process with assessors.
8
+
* Software development teams that want to meet security requirements and automate security evidence generation and communication.
9
+
* Security teams that want to ensure the security and compliance of software projects being created and manage the compliance process with assessors.
10
10
* Executives who are required to attest to their compliance with security standards.
11
11
* Security assessors that want to have a standard way of processing compliance documentation and tracking compliance.
12
12
* Security tool providers that build software for managing compliance processes.
13
13
* Security standard creators that want to create a machine-readable version of their requirements.
14
14
15
15
## Problem Statement
16
-
Currently, organizations use a variety of paper-based 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, labor-intensive, and often overwhelming. Not surprisingly, the results are generally 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 intent of the original requirement.
16
+
Currently, organizations use a variety of paper-based and non-standard electronic documents to communicate security requirements, evidence, and attestations. The labor required to create, process, manage, update, and track these documents is expensive, labor-intensive, and often overwhelming. 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 intent of the original requirement.
17
17
18
-
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. Unfortunately, in most cases, at least some of the requirements make no sense to apply to the product, and many critical aspects of security are not reflected in the requirements.
18
+
The problem is widespread, and many [articles](https://www.google.com/search?q=compliance+is+not+security)explain why compliance is not the same as security. If the security requirements represented the shared security interests of all stakeholders, then security and compliance would be aligned. Unfortunately, in most cases, at least some of the requirements make no sense to apply to a product, and many critical aspects of security are not reflected in the requirements.
19
19
20
-
The root cause of these issues is a fundamental communications problem. Security requirements don't often match up well with the expected threats for a particular real-world system and its defenses. Further, security requirements are often far too abstract for development organizations to clearly understand what they must do with their particular organization, processes, and technologies. The assessors that should be facilitating the interpretation of the requirements in the context of the actual system are often relegated to strict interpretation of the words in vague, high-level requirements.
20
+
The root cause of these issues is a fundamental communications problem. Security requirements don't often match up well with the expected threats for a particular real-world system and its defenses. Further, security requirements are often too abstract for development organizations to clearly understand what they must do with their particular organization, processes, and technologies. The assessors who should be facilitating the interpretation of the requirements in the context of the actual system are often relegated to a strict interpretation of the words in vague, high-level requirements.
21
21
22
-
Our challenge is to encourage standards bodies, builders, and assessors to communicate effectively. All the parties need a way to ensure that the *intent* of each requirement is applied appropriately to a particular product or system and achieved with confidence.
22
+
Our challenge is encouraging standards bodies, builders, and assessors to communicate effectively. All the parties need a way to ensure that the *intent* of each requirement is applied appropriately to a particular product or system and achieved with confidence.
23
23
24
24
## How CycloneDX Attestations Addresses Challenge
25
-
Of course, 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.
25
+
While CycloneDX Attestations may not completely eradicate this issue, they offer a solution that significantly reduces the paperwork burden. CycloneDX Attestations fosters a more efficient and streamlined interaction process by facilitating communication in a standard, machine-readable format.
26
26
27
27
We believe:
28
28
29
29
* The use of machine-readable standards in Attestations format will encourage faster and deeper understanding by all parties.
30
-
* The Attestations claims and evidence approach will allow development organizations to articulate their compliance rationale quickly and clearly
31
-
* The use of Attestations will enable all forms of assessors, certifiers, and accreditors to more quickly evaluate compliance and provide feedback to producers
32
-
* Attestations will enable faster compliance feedback loops and less surprises and delays
30
+
* The Attestations claims and evidence approach will allow development organizations to articulate their compliance rationale quickly and clearly.
31
+
* The use of Attestations will enable all forms of assessors, certifiers, and accreditors to quickly evaluate compliance and provide feedback to producers.
32
+
* Attestations will enable faster compliance feedback loops and fewer surprises and delays.
33
33
34
34
## Intended Use Cases
35
35
// TODO
@@ -38,16 +38,7 @@ We believe:
38
38
// * Regulatory and industry compliance requirements
39
39
40
40
## Tool Support
41
-
42
-
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.
43
-
44
-
## Join Us
45
-
46
-
If you are interested in using CycloneDX Attestations or want to help us realize our vision, please join us!
47
-
48
-
https://www.youtube.com/@CycloneDX
49
-
https://owasp.org/www-project-cyclonedx/
50
-
https://cyclonedx.org/about/participate/
41
+
Over time, we expect tools to emerge to manage all aspects of security attestation. 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's point of view, imagine being able to quickly evaluate claims and evidence, easily identify changes, point out gaps, and digitally sign approvals.
Copy file name to clipboardexpand all lines: Attestations/en/0x20-Standards.md
+3-5
Original file line number
Diff line number
Diff line change
@@ -1,19 +1,17 @@
1
1
# Standards
2
-
In CDXA, a "standard" is just a collection of security requirements. Each "standard" has a version number, description, an owner, and a list of requirements. The requirements themselves may be very specific and concrete, best practices, guidance, or even just priniciples. That's up to the standard creator. Many security standards are available in CDXA. You can see a list below.
2
+
In CDXA, a "standard" is just a collection of security requirements. Each "standard" has a version number, description, an owner, and a list of requirements. The requirements themselves may be very specific and concrete, with best practices, guidance, or even just principles. That's up to the standard creator. Many security standards are available in CDXA. You can see a list below.
3
3
4
4
In CDXA every requirement has:
5
5
* Identifier - should tie back to the original standard as much as possible
6
6
* Title - a short description
7
7
* Text - the actual text of the requirement
8
-
* Descriptions - an array of supplental text that provides guidance but is not directly part of the text
8
+
* Descriptions - an array of supplemental text that provides guidance but is not directly part of the text
9
9
* OpenCRE Identifier (where possible)
10
10
* Parent (to support a hierarchy of requirements)
11
11
* External References
12
12
13
13
## Creating Your Own Standard
14
-
Every system is a beautiful and unique snowflake. It has it's own resources, connections, algorithms, data stores, and security mechanisms. An organization built it and an organization operates it. In short, it has a threat model all its own. That means that it probably has a unique set of security defenses, assurance techniques, and stakeholders.
15
-
16
-
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. 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.
17
15
18
16
# TODO - add links for CDXA versions of PCI SSS and OWASP SAMM
Copy file name to clipboardexpand all lines: Attestations/en/0x30-Making-Attestations.md
+18-2
Original file line number
Diff line number
Diff line change
@@ -2,7 +2,6 @@
2
2
TODO
3
3
4
4
## Claims
5
-
6
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.
7
6
8
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.
@@ -15,7 +14,24 @@ A `Claim` is simply a statement that captures at least one aspect of how a certa
15
14
16
15
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."
17
16
18
-
// TODO Small snippet for Claims
17
+
```json
18
+
"claims": [
19
+
{
20
+
"bom-ref": "claim-1",
21
+
"target": "acme-inc",
22
+
"predicate": "Developers have taken the HackMe Secure Coding for Java training course and received a passing grade on the final test.",
0 commit comments