diff --git a/CBOM/en/0x01-Frontispiece.md b/CBOM/en/0x01-Frontispiece.md
new file mode 100644
index 0000000..c8ba512
--- /dev/null
+++ b/CBOM/en/0x01-Frontispiece.md
@@ -0,0 +1,35 @@
+
+\newpage
+
+# Frontispiece
+
+## About the Guide
+CycloneDX is a modern standard for the software supply chain.
+
+The content in this guide results from continuous community feedback and input from leading experts in the software
+supply chain security field. This guide would not be possible without valuable feedback from the CycloneDX Industry
+Working Group (IWG), the CycloneDX Core Working Group (CWG), the many CycloneDX Feature Working Groups (FWG),
+CycloneDX maintainers and a global network of contributors and supporters.
+
+## Copyright and License
+
+
+
+Copyright © 2024 The OWASP Foundation.
+
+This document is released under the [Creative Commons Attribution 4.0 International](https://creativecommons.org/licenses/by/4.0/).
+For any reuse or distribution, you must make clear to others the license terms of this work.
+
+Version 1.0.0, xx February 2024
+
+
+\emptyparagraph
+
+
+| Version | Changes | Updated On | Updated By |
+|---------|-----------------|------------|------------------------------|
+| 0.0.0 | Initial Release | 2024-xx-xx | CycloneDX Core Working Group |
+
+
+\newpage
+
diff --git a/CBOM/en/0x02-Preface.md b/CBOM/en/0x02-Preface.md
new file mode 100644
index 0000000..cbab2a9
--- /dev/null
+++ b/CBOM/en/0x02-Preface.md
@@ -0,0 +1,20 @@
+# Preface
+
+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.
+
+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.
+
+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.
+
+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.
+
+I commend the CycloneDX team for a highly polished revision of their standard, one that evolves the state of the art.
+
+---
+
+Andrew van der Stock
+Executive Director, OWASP Foundation
+
+
+\newpage
+
diff --git a/CBOM/en/0x10-Introduction.md b/CBOM/en/0x10-Introduction.md
new file mode 100644
index 0000000..a60b98f
--- /dev/null
+++ b/CBOM/en/0x10-Introduction.md
@@ -0,0 +1,67 @@
+# Introduction
+
+CBOM:
+NIST:
+SP: https://www.nccoe.nist.gov/sites/default/files/2023-12/pqc-migration-nist-sp-1800-38b-preliminary-draft.pdf
+Lines 536 and 952 onwards
+as part of NCCOE effort
+Apache 2.0 - attribute IBM
+
+
+
+
+
+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.
+
+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.
+
+## Intended Audience
+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
+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.
+
+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.
+
+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.
+
+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.
+
+## How CycloneDX Attestations Addresses Challenge
+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.
+
+We believe:
+
+* The use of machine-readable standards in Attestations format will encourage faster and deeper understanding by all parties.
+* The Attestations claims and evidence approach will allow development organizations to articulate their compliance rationale quickly and clearly
+* The use of Attestations will enable all forms of assessors, certifiers, and accreditors to more quickly evaluate compliance and provide feedback to producers
+* Attestations will enable faster compliance feedback loops and less surprises and delays
+
+## Intended Use Cases
+// TODO
+// * Supplier to consumer use case where the consumer requires adherence to something (e.g. SSDF)
+// * Internal use case where an internal policy is created from requirements defined in CDXA
+// * Regulatory and industry compliance requirements
+
+## Tool Support
+
+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.
+
+## Join Us
+
+If you are interested in using CycloneDX Attestations or want to help us realize our vision, please join us!
+
+https://www.youtube.com/@CycloneDX
+https://owasp.org/www-project-cyclonedx/
+https://cyclonedx.org/about/participate/
+
+
+\newpage
+
+
diff --git a/CBOM/en/0x20-Use-Cases.md b/CBOM/en/0x20-Use-Cases.md
new file mode 100644
index 0000000..2bba474
--- /dev/null
+++ b/CBOM/en/0x20-Use-Cases.md
@@ -0,0 +1,8 @@
+# Use Cases
+
+TODO
+
+
+
+\newpage
+
\ No newline at end of file
diff --git a/CBOM/en/0x30-Practicle-Examples.md b/CBOM/en/0x30-Practicle-Examples.md
new file mode 100644
index 0000000..4048fde
--- /dev/null
+++ b/CBOM/en/0x30-Practicle-Examples.md
@@ -0,0 +1,22 @@
+# Making Attestations
+TODO
+
+## 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."
+
+// TODO Small snippet for Claims
+
+
+\newpage
+
\ No newline at end of file
diff --git a/CBOM/en/0x40-Anatomy-of-a-CBOM.md b/CBOM/en/0x40-Anatomy-of-a-CBOM.md
new file mode 100644
index 0000000..511e75d
--- /dev/null
+++ b/CBOM/en/0x40-Anatomy-of-a-CBOM.md
@@ -0,0 +1,7 @@
+# Anatomy of a CBOM
+
+TODO
+
+
+\newpage
+
diff --git a/CBOM/en/0x50-Linking.md b/CBOM/en/0x50-Linking.md
new file mode 100644
index 0000000..985977e
--- /dev/null
+++ b/CBOM/en/0x50-Linking.md
@@ -0,0 +1,6 @@
+# Linking
+TODO
+
+
+\newpage
+
\ No newline at end of file
diff --git a/CBOM/en/0x60-Attestations.md b/CBOM/en/0x60-Attestations.md
new file mode 100644
index 0000000..199b7f2
--- /dev/null
+++ b/CBOM/en/0x60-Attestations.md
@@ -0,0 +1,3 @@
+# Attestations
+
+TODO