trustification · carlosthe19916 · Jul 12, 2023 · Jul 13, 2023 · Jul 13, 2023 · Jul 13, 2023
diff --git a/docs/concepts/_category_.json b/docs/concepts/_category_.json
@@ -0,0 +1,9 @@
+{
+  "label": "Concepts",
+  "position": 2,
+  "link": {
+    "type": "generated-index",
+    "description": "5 minutes to learn the most important concepts."
+  },
+  "collapsible": false
+}
diff --git a/docs/concepts/sbom.md b/docs/concepts/sbom.md
@@ -0,0 +1,39 @@
+---
+sidebar_position: 1
+---
+
+# SBOM (Software Bill of Materials)
+
+A software bill of materials (SBOM) is an inventory of all constituent components and software dependencies involved in the development and delivery of an application.
+
+An SBOM is similar to a bill of materials (BOM) used in supply chains and manufacturing. In the IT industry, however, it hasn't been a common feature for all vendors to accurately detail the foundational code components on which an application is built.
+
+## Why is SBOM Important to Security?
+
+SBOM enables organizations to identify and track all third-party components, in particular open source components, and comply with licensing requirements. It also helps ensure that the organization does not run vulnerable open source components and keeps track of critical updates and patches. It helps organizations utilize open source components as needed while maintaining security and compliance.
+
+## SBOM Standards: CycloneDX and SPDX
+
+Most projects that create or process SBOMs use one of two standards:
+
+### CycloneDX
+
+Is sponsored by the Open Web Application Security Project (OWASP). The CycloneDX SBOM has associated metadata and describes a set of software elements broken down into components, services, and dependencies. The SBOM also has constructs that define relationships between elements.
+
+### Software Package Data Exchange (SPDX)
+
+Is a project maintained by the Linux Foundation. The SPDX SBOM model defines three elements: Documents (metadata about the SBOM), Packages (groups of elements), and Files (single files).
+
+## What’s in an SBOM?
+
+The US National Telecommunications and Information Administration (NTIA) released a standard that defines the minimum requirements for an SBOM. According to the NTIA standard, an SBOM must include:
+
+- **Author Name**: usually the organization that develops the software.
+- **Vendor Name**: the name of the software vendor, including aliases (alternative names). Vendor and author may be different if a supplier is creating an SBOM on behalf of the vendor.
+- **Component Name**: the name and possible aliases of the software component.
+- **Version String**: the format of the version information is free-form, but should follow common industry usage.
+- **Component Hash**: the best way to identify a software component is to use a cryptographic hash that serves as a unique identifier.
+- **Unique Identifier**: in addition to the hash, each component must have an ID number that identifies it within the SBOM.
+- **Relationship**: defines the relationship between the component and the package. In most cases, the relationship is “included”, meaning that a certain component is included in a certain package.
+
+In addition to these minimum requirements, an SBOM can include additional information such as security scores, common vulnerabilities and exposure codes (CVEs) of known vulnerabilities in software components, and their severity.
diff --git a/docs/concepts/vex.md b/docs/concepts/vex.md
@@ -0,0 +1,19 @@
+---
+sidebar_position: 2
+---
+
+# VEX (Vulnerability Exploitability Exchange)
+
+VEX is a form of a security advisory, similar to those already issued by mature product security
+teams toda
+
+The goal of Vulnerability Exploitability eXchange (VEX) is to allow a software supplier or other
+parties to assert the status of specific vulnerabilities in a particular product
+
+## What can you expect from a VEX?
+
+- **Vulnerability details**: Provides additional information on a specific vulnerability, such that it can serve as a comprehensive list of associated vulnerabilities to a specific vulnerable component.
+- **Vulnerability context**: As a companion document to the SBOM, it also provides additional vulnerability context to discovered components (as part of the SBOM) in software products and whether they are exploitable in that particular environment. In essence, the VEX is a diagnostic tool that pinpoints what vulnerabilities really matter.
+- **Remediation guidance**: In case these components are exploitable, available remediation options are recommended.
+- **Automation support**: Supports automation for effective vulnerability management, tracking, and remediation.
+- **Focus on what matters most**: Enables organizations to focus on vulnerabilities that are exploitable and save time by not fixing vulnerabilities that pose no risk to the organization.
diff --git a/docs/intro.md b/docs/intro.md
@@ -2,46 +2,25 @@
 sidebar_position: 1
 ---
 
-# Tutorial Intro
+# What is software supply chain security
 
-Let's discover **Docusaurus in less than 5 minutes**.
+Software supply chain security combines best practices from risk management and cybersecurity to help protect the software supply chain from potential vulnerabilities. The software supply chain is made up of everything and everyone that touches your code in the software development lifecycle (SDLC), from application development to the CI/CD pipeline and deployment.
 
