diff --git a/content/en/guides/_index.md b/content/en/guides/_index.md new file mode 100644 index 00000000..7e282036 --- /dev/null +++ b/content/en/guides/_index.md @@ -0,0 +1,7 @@ +--- +title: "Ortelius User Guides" +linkTitle: "Ortelius User Guides" +weight: 1 +description: > + Guides for both Contributing and Adopting Ortleius +--- diff --git a/content/en/guides/contributorguide/Getting Started/welcome.md b/content/en/guides/contributorguide/Getting Started/welcome.md index e18a082b..63cbbf75 100644 --- a/content/en/guides/contributorguide/Getting Started/welcome.md +++ b/content/en/guides/contributorguide/Getting Started/welcome.md @@ -9,7 +9,7 @@ description: > ## Welcome to the Ortelius Project -Have you ever wanted to contribute to the coolest cloud technology? Well here is your chance. The Ortelius Open Source Project's mission is to simplify the adoption of modern architecture through a world-class microservice management platform driven by a supportive and diverse global open source community. Watch this video on how to get started. +Have you ever wanted to contribute to the coolest cloud technology? Well here is your chance. The Ortelius Open Source Project's mission is fortify the software supply chain through a world class Continuous Security Intelligence solution, driven by a supportive and diverse global open source community. Watch this video on how to get started.
{{< youtube Y4kR6ipipxA >}} @@ -17,7 +17,9 @@ Have you ever wanted to contribute to the coolest cloud technology? Well here is ### What is Ortelius? -Ortelius is a microservice catalog that centralizes everything you need to know about a microservice including: ownership, vulnerabilities, versions, dependency relationships, consuming applications and versions. Ortelius visualizes ‘logical’ application versions in a microservice architecture providing a clear view of the microservice supply chain and their consumers. +The Ortelius Continuous Security Intelligence solution is an open-source project focused on surveilling the DevOps pipeline collecting clues and forensics about the software you deliver to end users from Software Bills of Materials (SBOM) to deployment metadata. + +The mission of the Ortelius community is to expose weak links in the software supply chain by continuously gathering and analyzing software supply chain intelligence introduced across the DevOps pipeline. Generating security insights like SBOMs is not enough to harden your software supply chain. Consumption and analysis of the data is needed to rapidly respond to supply chain threats. Ortelius is managed by the [Continuous Delivery Foundation](https://cd.foundation) a specialty foundation under the Linux Foundation. diff --git a/content/en/guides/contributorguide/_index.md b/content/en/guides/contributorguide/_index.md index 1a990b18..2b3009ca 100644 --- a/content/en/guides/contributorguide/_index.md +++ b/content/en/guides/contributorguide/_index.md @@ -1,7 +1,7 @@ --- title: "Ortelius Contributor Guide" linkTitle: "Ortelius Contributor Guide" -weight: 2 +weight: 1 description: > Guide for how to contribute to the Ortelius open source project --- diff --git a/content/en/guides/userguide/First Steps/2 Defining Domains.md b/content/en/guides/userguide/First Steps/2 Defining Domains.md index 09d9c20b..30a534bf 100644 --- a/content/en/guides/userguide/First Steps/2 Defining Domains.md +++ b/content/en/guides/userguide/First Steps/2 Defining Domains.md @@ -1,7 +1,7 @@ --- title: "Building Your Domain Catalog" linkTitle: "Building your Domain Catalog" -weight: 3 +weight: 6 description: > How to Create and Manage _Domains_ --- @@ -14,9 +14,9 @@ For this reason, it may be helpful to review how you might want to organize your ### Domains and your Domain Driven Design -A Domain-Driven Design (DDD) is often used when moving from a traditional development model to a cloud-native, decoupled model. With microservices, it is often recommended that a structured method for organizing microservices into "solution" spaces be completed to facilitate reuse across siloed teams. Ortelius _Domains_ provides this organization. +A Domain-Driven Design (DDD) is often used when moving from a traditional development model to a cloud-native, decoupled model. With decoupled architecture, it is recommended that a structured method for organizing shared services into "solution" spaces be completed to facilitate reuse across teams. Ortelius _Domains_ provides this organization. -_Domains_ publish microservices and other reusable objects (web components, DB updates, etc.) making it easier to share _Components_ across siloed teams. Domains can be structured to closely resemble the patterns of your organization. They can represent functional areas such as 'security services' or departments, teams, geographical locations and software projects. +_Domains_ publish _Components_ (microservices, artifacts, web components, DB updates, etc.) making it easier to share _Components_ across teams. Domains can be structured to closely resemble the patterns of your organization. They can represent functional areas such as 'security services' or departments, teams, geographical locations and software projects. ### Top Down Structure @@ -29,9 +29,9 @@ There are four common ways to implement _Domains_: | **Purpose** | Description | |---| --- | | **Site _Domain_** | This is the highest-level and default _Domain_. Your default Site _Domain_ name is 'Global.' You can rename your Site _Domain_ if needed. Anything defined to this level can be shared across all lower level _Subdomains_. For example, _Environments_ and _Tasks_ defined to the Site _Domain_ are shared by all child _Subdomains_.| -|**Catalog _Subdomains_**| These _Domains_ are used to organize reusable _Components_, such as microservices. At this level, you create as many _Subdomains_ as needed to represent your _Component_ organization based on the "solution space" they serve. For example, you could build your Catalog as follows:
  • Security Services
  • Purchase Processing
  • Data Access
  • Ad Services
    • A Catalog _Domain_ does not contain Life Cycle _Domains_. +|**Catalog _Subdomains_**| These _Domains_ are used to organize reusable _Components_. At this level, you create as many _Subdomains_ as needed to represent your _Component_ organization based on the "solution space" they serve. For example, you could build your Catalog as follows:
  • Security Services
  • Purchase Processing
  • Data Access
  • Ad Services
    • A Catalog _Domain_ does not contain Life Cycle _Domains_. |**Project _Subdomains_**| Use a _Subdomain_ to represent your software _Application_ and its Life Cycle. A _Subdomain_ defined for an _Application_ may need a continuous delivery life cycle. This is defined by selecting "All _Subdomains_ are Life Cycles." This means that any _Subdomains_ cannot include any additional _Subdomains_ and will be used to represent stages of the _Pipeline_ with specific _Environments_ assigned. | -|**Life Cycle _Subdomains_**| This is the lowest level of _Subdomain_. It is available when the parent _Domain_ has "All _Subdomains_ are Life Cycles" selected. These _Subdomains_ map to each stage in your continuous delivery pipeline. They often have specific _Environments_ and _Tasks_ assigned for interaction with your continuous delivery orchestration engine. Ortelius can be called by your continuous delivery Engine (Jenkins, Jenkins X, CircleCI, Google CloudBuild, GitLab or GitHub Actions, etc.) to perform the continuous configuration management of your microservices and _Applications_ across all lifecyle states. In addition, you can assign Move, Approve and Request Tasks to your Life Cycle _Subdomain_ to define a continuous delivery pipeline process within Ortelius that can interact with your pipeline process. | +|**Life Cycle _Subdomains_**| This is the lowest level of _Subdomain_. It is available when the parent _Domain_ has "All _Subdomains_ are Life Cycles" selected. These _Subdomains_ map to each stage in your continuous delivery pipeline. They often have specific _Environments_ and _Tasks_ assigned for interaction with your continuous delivery orchestration engine. Ortelius can be called by your continuous delivery Engine (Jenkins, Jenkins X, CircleCI, Google CloudBuild, GitLab or GitHub Actions, etc.) to perform the continuous configuration management of your _Components_ and _Applications_ across all lifecycle states. In addition, you can assign Move, Approve and Request Tasks to your Life Cycle _Subdomain_ to define a continuous delivery pipeline process within Ortelius that can interact with your pipeline process. | Below is an example of how an Online Store Company organized their _Domains_. @@ -60,7 +60,7 @@ When scrolling up or down the _Domain_ hierarchy using the Sunburst map, the det #### Access Control - _Users_ within the designated _Groups_ of "User" or "Admin" can update the _Domain_ in various ways. To add a _Group_ to one of the access lists, drag and drop the _Group_ from the Available _Groups_ list onto the desired access list. All _Users_ who belong to a _Group_ in one of the Access lists will be granted access to the _Domain_. Access control for _Domains_ include: + There are two User Groups, _Users_ and "Admins" You can define high-level security to these _Domains_ for these two Groups.: | Access | Description | | --- | --- | diff --git a/content/en/guides/userguide/First Steps/2 Intro to Set Up.md b/content/en/guides/userguide/First Steps/2 Intro to Set Up.md index 8106544d..5205c348 100644 --- a/content/en/guides/userguide/First Steps/2 Intro to Set Up.md +++ b/content/en/guides/userguide/First Steps/2 Intro to Set Up.md @@ -1,7 +1,7 @@ --- -title: "Get Started by Adding Ortelius to Your Pipeline" -linkTitle: "Get Started by Adding Ortelius to Your Pipeline" -weight: 1 +title: "Adding Ortelius to Your Pipeline" +linkTitle: "Adding Ortelius to Your Pipeline" +weight: 10 description: > Get Started by Adding Ortelius to Your Pipeline --- diff --git a/content/en/guides/userguide/First Steps/Basic Concepts.md b/content/en/guides/userguide/First Steps/Basic Concepts.md index 0a51ac56..3e3c4522 100644 --- a/content/en/guides/userguide/First Steps/Basic Concepts.md +++ b/content/en/guides/userguide/First Steps/Basic Concepts.md @@ -1,7 +1,7 @@ --- title: "Overview of Ortelius Objects and Concepts" linkTitle: "Overview of Ortelius Objects and Concepts" -weight: 2 +weight: 1 description: > Understanding Core Objects and Concepts. --- diff --git a/content/en/guides/userguide/Installation and Support/Orteliustutorial.md b/content/en/guides/userguide/Installation and Support/Orteliustutorial.md new file mode 100644 index 00000000..4bca9d17 --- /dev/null +++ b/content/en/guides/userguide/Installation and Support/Orteliustutorial.md @@ -0,0 +1,218 @@ +--- +title: "Free SaaS Signup and Tutorial" +linkTitle: "Free SaaS Signup and Tutorial" +weight: 2 +description: > + Signup and Learn How to Gather Continuous Security Intelligence +--- +This tutorial uses the Ortelius project to walk you through the basic concepts of Continuous Security Intelligence. DeployHub Team is based on the [Ortelius](https://ortelius.io) Open-Source project, incubating at the [Continuous Delivery Foundation](https://cd.foundation). This free SaaS version of Ortelius is hosted by DeployHub, and is also referred to as DeployHub Team. + +## Signing Up and Getting Started + +When you [signup for DeployHub Team](https://www.deployhub.com/deployhub-team/), you are asked for basic information, your UserID/Password, Company and Project names. Your UserID/Password and Company name are unique. Your Project will be a _Subdomain_ under your Company _Domain_. + +DeployHub Team is accessible through the following url: + +[https://console.deployhub.com/dmadminweb/Home](https://console.deployhub.com/dmadminweb/Home) + +Login using the UserID and Password you used when you signed up for DeployHub. Check your email for your login information. + +Upon logging into DeployHub, you will be given an option to select your Company Name Domain, or the Open Source Domain. The Open Source Domain is prepopulated with data so you can take a tour. Select the Open Source Domain to start exploring. + +![Sign into a Domain](/guides/userguide/images/domainsignin.jpg) + +## Explore Domains + +_Domains_ serve as the basic structure of organizing Continuous Security Intelligence. Developers use _Domains_ to catalog their _Components_ based on 'solution spaces.' Organizing your software supply chain in this way allows for _Components_ to be easily shared. + +_Domains_ are not folders. They serve as a method for creating fully qualified names of Objects within DeployHub to keep things organized. _Domains_ also manage security and Tasks. When you assign security options and Tasks at the _Domain_ level, any child _Subdomain_ inherits the value. A child _Subdomain_ can override a parent _Domain_ value. + +You can explore the _GLOBAL.open source_ Domain to learn how Continuous Security Intelligence is organized. In DeployHub terminology, the _GLOBAL.open source_ Domain has multiple _Subdomains_. + +### Take a Tour of _Domains_: + +1) From the left hand side menu, select _Domains_ to see the child _Subdomains_. You will see Linux Foundation, NPM, Golang, Maven as a few of the options. Click on Linux Foundation to expand the chart to view further _Subdomains_. + +2) You will see the Linux Foundation includes the CDF and OpenSSF as _Subdomains_. Under the CDF, you will see the child _Subdomain_ Ortelius. Select Ortelius to see the _Subdomains_ associated to the Ortelius project. These _Subdomains_ represent different releases of Ortelius. + +For More information on Domains see - [Building _Domains_](/userguide/first-steps/2-defining-domains/) + +## Explore Components + +_Components_ are artifacts, binaries, database SQL, files or any deployable artifact. _Components_ are assigned to _Applications_. This assignment allows for the aggregation of data from the _Components_ to the _Applications_ that consume them, providing unified Software Bill of Materials reports and Application Security Posture reports. + +### Take a Tour of _Components_ + +1) View Components + +From the left hand side menu, select "_Components_". Using the filter option, choose _GLOBAL.Open Source.Linux Foundation.CDF.Ortelius_ to view all of the _Components_ consumed by the Ortelius open source project. + +![Ortelius Domain](/guides/userguide/images/OrteliusDomainSelection.jpg) + +


    + +2) Component Lists + +Notice that the first item in the list is _ms-compitem-crud;main_. "Main" indicates the base version of this _Component_. The subsequent items in the list shows the changes from the "Main" branch. + +![Components](/guides/userguide/images/OrteliusComponentMain.jpg) + +


    + + 3) Historical Comparisons + +Generate a Comparison Report between two _Component_ versions. Checkmark any two versions and select the _Compare_ option from the list menu to see their differences. + +![Compare Components](/guides/userguide/images/componentlist.jpg) + +


    + + 4) Software Bill of Materials + +View a _Component_ Software Bill of Materials (SBOM) Report. When your _Component_ build executes, Ortelius will generate an Software Bill of Material using the tool of your choice. DeployHub then cross references the known vulnerabilities to the packages. The report shows a timestamp to record the point in time the vulnerabilities were found. This is a static view of the known vulnerabilities at build time. + +![Component SBOM](/guides/userguide/images/SBOM-component.jpg) + +


    + + 5) Sorting Components + +Sort Components by "Completed." "Completed" indicates the _Component_ has been deployed to end users. From the _Component_ list view, click on "Completed" to sort. Select a _Component_ in the completed list to view its Security Posture and current vulnerabilities. DeployHub provides updates to vulnerabilities every 30 minutes. + +![CompletedComponents](/guides/userguide/images/completed.jpg) + +


    + +6) Component Details + +View the _Components_ details including the OpenSSF Scorecard Results, current known vulnerabilities, and Overall _Component_ Security Posture. + +![Components Scorecard](/guides/userguide/images/componentOpenSSFSC.jpg) + +


    + +![Components Swagger](/guides/userguide/images/readme-swagger.jpg) + +


    + +![Components Vulnerabilities](/guides/userguide/images/newvulnerabilities.jpg) + +


    + +7) Blast Radius + +View the Blast Radius of a _Component_. The Blast Radius shows you what 'logical' applications are impacted by a vulnerability, anomaly, or update. From the _Component_ detail screen, scroll to the bottom to see the Dependency Map. You will see this map shows the versions of the Ortelius "logical" _Application_ that are using this version of the _Component_. + + +![Component Map](/guides/userguide/images/component-map.jpg) + +
    + +For More information on Components see - [Publishing _Components_](/guides/userguide/publishing-components/) + +## Explore Applications + +An _Application_ is a collection of _Components_ that make up a complete software solution. DeployHub manages the Logical _Application_ aggregating _Component_ data up to the application-level. + +### Take a Tour of _Applications_ + +1) Application Lists + +From the left hand side menu, select "_Applications"_. If you have completed the above steps, you will still be in the _GLOBAL.Open Source.Linux Foundation.CDF.Ortelius_ Domain. Notice that the first item in the list is _ortelius_ without a assigned Version number. This indicates the main branch of the Ortelius _Application_. Select "Completed" from the list menu options to sort by all versions of Ortelius that have been released. + +![Application List](/guides/userguide/images/app-list.jpg) + +


    + + 2) Compare Versions + +Generate a Comparison Report between two _Application_ versions. Checkmark any two versions and select the _Compare_ option from the list menu to see their differences. + +![Compare Applications](/guides/userguide/images/app-compare-select.jpg) + +


    + +Results: + +![Compare Application Results](/guides/userguide/images/app-compare.jpg) + +


    + +4) Aggregated Software Bill of Materials + +View an aggregated _Application_ Software Bill of Material report. An _Application_ SBOM is a report that shows all of the _Application's_ _Component_ SBOM data, with duplicates removed. When a _Component_ is updated, DeployHub automatically creates a new version of all _Applications_ consuming the _Component_, with a new aggregated SBOM. DeployHub then cross references all of the _Application's_ _Components_ packages with the known vulnerabilities. The report shows a timestamp to record the point in time the vulnerabilities were found. This is a static view of the known vulnerabilities at build time for the _Application_ with SBOM details. If you are required to produce an SBOM for governance purposes, you can provide your consumers with access to the DeployHub platform allowing them to 'self serve' and track your _Application's_ security posture. + +


    + +![Export SBOM](/guides/userguide/images/exportSBOM.jpg) + +


    + +5) Application Details + +View the _Application_ details including: +- List of _Components_ the _Application Consumes +- List of OS packages from the SBOM report +- List of current vulnerabilities + +![Application details](/guides/userguide/images/application-detials.jpg) + +


    + +6) Application Security Posture + +View the _Applications_ overall security posture. This report shows the security activities that are associated with the DevSecOps pipeline. + +![Compliance Run](/guides/userguide/images/run-compliance.jpg) + +


    + +Results: + +![Compliance Results](/guides/userguide/images/compliance-results.jpg) + +


    + +Learn More at [Packaging _Applications_](/guides/userguide/packaging-applications/) + + +## Explore Open-Source Inventory + +DeployHub allows you to search your entire inventory of _Components_ for open-source packages. Rapidly responding to vulnerabilities requires you know precisely where your exposure to the vulnerability is running, and what _Components_ need to remediated. + +### Take a Tour of Open-Source Inventory + + 1) Open Source Package Search + +Search for Package using the "Package Search" menu option from the _Application_ list view. + +![Package Search Menu](/guides/userguide/images/packagesearchmenu.jpg) + +


    + + 2) Enter the Package Name + +Enter the package you wish to search for such as "Spring." + +![Package Search Menu](/guides/userguide/images/spring-search.jpg) + +


    + +Results: + +![Package Search Menu](/guides/userguide/images/spring-results.jpg) + + + +## Conclusion + +There are many other features of DeployHub that we did not get to cover on this short test drive. However, you should have the basic understanding of the major Objects and concepts needed to get you started. What we did not cover that you may want to view are: + +[Environments and Endpoints](/userguide/first-steps/2-define-your-credentials/) - Environments and Endpoints can be used to: +- execute deployments using DeployHub's internal agentless deployment engine +- associate an artifact repo to your _Application_ +- connect your external deployment tools, called from your CI/CD deployment step, to DeployHub. + +Another important topic is integrating with your CD pipeline. See [Using DeployHub with CI/CD](/userguide/integrations/ci-cd_integrations/) on how you can include gathering all DevSecOps data. + +We will leave you with how to setup DeployHub for your installation. See [First Steps](/userguide/first-steps/), for getting your setup completed. Once you have your setup complete you can start continuously gathering your software supply chains security intelligence. diff --git a/content/en/guides/userguide/Introduction/_index.md b/content/en/guides/userguide/Introduction/_index.md index 4e18953b..b8fc0bcb 100644 --- a/content/en/guides/userguide/Introduction/_index.md +++ b/content/en/guides/userguide/Introduction/_index.md @@ -3,30 +3,30 @@ title: "Welcome" linkTitle: "Welcome" weight: 1 description: > - Introduction to the Ortelius Supply Chain Catalog + Introduction to the Ortelius Continuous Security Intelligence --- ## Why Use Ortelius -Ortelius is an open source, supply chain evidence catalog for publishing, versioning and sharing microservices and other _Components_ such as DB objects and file objects. Ortelius centralizes everything you need to know about a component-driven architecture including _Component level_ ownership, SBOMs, vulnerabilities, dependency relationships, key values, deployment metadata, consuming applications and versions. Ortelius harvests information from the DevOps pipeline centralizing supply chain data across tools and teams. +Ortelius is an open source, Continuous Security Intelligence solution for surveilling, gathering and analyzing the security posture of _Components_ and their consuming "logical" _Applications_". Ortelius is particularly suited for complex, decoupled architectures where hundreds of artifacts and repos are used, and a central view of the entire supply chain from a usage, security, and inventory perspective is required. When you outgrow your excel spreadsheet, its time to consider Ortelius. The Ortelius watch center tracks _Component_ ownership, SBOMs, vulnerabilities, dependency relationships, key values, deployment metadata, consuming _Applications_ and versions. Ortelius collects clues and forensics from the DevOps pipeline centralizing supply chain data across tools and teams. ![Supply Chain Catalog](/supplychaincatalog.png) +## The "Logical" Application -Ortelius visualizes ‘logical’ application versions in a cloud-native architecture providing a clear view of the software supply chain and their consumers. With this _Component_ level information, Ortelius can easily aggregate metadata up to the 'logical' application producing application level SBOMs, CVEs, audit reports, deployment inventory and status. - -Ortelius is particularly suited for a microservice architecture where hundreds of artifacts and repos are used, and a central view of the entire supply chain from a usage, security, and inventory perspective is required. When you outgrow your excel spreadsheet, its time to consider Ortelius. +In order to understand the security posture of an _Application_, teams need to know the _Component_ dependencies, and the _Component_ packages. Ortelius aggregates DevSecOps data to the ‘logical’ application versions simplifying the complexities of a cloud-native architecture. Ortelius provides a clear view of the software supply chain for every "logical" _Application_ and its _Components_. By tracking _Component_ level information, Ortelius can easily aggregate metadata up to the 'logical' application producing application level SBOMs, CVEs, audit reports, deployment inventory and status. **Decoupled Environments are Complex** -Migrating to decoupled, cloud-native architecture breaks the way we assemble and configure software. With a decoupled implementation, we no longer build a complete software solution, or Application Version. Instead we manage many moving parts that communicate at run-time based on APIs. The loss of the 'Application Version' disrupts the core of software delivery. It impacts most of our standard software practices including the generation of application security level reports. After all, everything is based on an Application Version from tracking changes request, determining differences, tracking relationships and supporting users. Without a method of tracking the logical _Application_, IT teams struggle to confirm that the software they deliver to end users is safe. +Migrating to decoupled, cloud-native architecture breaks the way we assemble and configure software. With a decoupled implementation, we no longer build a complete software solution, or _Application Version_. Instead we manage many moving parts that communicate at run-time based on APIs. The loss of the _Application Version_ disrupts the core of software delivery. It impacts most of our standard software practices including the generation of application security level reports. After all, everything is based on an Application Version from tracking changes request, determining differences, tracking relationships and supporting users. Without a method of tracking the logical _Application_, IT teams struggle to confirm that the software they deliver to end users is safe. -Ortelius is not a 'microservice registry' or 'API Gateway." Instead, Ortelius interacts with the DevOps pipeline to automatically gather supply chain metadata. Tracking microservices and _Components_ in this way facilitates their sharing and reuse across teams. Ortelius serves as an internal market place for finding, tracking and versioning microservices and relating them to the _Applications_ that consume them. The publishing catalog is based on a _Domain_ structure to support a Domain Driven Design. +Ortelius is not a 'artifact registry' or 'API Gateway." Instead, Ortelius interacts with the DevOps pipeline to automatically gather supply chain metadata. Tracking _Components_ in this way facilitates their sharing and reuse across teams. Ortelius serves as an internal market place for finding, tracking and versioning _Components_ and relating them to the _Applications_ that consume them. The evidence organization is based on a _Domain_ structure to support a Domain Driven Design. ## Versioning - Ortelius Secret Sauce Ortelius versions both _Components_ and 'logical' _Applications_. When versioning _Components_, Ortelius provides insights needed to determine if the service is safe for consumption including: - Software Bill of Material +- OpenSSF Scorecard - Common Vulnerabilities and Exposures (CVE) - Swagger Details - Readme and Licensing @@ -43,7 +43,7 @@ Ortelius versions both _Components_ and 'logical' _Applications_. When versioni _Application Versions_ are based on a collection of _Component Versions_. If a new version of a _Component_ is built or registered, Ortelius auto increments the _Component_ version and the consuming _Application_ version. Dashboards are provided for each new _Application_ version showing: -- A full map of all the microservices, or _Components_, the _Application_ version is consuming. +- A full map of all the _Components_, the _Application_ version is consuming. - An Application Level SBOM, based on all _Component_ SBOMs - An Application Level CVE - The specific changes that created the new _Application_ version (your new diff report) @@ -52,12 +52,13 @@ Ortelius versions both _Components_ and 'logical' _Applications_. When versioni - Where it is running - Trends (Deployment time, success failure rates) -This level of information can also be viewed from the _Component_ level showing similar information to the _Application_, but instead showing the _Applications_ that are dependent on the microservice (_Component_). +This level of information can also be viewed from the _Component_ level showing similar information to the _Application_, but instead showing the _Applications_ that are dependent on the _Component_. ## Other Core Features -**Domain-Driven-Design:** First and most important is the Ortelius Domain structure for cataloging and sharing microservices. This feature organizes your microservice in a method that encourages reuse and sharing across development teams. -**Dependency maps:** Shows you the 'logical' view of your application and which microservices, or _Components_, it consumes. Once you begin sharing microservices, you need to track who is using the microservice. An _Application_ is a logical collection of _Components_ that make up an entire software solution. +**Domain-Driven-Design:** First and most important is the Ortelius Domain structure for organizing security forensics. This feature organizes your _Component_ metadata in a method that encourages reuse and sharing across development teams. + +**Dependency maps:** Shows you the 'logical' view of your application and which _Components_ it consumes. Once you begin sharing _Components_ you need to track their usage. An _Application_ is a logical collection of _Components_ that make up an entire software solution. **Application Level SBOMs and CVE:** Ortelius aggregates all _Component_ level data up to the logical _Application Version_ making it easy to provide security reporting on a complete software system, even when it is decoupled. diff --git a/content/en/guides/userguide/Packaging Applications/2 Defining Applications.md b/content/en/guides/userguide/Packaging Applications/2 Defining Applications.md index 22dcefcb..f1de1b54 100644 --- a/content/en/guides/userguide/Packaging Applications/2 Defining Applications.md +++ b/content/en/guides/userguide/Packaging Applications/2 Defining Applications.md @@ -8,7 +8,7 @@ description: > ## Using the _Application_ List View for Adding or Deleting -Use the _Application_ List View accessible from the left hand _Application_ menu option. This will take you to a list of all _Application Base Versions_ and _Application Versions_ to which you have access. There is a row for every _Environment_ to which the _Application Base Version_ or _Application Version_ has been deployed. For this reason, there will be multiple entries for the same _Application_ if it has been deployed to multiple _Environments_. +Use the _Application_ List View accessible from the left hand _Application_ menu option. This will take you to a list of all _Application Base Versions_ and _Application Versions_ to which you have access. There is a row for every _Environment_ to which the _Application Base Version_ or _Application Version_ has been assigned. For this reason, there will be multiple entries for the same _Application_ for every update. The list view is organized on the following columns: @@ -17,16 +17,14 @@ The list view is organized on the following columns: |**Version**| The _Application Base Version_ or _Application Version_ number. | |**Domain**| The _Domain_ to which the _Application_ belongs.| |**Parent**| The _Application Base Version_ from which the _Application Version_ was created. This will be empty for the _Application Base Version_.| -|**Environment**| The _Environment_ to which the _Application_ has been deployed. Each _Environment_ will represent a different row in the List View table.| -|**Last Deployment to Environment**| The Deployment Log number.| -|**Completed**|The date and time of the last deployment to the listed _Environment_.| +|**Environment**| The _Environment_ to which the _Application_ has been assigned. Each _Environment_ will represent a different row in the List View table.| +|**Completed**|The date and time of the last publish to the listed _Environment_.| |**Results**| Success or Fail.| You can also use the Filter bar, represented by a funnel icon, to reorder your _Application_ List View by: - Domain - Environment -- Last Deployment - Parent - Result - Version @@ -77,27 +75,6 @@ Your _Application's_ SBOM is derived by aggregating all of your _Package Compone >Note - This list may be incomplete if one or more of your _Package Components_ do not have an associated SBOM. - -### Log History - -_Applications_ can be deployed many times, to the same or different locations (_Environments_). For every Deployment, the Log History will show all deployments based on "Result" and "Date". - -{{% include "guides/userguide/reusable/Attributes.md" %}} - -### Trends - -The Trends graph shows the success or failure rates overtime as well at the time required for the last 10 deployments. If an _Application_ deployment takes longer than previous deployments, there is an issue with the deployment logic. - -### Deployed Environments - -When you record deployments via the Ortelius CLI, you can capture deployment data showing which _Application Versions_ have been deployed an _Environment_. - -### Last Deployment Difference Based on Environment - -When tracking versions, the Difference Graph shows what changed in the last deployment between the previous deployment. - -{{% include "guides/userguide/reusable/AuditTrail-withDeployments.md" %}} - ### Access _Users_ within designated _Groups_ can update or view the _Application_. To add a _Group_ to one of the access lists, drag and drop the _Group_ from the Available Groups list onto desired access list. All _Users_ who belong to a _Group_ within an Access lists will be granted access to the _Application_: @@ -106,17 +83,14 @@ When tracking versions, the Difference Graph shows what changed in the last depl | --- | --- | | **View** | Any _User_ in any _Group_ within this list can see the selected _Component_ in the List View. | | **Change** | Any _User_ in any _Group_ within this list can make changes to the _Component_. | -| **Deploy** | Any _User_ in any _Group_ within this list can deploy the _Application_. Restrictions are based on the Access defined at the _Environment_ level. | - ## Package Components Tab -This tab contains all the _Components_ that make up an _Application_, linked together in order of deployment if needed using a blueprint designer. Click on the _Component_ Selector on the right side to see the available _Components_ based on _Domains_ and Categories. A Category acts as a tag or label assigned at the _Component_ level and are not specific to _Domains_. _Domains_ are identified with a sitemap icon. A Category is identified with a Tag icon. Selecting either expands the options to show all available _Components_. +This tab contains all the _Components_ that make up an _Application_, linked together using a blueprint designer. Click on the _Component_ Selector on the right side to see the available _Components_ based on _Domains_ and Categories. A Category acts as a tag or label assigned at the _Component_ level and are not specific to _Domains_. _Domains_ are identified with a sitemap icon. A Category is identified with a Tag icon. Selecting either expands the options to show all available _Components_. -Click and drag a _Component_ from the list on the far right side and drop it into the Assigned _Components_ area. It will appear in the area as a box containing the name of the _Component_. It automatically links to the last _Component_. Right click on the connecting line, select "Delete this Connection".Create by Click on the anchor (the green dot at the bottom of the _Component_) to create a new connector. Then drag and drop it onto another _Component_. This determines the order in which the _Components_ will be deployed. Each _Component_ contains _Component Items_ also linked together in the order to be executed. For a microservice implementation, they can all be linked to the "start point". This means they will be deployed in parallel. +Click and drag a _Component_ from the list on the far right side and drop it into the Assigned _Components_ area. It will appear in the area as a box containing the name of the _Component_. It automatically links to the last _Component_. Right click on the connecting line, select "Delete this Connection".Create by Click on the anchor (the green dot at the bottom of the _Component_) to create a new connector. Then drag and drop it onto another _Component_. Each _Component_ contains _Component Items_ also linked together in the order to be executed. -NOTE: At least one _Component_ must be connected to the "start point" or the deployment will fail. ## How to Publish New _Application Versions_ Automatically via Continuous Delivery -Configure a continuous delivery system to automatically update new _Application_ versions each time a new GitCommit triggers a new _Component_ to be consumed by your _Application_. Ortelius in the workflow performs this continuous versioning of new _Components_ and their consuming _Applications_. For more information, see [Using Ortelius with CI/CD](/guides/userguide/integrations/ci-cd_integrations/). +Configure a CI/CD system to automatically update new _Application_ versions each time a new GitCommit triggers a new _Component_ to be consumed by your _Application_. Ortelius in the workflow performs this continuous versioning of new _Components_ and their consuming _Applications_. For more information, see [Using Ortelius with CI/CD](/guides/userguide/integrations/ci-cd_integrations/). diff --git a/content/en/guides/userguide/Packaging Applications/BuildingApplications.md b/content/en/guides/userguide/Packaging Applications/BuildingApplications.md index 78d5898c..2362dd94 100644 --- a/content/en/guides/userguide/Packaging Applications/BuildingApplications.md +++ b/content/en/guides/userguide/Packaging Applications/BuildingApplications.md @@ -3,28 +3,20 @@ title: "Intro to Applications" linkTitle: "Intro Applications" weight: 4 description: > - An overview of applications and their versions, tasks, components and deployments. + An overview of applications and their versions, Metadata, and components. --- ## Application Base Versions and Versions - _Applications_ are main [Objects](/guides/userguide/concepts/basic-concepts/#application-object) in Ortelius. They are a collection of _Components_ that can be deployed as a single software solution. You define an _Application_ by associating the _Components_ it will consume. The first time you define an _Application_, it is referred to as the _Application Base Version._ When you change the _Application Base Version_, you create a new _Application Version_. _Applications_ are assigned and deployed to _Environments_. _Applications_ are associated to a _Domain_. + _Applications_ are a collection of _Components_ that represent a single software solution delivered to end users. You define an _Application_ by associating the _Components_ it will consume. The first time you define an _Application_, it is referred to as the _Application Base Version._ When you change the _Application Base Version_, you create a new _Application Version_. - **Application Base Version** : Defines the software product in terms of _Components_, _Attributes,_ and assigned _Environments_. -- **Application Version** : This child of the _Application Base Version_ represents changes and can be deployed just as an _Application Base Version_ is. +- **Application Version** : This child of the _Application Base Version_ represents the differences. -An _Application_ and all objects within it will be deployed to one or more _Endpoints_. (Each one represents a container, physical or virtual server in the enterprise in an _Environment_. A backend versioning engine tracks all _Application Version_ configurations. For this reason, each new version will be given a new version number. - -For instance, your Application Base Version may be called MyApp;1, subsequent versions would be automatically named MyApp;2, MyApp;3, etc. +For instance, your Application Base Version may be called MyApp;1, subsequent versions would be automatically named MyApp;2, MyApp;3, etc. When a new _Application Version_ is created from either an _Application Base Version_ or another _Application Version_, it inherits all previous _Components_ and Attributes from its predecessor. You can create a new _Application Version_ from any previous version. ## Applications and their Components -_Applications_ are defined by the _Components_ they consume. As with _Applications_, _Components_ have versions. If a new _Component_ is made available, Ortelius can be called by a continuous delivery tool to automatically create a new _Application Version_ each time a new build is detected. For more information on this topic, see the [CD Engine Chapter](/guides/userguide/integrations/ci-cd_integrations/). - -When a new _Application Version_ is created from either an _Application Base Version_ or another _Application Version_, it inherits all previous _Components_ and Attributes from its predecessor. You can create a new _Application Version_ from any previous version. - -## Applications and Tasks - -_Tasks_ allow you to act upon _Applications_. They are defined at the _Domain_ level and are available to all of the _Applications_ within the Domain as default _Tasks_. _Tasks_ can also be called via your continuous delivery pipeline. Common _Tasks_ integrated into continuous delivery are _Move Version_, _Approve_ and _Deploy_. All _Tasks_ are managed at the _Domain_ level. For more information on Tasks and _Domains_ see [Deployment Task](/guides/userguide/first-steps/2-defining-domains/#deployment-tasks). +_Applications_ are defined by the _Components_ they consume. As with _Applications_, _Components_ have versions. If a new _Component_ is made available, Ortelius can be called by a continuous delivery tool to automatically create a new _Application Version_ each time a new build is detected. For more information on this topic, see [CI/CD Integrations](/guides/userguide/integrations/ci-cd_integrations/). diff --git a/content/en/guides/userguide/Publishing Components/2 Define Components.md b/content/en/guides/userguide/Publishing Components/2 Define Components.md index 9d441d78..5e13974f 100644 --- a/content/en/guides/userguide/Publishing Components/2 Define Components.md +++ b/content/en/guides/userguide/Publishing Components/2 Define Components.md @@ -50,11 +50,10 @@ When adding new _Components_ select the _Component_ Type from the drop down lis | --- | --- | | **Container** | For Containers such as Docker. | | **Application File** | For binary files such as .jar, .war, .ear, .exe, .dll, Linux executable files, Oracle Forms, or similar artifacts. | -| **Database** | For SQL files such as .ddl or other database update scripts. | ## How to View and Edit _Components_ -_Components_ are defined as Container, Application File, or Database. These are the different types of _Components_ you may need from microservices to binaries and DB updates. The Dashboard view displays all information related to a specific _Component Base Version_ or _Component Version_. Depending on what type of _Component_ you are defining, you will be presented with different data definition fields. +_Components_ are defined as Container, Application File, or Database. These are the different types of _Components_ you may need from microservices to binaries. The Dashboard view displays all information related to a specific _Component Base Version_ or _Component Version_. Depending on what type of _Component_ you are defining, you will be presented with different data definition fields. The following fields are common to all _Components_: @@ -107,32 +106,6 @@ A Container _Component_ has the following optional attributes: | **Build URL**| The URL to the _Build Engine_. | |**Build Date**| The timestamp from when the last build job was run.| -### Database Type Specific Data Definition - -Database _Components_ are used for making database updates such as table changes using SQL Scripts. Note: An database form (such as an Oracle Form) can be compiled and should be defined as an Application File not Database _Component_. - -| Field | Description | -| --- | --- | -| **Base Directory**|Base, or high level, directory where the file will be deployed. This value will be ignored if the _Endpoint_ has a Base Directory defined. See [Formatting Directories](/guides/userguide/publishing-components/2-define-components/#formatting-of-the-deployment-directory-with-base-and-target-directories-for-database-and-application-file-deployments) on the order of how the deployment directory is formatted. | -|**Roll Forward Target Directory**| The directory under the Base Directory where the Roll Forward file will be deployed, or final "Target" Directory. See [Formatting Directories](/guides/userguide/publishing-components/2-define-components/#formatting-of-the-deployment-directory-with-base-and-target-directories-for-database-and-application-file-deployments) on the order of how the deployment directory is formatted. | -|**Roll Forward Repository**| Choose the Repository that contains your Roll Forward SQL. This list box is populated based on the _Repositories_ pre-defined in your initial setup. Based on the _Repository_ you select, you may be provided override or append fields if they were made available. For more information on _Repositories_ see [Connecting Your Repositories](/guides/userguide/first-steps/2-define-repositories/#using-the-repository-dashboard-for-viewing-and-editing). | -| **Rollback Target Directory** | The directory under the Base Directory where the Rollback file will be deployed, or final "Target" Directory. See [Formatting Directories](/guides/userguide/publishing-components/2-define-components/#formatting-of-the-deployment-directory-with-base-and-target-directories-for-database-and-application-file-deployments) on the order of how the deployment directory is formatted. | -| **Rollback Repository** | Choose the Repository that contains your Roll Forward SQL. This list box is populated based on the _Repositories_ pre-defined in your initial setup. Based on the _Repository_ you select, you may be provided override or append fields if they were made available. For more information on _Repositories_ see [Connecting Your Repositories](/guides/userguide/first-steps/2-define-repositories/#using-the-repository-dashboard-for-viewing-and-editing). | - - -## _Endpoints_ - -This section lists all _Endpoints_ that the _Component_ has been installed to with its Deployment Number. The Deployment Number is generated by Ortelius for each unique deployment. You can also use this section to stop incremental deployments and force a specific version to be deployed to the _Endpoint_. By manually adding a specific _Component Version_ to the _Endpoint_, you bypass the incremental deployment logic of the deployment engine. For example, if you would like to deploy a particular container without accepting any intermediate updates, you would go to the intermediate _Component Versions_ and manually add them to the _Endpoints_, causing the deployment engine to believe that it was previously deployed. When you manually add an _Endpoint_, the Deployment Number will show "manually deployed." To manually add a _Component_ to an _Endpoint_, use the +Add option. You will be provided a list of available _Endpoints_. Use Save to commit the change to the table. You can select multiple _Endpoints_. To Edit or Delete an _Endpoint_, select the _Endpoint_ and use the Edit or Delete option. - -{{% include "guides/userguide/reusable/Attributes.md" %}} - -## Deployed Environments for _Component_ - -A map showing all _Environments_ where the _Component_ is deployed. - -## Consuming _Applications_ - -This section shows a list of all _Applications_ that are consuming this _Component_. ## Component Readme diff --git a/content/en/guides/userguide/Publishing Components/Intro to Components.md b/content/en/guides/userguide/Publishing Components/Intro to Components.md index aa47d254..371ed6f3 100644 --- a/content/en/guides/userguide/Publishing Components/Intro to Components.md +++ b/content/en/guides/userguide/Publishing Components/Intro to Components.md @@ -8,9 +8,9 @@ description: > ## Intro to _Components_ -Ortelius manages microservices and other reusable objects as _Components_. _Components_ are assigned to an _Application_ even though they are managed independently. Assign _Components_ to _Applications_ to track a 'logical' view of your software solution. In a monolithic approach, we performed this step during the software compile and link, or 'build' process. In microservices, they are loosely coupled and linked at run-time. Defining _Components_ to [_Applications_](/guides/userguide/packaging-applications/buildingapplications/) puts the _Application_ in a 'logical' view. +_Components_ are files, artifacts, or containers. _Components_ are assigned to an _Application_ but managed independently. Assign _Components_ to _Applications_ to track a 'logical' view of your software solution. In a monolithic approach, we performed this step during the software compile and link, or 'build' process. In loosely coupled architectures, linking is done at runtime via APIs. Ortelius uses a 'logical' [_Applications_](/guides/userguide/packaging-applications/buildingapplications/) to aggregate _Components_ data to the higher _Application_ level to provide _Application_ security postures, aggregated SBOM, and blast radius impact of a vulnerability. -If you are an API or microservice developer, this will be where you do most of your work. However, application developers may also define _Components_ that are used only by their specific _Application_. _Components_ are microservices (containers), Database updates or files. By tracking the low level metadata for a _Component_, it can be easily shared in a consistent way across organizational teams and _Environments_. +If you are an API developer, this will be where you do most of your work. However, application developers may also define _Components_ that are used only by their specific _Application_. _Components_ are microservices, containers, database updates or files. _Components_ change over time, and so Ortelius contains _Component Base Versions_ and _Component Versions_. @@ -30,7 +30,7 @@ There is a many-to-many relationship between _Applications_ and _Components._ An ## Sharing _Components_ -If you want your microservice _Component_ to be shared across your teams, publish your _Component_ to a _Domain_ that allows sharing. If it is defined to only your _Application,_ then only your team will be able to see it. +If you want your _Component_ to be shared across your teams, publish your _Component_ to a _Domain_ that allows sharing. If it is defined to only your _Application,_ then only your team will be able to see it. ## _Component_ Versioning @@ -48,7 +48,7 @@ Ortelius uses a backend versioning engine to track your _Components_. Versioning - Deployment Metadata (Helm Chart, Ansible Playbook, etc.) - Any Attributes such as Key Value Pairs, environment variables, and database schemas. -This information is collected when you define your _Component_ to the Ortelius catalog. The Ortelius Command Line Interface will automatically update this information via your CD Pipeline. When your Pipeline initiates a workflow for the _Component_, it indicates that a new version of the _Component_ is being pushed across the Pipeline causing all consuming _Applications_ to be automatically incremented to a new version number. If a _Component_ changes, the consuming _Application_ also changes. Both get a new version number. For more information see [Using Ortelius with CI/CD](/guides/userguide/integrations/ci-cd_integrations/). +This information is collected when you define your _Component_ to the Ortelius evidenced store. The Ortelius Command Line Interface will automatically update this information via your CD Pipeline. When your Pipeline initiates a workflow for the _Component_, it indicates that a new version of the _Component_ is being pushed across the Pipeline causing all consuming _Applications_ to be automatically incremented to a new version number. If a _Component_ changes, the consuming _Application_ also changes. Both get a new version number. For more information see [Using Ortelius with CI/CD](/guides/userguide/integrations/ci-cd_integrations/). When you first define your _Component_ Ortelius tracks it as the _Component Base Version_. Subsequent updates to that _Component_ creates a new _Component Version_ which represent the updates over time. A _Component Base Version_ is always the first one created, and it acts as a model for subsequent _Component Versions_. Otherwise they are identical types of objects. diff --git a/content/en/guides/userguide/_index.md b/content/en/guides/userguide/_index.md index 5193708c..3a8247d8 100644 --- a/content/en/guides/userguide/_index.md +++ b/content/en/guides/userguide/_index.md @@ -3,5 +3,5 @@ title: "Ortelius User Guide" linkTitle: "Ortelius User Guide" weight: 1 description: > - Guide for using Ortelius + Documentation, Installation and Tutorial --- diff --git a/content/en/guides/userguide/images/OrteliusComponentMain.jpg b/content/en/guides/userguide/images/OrteliusComponentMain.jpg new file mode 100644 index 00000000..4284ba54 Binary files /dev/null and b/content/en/guides/userguide/images/OrteliusComponentMain.jpg differ diff --git a/content/en/guides/userguide/images/OrteliusDomainSelection.jpg b/content/en/guides/userguide/images/OrteliusDomainSelection.jpg new file mode 100644 index 00000000..24ee9a94 Binary files /dev/null and b/content/en/guides/userguide/images/OrteliusDomainSelection.jpg differ diff --git a/content/en/guides/userguide/images/SBOM-component.jpg b/content/en/guides/userguide/images/SBOM-component.jpg new file mode 100644 index 00000000..a81b98a3 Binary files /dev/null and b/content/en/guides/userguide/images/SBOM-component.jpg differ diff --git a/content/en/guides/userguide/images/SBOMDetialList.jpg b/content/en/guides/userguide/images/SBOMDetialList.jpg new file mode 100644 index 00000000..a81b98a3 Binary files /dev/null and b/content/en/guides/userguide/images/SBOMDetialList.jpg differ diff --git a/content/en/guides/userguide/images/app-compare-select.jpg b/content/en/guides/userguide/images/app-compare-select.jpg new file mode 100644 index 00000000..0e3cab7a Binary files /dev/null and b/content/en/guides/userguide/images/app-compare-select.jpg differ diff --git a/content/en/guides/userguide/images/app-compare.jpg b/content/en/guides/userguide/images/app-compare.jpg new file mode 100644 index 00000000..8374eb62 Binary files /dev/null and b/content/en/guides/userguide/images/app-compare.jpg differ diff --git a/content/en/guides/userguide/images/app-list.jpg b/content/en/guides/userguide/images/app-list.jpg new file mode 100644 index 00000000..cf7e3df6 Binary files /dev/null and b/content/en/guides/userguide/images/app-list.jpg differ diff --git a/content/en/guides/userguide/images/application Detials.jpg b/content/en/guides/userguide/images/application Detials.jpg new file mode 100644 index 00000000..df00e52c Binary files /dev/null and b/content/en/guides/userguide/images/application Detials.jpg differ diff --git a/content/en/guides/userguide/images/application-detials.jpg b/content/en/guides/userguide/images/application-detials.jpg new file mode 100644 index 00000000..df00e52c Binary files /dev/null and b/content/en/guides/userguide/images/application-detials.jpg differ diff --git a/content/en/guides/userguide/images/completed.jpg b/content/en/guides/userguide/images/completed.jpg new file mode 100644 index 00000000..48e03b18 Binary files /dev/null and b/content/en/guides/userguide/images/completed.jpg differ diff --git a/content/en/guides/userguide/images/compliance-results.jpg b/content/en/guides/userguide/images/compliance-results.jpg new file mode 100644 index 00000000..9f20db0e Binary files /dev/null and b/content/en/guides/userguide/images/compliance-results.jpg differ diff --git a/content/en/guides/userguide/images/component-map.jpg b/content/en/guides/userguide/images/component-map.jpg new file mode 100644 index 00000000..cfac9379 Binary files /dev/null and b/content/en/guides/userguide/images/component-map.jpg differ diff --git a/content/en/guides/userguide/images/componentOpenSSFSC.jpg b/content/en/guides/userguide/images/componentOpenSSFSC.jpg new file mode 100644 index 00000000..2e1013de Binary files /dev/null and b/content/en/guides/userguide/images/componentOpenSSFSC.jpg differ diff --git a/content/en/guides/userguide/images/componentlist.jpg b/content/en/guides/userguide/images/componentlist.jpg new file mode 100644 index 00000000..40c38651 Binary files /dev/null and b/content/en/guides/userguide/images/componentlist.jpg differ diff --git a/content/en/guides/userguide/images/domainsignin.jpg b/content/en/guides/userguide/images/domainsignin.jpg new file mode 100644 index 00000000..b6992a5a Binary files /dev/null and b/content/en/guides/userguide/images/domainsignin.jpg differ diff --git a/content/en/guides/userguide/images/exportSBOM.jpg b/content/en/guides/userguide/images/exportSBOM.jpg new file mode 100644 index 00000000..1246b86d Binary files /dev/null and b/content/en/guides/userguide/images/exportSBOM.jpg differ diff --git a/content/en/guides/userguide/images/newvulnerabilities.jpg b/content/en/guides/userguide/images/newvulnerabilities.jpg new file mode 100644 index 00000000..5323bc96 Binary files /dev/null and b/content/en/guides/userguide/images/newvulnerabilities.jpg differ diff --git a/content/en/guides/userguide/images/packagesearchmenu.jpg b/content/en/guides/userguide/images/packagesearchmenu.jpg new file mode 100644 index 00000000..336bf19d Binary files /dev/null and b/content/en/guides/userguide/images/packagesearchmenu.jpg differ diff --git a/content/en/guides/userguide/images/readme-swagger.jpg b/content/en/guides/userguide/images/readme-swagger.jpg new file mode 100644 index 00000000..ae7e0af0 Binary files /dev/null and b/content/en/guides/userguide/images/readme-swagger.jpg differ diff --git a/content/en/guides/userguide/images/run-compliance.jpg b/content/en/guides/userguide/images/run-compliance.jpg new file mode 100644 index 00000000..3b967153 Binary files /dev/null and b/content/en/guides/userguide/images/run-compliance.jpg differ diff --git a/content/en/guides/userguide/images/spring-results.jpg b/content/en/guides/userguide/images/spring-results.jpg new file mode 100644 index 00000000..0c16987a Binary files /dev/null and b/content/en/guides/userguide/images/spring-results.jpg differ diff --git a/content/en/guides/userguide/images/spring-search.jpg b/content/en/guides/userguide/images/spring-search.jpg new file mode 100644 index 00000000..da2a87cb Binary files /dev/null and b/content/en/guides/userguide/images/spring-search.jpg differ