Signed-off-by: tracyragan <[email protected]>

content/en/_index.md

@@ -16,29 +16,29 @@ description: Welcome to the Ortelius Open Source Project Site
 
 {{< blocks/section color=primary >}}
 <div class="col-12">
-<h1 class="text-center">Centralized DevOps and Security Evidence for Rapid Software Supply Chain Security Response </h1>
+<h1 class="text-center">Centralized DevOps and Security Evidence for Rapid Software Supply Chain Attack Response </h1>
 <hr>
 </div>
 
-Today’s software security tools gather data for mostly low-level objects, like containers, causing critical security intelligence to be fragmented and stored across siloed logs and tools. Responding to a software supply chain security threat requires consolidated evidence that shows where a high-risk vulnerability's impact across the entire organization. Ortelius continuously monitors updates to your organization's software supply chain, tracking open-source inventory, and providing insights on impact and usage. In addition, the  Ortelius historical trend analysis is the basis for tomorrow's threat modeling with automated rapid response.
+Today’s software security tools gather data for mostly low-level objects, like containers, causing critical security intelligence to be fragmented and stored across siloed logs and tools. Responding to a software supply chain security threat requires consolidated evidence that shows a high-risk vulnerability's impact across the entire organization. Ortelius continuously monitors the updates to your organization's software supply chain, tracking open-source inventory, and providing insights on impact and usage. In addition, the  Ortelius historical trend analysis is the basis for tomorrow's threat modeling with automated rapid response.
 
 The mission of the Ortelius community is to defend the software supply chain by leveraging the open-source software security intelligence already generated across the DevOps pipeline, and to create AI threat models for rapid supply chain attack response. 
 
 Ortelius is an evidence store that federates supply chain and DevOps intelligence generated across the DevOps pipeline, providing an end-to-end view of an organization's security profile. Ortelius tracks and versions DevOps and security details for every component of your software supply chain. This data is then collected and aggregated to the 'logical' applications, organizational Domains, and deployed environments giving you a sweeping view of your organization's security insights. With Ortelius, you can easily answer the question, "where is Log4J running?"
 