-## Getting Started
+The supply chain includes networks of information about the software, like the components (e.g. infrastructure, hardware, operating systems (OS), cloud services, etc.), the people who wrote them, and the sources they come from, like registries, GitHub repositories, codebases, or other open source projects. It also includes any vulnerabilities that may negatively impact software security – and that’s where software supply chain security comes in.
 
-Get started by **creating a new site**.
+## Why is software supply chain security critical?
 
-Or **try Docusaurus immediately** with **[docusaurus.new](https://docusaurus.new)**.
+Most software today isn’t written from scratch – it’s typically a combination of software artifacts containing open source software. However, these software artifacts are subject to vulnerabilities, and developers have less control over source code from a third party or any changes made to a software artifact over time. It’s important to note that unpatched software is more susceptible to security issues. Because software is essential to executing daily business operations, supply chain security is a crucial responsibility of every organization and security team.
 
-### What you'll need
+Software company SolarWinds was breached in 2020 when attackers launched malicious code via its Orion IT monitoring and management software, a platform used among large corporations and government agencies. By attacking the supply chain, the hackers infiltrated not only SolarWinds but their customers as well. Log4j is a commonly used but widely exploitable open source software that has left countless users and organizations susceptible to data breaches and attacks. In 2021, the president of the United States highlighted the importance of software supply chains and security with 2 White House executive orders: supply chains and cybersecurity.
 
-- [Node.js](https://nodejs.org/en/download/) version 16.14 or above:
-  - When installing Node.js, you are recommended to check all checkboxes related to dependencies.
+## What are the security risks to the software supply chain?
 
-## Generate a new site
+Risk to any component of the software supply chain presents a potential risk to every software artifact relying on that supply chain component. It provides hackers the opportunity to insert malware, a backdoor, or other malicious code to compromise any components and their associated supply chains. Software supply chain attacks, commonly carried out by profit threat actors and nation state actors, are rising and can have dramatic effects in both our digital and physical worlds. These generally fall into one of four types of risks:
 
-Generate a new Docusaurus site using the **classic template**.
+- Vulnerabilities: are flaws in software code that could be exploited leading to a breach. Patch and update your software artifacts to minimize this risk
+- Licensing: is a legal risk that could obligate you to make any resulting software artifacts open source and nullify patent rights. Consult legal experts in this area.
+- Third party dependencies: are any dependency upon any outside organization as part of the software supply chain and are difficult to know. Analyze all third party code and talk to your suppliers about how they protect you.
+- Processes and policies: are a problem if you do not have them. Create policies for your developers and processes (or playbooks) for when you need to respond to a vulnerability.
 
-The classic template will automatically be added to your project after you run the command:
-
-```bash
-npm init docusaurus@latest my-website classic
-```
-
-You can type this command into Command Prompt, Powershell, Terminal, or any other integrated terminal of your code editor.
-
-The command also installs all necessary dependencies you need to run Docusaurus.
-
-## Start your site
-
-Run the development server:
-
-```bash
-cd my-website
-npm run start
-```
-
-The `cd` command changes the directory you're working with. In order to work with your newly created Docusaurus site, you'll need to navigate the terminal there.
-
-The `npm run start` command builds your website locally and serves it through a development server, ready for you to view at http://localhost:3000/.
-
-Open `docs/intro.md` (this page) and edit some lines: the site **reloads automatically** and displays your changes.
+Common attack vectors include hijacking updates, undermining code signing, and compromising open source code.
diff --git a/docs/tutorial-basics/_category_.json b/docs/tutorial-basics/_category_.json
diff --git a/docs/tutorial-basics/congratulations.md b/docs/tutorial-basics/congratulations.md
diff --git a/docs/tutorial-basics/create-a-blog-post.md b/docs/tutorial-basics/create-a-blog-post.md
diff --git a/docs/tutorial-basics/create-a-document.md b/docs/tutorial-basics/create-a-document.md
diff --git a/docs/tutorial-basics/create-a-page.md b/docs/tutorial-basics/create-a-page.md
diff --git a/docs/tutorial-basics/deploy-your-site.md b/docs/tutorial-basics/deploy-your-site.md
diff --git a/docs/tutorial-extras/_category_.json b/docs/tutorial-extras/_category_.json
diff --git a/docs/tutorial-extras/img/docsVersionDropdown.png b/docs/tutorial-extras/img/docsVersionDropdown.png
diff --git a/docs/tutorial-extras/img/localeDropdown.png b/docs/tutorial-extras/img/localeDropdown.png
diff --git a/docs/tutorial-extras/manage-docs-versions.md b/docs/tutorial-extras/manage-docs-versions.md