-The latest version of Ortelius is maintained by the Ortelius Community managed by the [Continuous Delivery Foundation](http://cd.foundation/) (Linux Foundation). The Ortelius mission is to provide a comprehensive view of your organizations security profile using a world-class microservice catalog driven by a supportive and diverse global open source community.  Corporate support comes from DeployHub with 80% of the codebase from DeployHub's [Microservice Catalog](https://www.deployhub.com/).
+The latest version of Ortelius is maintained by the Ortelius Community managed by the [Continuous Delivery Foundation](http://cd.foundation/) (Linux Foundation). Corporate support comes from DeployHub with 80% of the codebase from DeployHub's [Software Supply Chain Security](https://www.deployhub.com/) Platform. 
 <p></p>
 {{< /blocks/section >}}
 
 {{< blocks/section color=white >}}
 <div class="col-12">
-<h1 class="text-center"> Continuous Versioning of Your Software Composition</h1>
+<h1 class="text-center"> A Central Evidence Store and Dashboard for DevOps and Security Data</h1>
 <hr>
 <p></p>
 </div>
-{{% blocks/feature icon="fas fa-3x fa-sitemap" title="Versioning" url="/versioning/" %}}
+{{% blocks/feature icon="fas fa-3x fa-sitemap" title="Continuous Software Supply Chain Versioning" url="/versioning/" %}}
 {{% /blocks/feature %}}
-{{% blocks/feature icon="fas fa-3x fa-share-square" title="Supply Chain Data" url="/catalog/" %}}
+{{% blocks/feature icon="fas fa-3x fa-share-square" title="Supply Chain Evidence" url="/catalog/" %}}
 {{% /blocks/feature %}}
 {{% blocks/feature icon="fas fa-3x fa-box-open" title="Logical Application Tracking" url="/microservicemapping/" %}}
 {{% /blocks/feature %}}

content/en/catalog/_index.md

@@ -1,13 +1,13 @@
 ---
 title: Supply Chain Data and DevOps Intelligence Dashboard
-description: Supply Chain Data in Ortelius
-summary: Supply Chain Data and DevOps Intelligence Dashboard
+description: Ortelius Aggregates Supply Chain Data Across the Pipeline
+summary: Use the Evidence You Already Collect
 type: contributor
 ---
 
 {{< blocks/section color=primary >}}
 <div class="col-12">
-<h1 class="text-center">Supply Chain Data and DevOps Intelligence for Hardening Cybersecurity</h1>
+<h1 class="text-center">Aggregated Security and DevOps Intelligence Across the Organization</h1>
 <hr>
 
 Ortelius is your go to place for DevOps and Security intelligence. The Ortelius evidence store and dashboard collects and displays as much data as possible from the DevOps Pipeline process. DevOps and Security data is fragmented across tools and left in the underlying build directory where the DevOps pipeline was executed. Most of the data is collected for one container at a time, making it difficult to see a complete software application's security profile, CVEs and SBOMs. By aggregating the data, Ortelius provides critical software supply chain intelligence needed for rapidly responding to cyber threats. Most important, Ortelius shows your open-source usage and details across the organization with ['logical applications'](/microservicemapping/ mapping. Some of the data collected by Ortelius includes:

content/en/microservicemapping/index.md

@@ -12,15 +12,15 @@ type: contributor
 
 ## Mapping Logical Applications
 
-Applications are a collection of components and microservices in a cloud-native architecture. Application mapping shows a 'logical' representation of the application's high-level components and microservices with their versions. Ortelius uses this information to show you how your 'logical' application has changed over time. As we work to harden cybersecurity, it is important to monitor your application's changes, even when you did not make the change.
+Applications are a collection of components in a decoupled, cloud-native architecture. Application mapping shows a 'logical' representation of the application's high-level components with their versions. Ortelius uses this information to show you how your 'logical' application has changed over time. As we work to harden cybersecurity, it is important to monitor your application's changes, even when you did not make the change.
 
-In a decoupled architecture, your applications will consume shared components. When these shared components are updated you have a new version of your application. Ortelius shows you the versions of all components and microservice that a specific version of your application is using.  While microservices move us away from traditional build and release approaches, we still need a method of tracking their changes and a way to make them unique. Like a software version control solution, Ortelius tracks specific information in the microservice mapping to track its changes and uniquely identify a version. Changes to a microservice impacts your microservice architecture<a href="https://www.deployhub.com/microservice-architecture/">.</a> This means that every logical application that consumes that service will have a potential impact. Microservice mapping tracks that for you.
+In a decoupled architecture, your applications will consume shared components. When these shared components are updated you have a new version of your application. Ortelius shows you the versions of all components, such as microservices, shared objects and AI agents, that a specific version of your application is using.  While microservices move us away from traditional build and release approaches, we still need a method of tracking their changes and a way to make them unique. Like a software version control solution, Ortelius tracks specific information in the component mapping to track its changes and uniquely identify a version. Changes to a component impacts your decoupled  architecture<a href="https://www.deployhub.com/application-security-devops-best-practices/">.</a> This means that every logical application that consumes that service will have a potential impact. 
 
-As microservices are consumed by applications, Ortelius tracks the dependencies. It can tell you at any point in time which version of the microservices your application is consuming, how many different versions have been deployed to your Kubernetes cluster, and who is using the same microservice. Ortelius builds a map that displays this data overtime.
+As components are consumed by applications, Ortelius tracks the dependencies. It can tell you at any point in time which version of the component your application is consuming and how many different versions have been deployed to your environments, referred to as version drift. Ortelius builds a map that displays this data overtime.
 
 ## Logical Application SBOMs and CVEs
 
-By tracking how your logical application changes, Ortelius can aggregate all lower level microservice data up to your logical application level. SBOMs and CVEs at the application level are aggregated based on the microservices your application consumes.
+By tracking how your logical application changes, Ortelius can aggregate all lower level component data up to your logical application level. SBOMs and CVEs at the application level are aggregated based on the components your application consumes.
 <br>
 <br>
 
@@ -34,11 +34,11 @@ By tracking how your logical application changes, Ortelius can aggregate all low
 
 ## Conclusion
 
-You should expect to be managing thousands of components and microservices in your cloud-native environment. A decoupled architecture will require a process of mapping shared component  usage across all applications, keeping teams informed of what versions of shared objects they are using. Ortelius provides a method for managing your application's inventory along with all configuration details. It integrates with your CI/CD process to continually update new versions of your shared services that in turn creates new versions of your applications. With our inventory system, you always know what version of a microservice your application version is dependent upon. You have the insights on the meta data to resolve issues, and expose the level of impact a new microservice version may create.
+You should expect to be managing thousands of components in your cloud-native environment. A decoupled architecture will require a process of tracking shared component  usage across all applications, keeping teams informed of what versions of shared objects they are using. Ortelius provides a method for managing your application's inventory along with all configuration details. It integrates with your CI/CD process to continually update new versions of your shared services that in turn creates new versions of your applications. With our inventory system, you always know what version of a component or open-source package your application version is dependent upon. You have the insights to resolve issues, Ortelius uses the data and makes it actionable. 
 
 ## Mapping in Action
 
-Ortelius tracks microservice versions to their 'logical' application versions.
+Ortelius tracks component versions to their 'logical' application versions.
 <br>
 <br>
 <video autoplay="autoplay" loop="loop" controls="controls" width="60%" height="60%"><source src="/images/mapview.mp4" type="video/mp4" />

content/en/versioning/index.md

@@ -1,32 +1,37 @@
 ---
-title: Component and Microservice Versioning
-description: Ortelius versioning features.
-summary: Component and Microservice Versioning
+title: Track Open-Source and Shared Component Changes
+description: Continuous Software Supply Chain Versioning
+summary: Track Open-Source and Shared Component Changes
 type: contributor
 ---
 
+
 {{< blocks/section color=primary >}}
 <div class="col-12">
-<h1 class="text-center">Component and Microservice Versioning</h1>
+<h1 class="text-center">Continuously Monitor the Updates to Your Software Supply Chain</h1>
 <hr>
 
+## Change Happens
+
+Software systems undergo daily changes and enhancements driven by the constant need for business agility. High-frequency software updates allow developers to submit modifications, updates, and new features, on a daily to hourly basis, ensuring that the software evolves rapidly in response to business demands. As a result, users benefit from not only the latest features but also ongoing bug fixes. However, with an increase in the frequency of software updates, the risk of introducing a new open-source software vulnerability increases. For this reason, the ability to view the changes to an organization's complete software supply chain is important. Change is where historical data is derived and trends can be analyzed. 
+
 ## Know What Changed
 
-As we move into a decoupled, cloud-native architecture we must take additional steps to track the hundreds of changes moving across our pipeline. When you fully embrace microservices you quickly start asking questions about who is consuming a service, what version is running in what cluster, who owns it and where can you find the associated software bill of material and CVE.
+As we move into a decoupled, cloud-native architecture we must take additional steps to track the hundreds of changes moving across our pipeline. When you fully embrace a decoupled architecture you quickly start asking questions about who is consuming a component, what version is running in what cluster, who owns it and where can you find the associated software bill of material and CVE.
 
-In our monolithic days, it was important to version source code so we understood what version of the code was compiled/linked into our builds. We now must track this at the run-time level. A deployment of a new shared container is our new 'compile/link' step. For this reason, microservice versioning is critical. Tracking hundreds of changes occurring at the same time requires continuous data gathering for each change, captured and tagged as a version. A new version of a lower level component impacts all 'logical' applications who consume it. This means a new application version is created each time a dependency is updated. A single 'logical application' that you deliver to an end user could have many new versions over the course of a few days. Each new version has a new software bill of material and CVE for example. In cloud-native, nothing stays the same for long.
+In our monolithic days, it was important to version source code so we understood what version of the code was compiled/linked into our builds. We now must track this at the run-time level. A deployment of a new shared container is our new 'compile/link' step. For this reason, software supply chain versioning is critical. Tracking hundreds of changes requires continuous data gathering for every change, with tagged versions. A new version of a lower level component impacts all 'logical' applications who consume it. This means a new application version is created each time a dependency is updated. A single 'logical application' that you deliver to an end user could have many new versions over the course of a few days. Each new version has a new software bill of material and CVE for example. In high frequency agile environments, nothing stays the same for long. 
 
 #### Impact on Logical Applications
 
-Logical applications are a collection of components (containers, DB Objects, files). 'Logical applications' are impacted and changed when its dependencies are updated. In our monolithic world, we would use the build number to version the release candidate. In a decoupled architecture, component and microservice versioning tracks the new releases. As microservices become more of the norm, developers will begin to share and reuse microservices across company silos. This sharing will create more microservice dependencies between teams. While this adds to the complexity of a microservice architecture, it also creates a more stable environment by reducing redundant code.
+Logical applications are a collection of components (containers, DB Objects, files). 'Logical applications' are impacted and changed when its dependencies are updated. In our monolithic world, we would use the build number to version the release candidate. In a decoupled architecture, software supply chain versioning tracks the new releases. As decoupled architecture become the norm, developers will begin to share and reuse objects across organizational silos. This sharing will create more software dependencies between teams. A decoupled architecture creates a more stable environment by reducing redundant code and objects. However, the security and DevOps intelligence becomes fragmented as it is collected for one object at a time. Logical application SBOMs and CVEs are lost. 
 
-The use of versioning at the component, microservice and application level addresses the complexity and keeps everyone informed of service usage across many teams.
+The use of versioning at the contianer and application level addresses the complexity and keeps everyone informed of shared usage across teams, and where open-source packages are consumed. 
 
 ## Conclusion
 
-Ortelius is a central 'evidence' store of all supply chain data and DevOps intelligence used across teams and organizational siloes. Ortelius integrates into your DevOps Pipeline to automate the collection of this data with versioning at both your component and 'logical application' levels. Ortelius is called at the 'build' step of your updated container or object. Ortelius captures Swagger logs, readme, SBOMs, and other build data, and then collects the new container data, such as the tag, when the container is registered. With this information, Ortelius creates a new version of the component. This in turn creates new versions of all consuming 'logical' applications. No manual work required.
+Ortelius is a central 'evidence' store of all supply chain data and DevOps intelligence used across teams and organizational siloes. Ortelius integrates into your DevOps Pipeline to automate the collection of this data with versioning at both your component and 'logical application' levels. Ortelius is called at the 'build' step of your updated container or object. Ortelius captures SBOMs, Swagger logs, readme, and other build data, and then collects the new container data, such as the tag, when the container is registered. With this information, Ortelius creates a new version of the component. This in turn creates new versions of all consuming 'logical' applications. No manual work required.
 
-Ortelius exposes risk by consuming each Component's Software Bill of Material (SBOM). This information provides a mountain of security data including the open-source packages and licenses. Ortelius can use this data to make it easy to answer the question "Where are we using Log4J?"
+Ortelius exposes risk by consuming each Component's Software Bill of Material (SBOM). This information provides a mountain of security data including the open-source packages and licenses. Ortelius continuously tracks this level of software supply chain data making it easy to answer the question "Where are we using Log4J?"
 
 <br>
 <br>