Components and Their Security Posture

Intro to Components

Components are independent artifacts—such as containers, jar files, and executables—pushed through the CI/CD pipeline and deployed separately, each with its own security details, including Software Bill of Materials (SBOMs) and vulnerabilities. DeployHub Pro continuously tracks the CI/CD pipeline, collecting both security and DevOps insights for every Component. By mapping this data, DeployHub Provides a unified view of each Component’s security profile.

A collection of Components forms a ’logical’ view of an Application. Because each Component comes with its own security and DevOps data, DeployHub Pro aggregates the Component insights for all ’logical’ Applications. This aggregation provides a comprehensive view of the ’logical’ Application’s SBOMs and vulnerabilities, supporting a unified security perspective within complex, decoupled, cloud-native architectures.

Components change over time, and so they have both a Component Base Versions, the first iteration of a Component, and Component Versions, all subsequent iterations.

• Component Base Version : The initial definition of a Component.

• Component Version : A child of the Component Base Version that represents changes.

Publish New Component Versions automatically via the CI/CD Pipeline

Components can only be added via your CI/CD pipeline. Configure your CI/CD Pipeline to automatically update new Component Versions each time a new GitCommit triggers the workflow process. Add DeployHub Pro to the workflow to perform the continuous versioning of new Components and their consuming Applications. For more information, see Using DeployHub Pro with CI/CD.

Components and Domains

Components are organized by Domains. When you create a new Component you publish it to the Domain that defines the “Solution Space” the Component addresses. By organizing Components into Domains, you create a catalog that allows other teams within your organization to find the Component, view its security profile, and share its Software Bill of Materials (SBOM) report.

The organization of Components by Domains support the Domain Driven Design of a decoupled architecture. Before you begin publishing Components, you will need to have a Domain ready. For more on Domains see the Building Your Domain Catalog.

Components and Applications

Components are consumed by Applications. You track a ’logical’ view of your complete software solution by assigning Components to the consuming Application. Defining Components to Applications is a “packaging” process that is done through your CI/CD pipeline.

There is a many-to-many relationship between Applications and Components. An Application can contain many different Components. A Component can be used across many different Applications. DeployHub Pro tracks and versions all Component Version relationships including to which Applications they have been assigned.

Component Versioning

DeployHub Pro uses a backend versioning engine to track your Components. When you first add your Component, DeployHub Pro 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. Versioning tracks Component attributes including low level information that is needed for other teams to reuse your Component including:

• SBOMs
• OpenSSF Scorecard
• Vulnerabilities
• Swagger and Readme
• License
• Helm Info
• Build Info
• Git repo
• Git commit (Branch and Tag)
• CD Build / Workflow Number
• Deployment Metadata

DevOps and security information is collected for all Components via the CI/CD pipeline. When your CD engine initiates a workflow for the Component, DeployHub Pro is called to determine that a new version of the Component is being pushed across the Pipeline. When a Component is updated, DeployHub Pro automatically updates all consuming Applications and creates a new logical Application Version. If a Component changes, the consuming Application also changes. Both get a new version number. For more information see Using DeployHub Pro with CI/CD.

DeployHub Pro uses a simple versioning number schema starting at 1 and incrementing over time, for example: Myapp;1, Myapp;2. .

You can use your DevOps Pipeline to include variance in your versioning number (base name, variant, version). See Step 2 - Create Your Component.toml File in the CI/CD Integrations.

The Component List View

Components are added to DeployHub Pro through the CI/CD process. Once added, the Component will be displayed in the Component list view. Use the Components List View accessible from the left hand Components menu option to view all of your available Components Versions. The list of all Components is organized by the following:

List Column	Description
Version	The Component Base Version or Component Version number.
Domain	The Domain to which the Component belongs.
Environment	The Environment to which the Component has been deployed. Each Environment will represent a different row in the List View table.
Deployment Log	The Deployment Log number with a link to the log.
Completed	The date and time of the last deployment to the listed Environment.
Results	Success or Fail.

You can also use the Filter bar, represented by a funnel icon, to reorder your Component List View:

• Domain
• Environment
• Last Deployment
• Parent
• Result
• Version

Additional Tabs from the Component List View

Menu Tab	Description
Refresh	Refreshes your screen.
Delete	Deletes the selected Component Version. To delete all, you must delete the Component Versions starting from the newest to the oldest. The Component Base Version would be deleted last. Sorting by “Version” gives you the order.
SBOM	Export your Component’s Software Bill of Materials report. Select the Component’s check box and click on the SBOM button to see your SBOM report.

Viewing a Component’s Security Details

Double click on a Component from the Component List to view and edit an individual Component’s security and DevOps details. The DeployHub Pro Dashboard displays all information related to a specific Component Version.

Viewing all Component Versions

You can view a list of all Component Versions by selecting the “Versions” button displayed after the Component’s name at the top of the DeployHub Pro Dashboard.

Comparing Two Component Versions

You can compare any two Component Versions by selecting the _Compare_button. You will be provided a list to select your second Component Versions for the comparison.

Security Posture Section

The first information you will see when viewing a Component is the Security Posture. DeployHub Pro gathers security insights created by open-source and commercial tools coming from organizations such as the OpenSSF, Continuous Delivery Foundation, OSV.dev, and Sonatype. When security tooling is added to your CI/CD pipeline, DeployHub Pro pulls the security information and maps it to the deployment locations providing real-time security insights for every software update, referred to as continuous security monitoring. By mapping the security data to release versions, and their deployed locations, DeployHub Pro gives you continuous insights into vulnerabilities long after your static CI/CD container scan was completed.

Note: Data from security tools can only be displayed if the tools are added to the CI/CD pipeline. To learn how DeployHub Pro can simplify this step view Setting up DeployHub Pro via the CLI.

Software Bill of Materials

DeployHub Pro consumes a Component’s Software Bill of Materials data as part of the CI/CD process. It can consume both SPDX and CycloneDX formats. DeployHub Pro presents the following SBOM summary information:

SBOM Element	Description
Package	The name of the package.
Version	The Package release number.
License	The license used by the Package.
OSSF Scorecard	When available, the OpenSSF Scorecard status for each package.

Note: SBOM information will only be displayed if SBOM usage is added to the CI/CD pipeline. To learn how DeployHub Pro can simplify this step view [the CI/CD chapter](/userguide/first-steps/2-intro-to-setting-up-DeployHub Pro/).

Real-Time Vulnerabilities

With the SBOM data, DeployHub Pro continuously monitors the vulnerabilities for the Component. Every 10 minutes, DeployHub Pro scans the OSV.dev distributed vulnerability database for the most recent vulnerabilities for the Component.

Vulnerability Element	Description
Package	The name of the package with the vulnerability.
Version	The vulnerable Package release number.
ID	The vulnerability ID with a link to the vulnerability description on OSV.dev.
Summary	A brief summary of the vulnerability

Note: Without the SBOM data, vulnerabilities cannot be traced.

OpenSSF Scorecard

OpenSSF Scorecard is a collection of security health metrics for open source packages. These metrics are critical as they allow consumers to evaluate the security posture before use. DeployHub Pro displays the OpenSSF score card information for the Component and all of the packages the Component consumes (displayed at the SBOM level).

OpenSSF Scorecard Element	Description
Score	The OpenSSF Scorecard assessment of the Component based on the metric.
Check	OpenSSF Scorecard executes a variety of metrics referred to as ‘checks.’ This column displays each of the metrics.

Note: OpenSSF score card information is only available when the package or Component Git repo has been added to gather the OpenSSF scorecard metrics. Learn how to add OpenSSF Scorecard from their Git Repo.

Readme

DeployHub Pro consumes the README text file found in the associated GitHub repo. The Readme section provides information about the Component and help users understand what the Component is about and how to use it.

License

DeployHub Pro consumes the license information from the GitHub repository associated to the Component. The full license is displayed.

Impact Assessment Section

When responding to vulnerabilities you must know how widespread the vulnerability is across your runtime environments. DeployHub Pro maps security data to DevOps data to provide an inventory of each Application who consumes Component.

Consuming Applications

The table shows you all of the Applications who are consuming this Component.

Field	Description
Application	The Application Version that consumes the Component Version.
Domain	The organizational level to which the Application belongs.
Environment	The artifact repository, or physical Environment where the Component’s consuming Application is running.
Deployment Log	The DeployHub Pro internal deployment number linked to the deployment log generated by the deployment tool.
Completed	The date/time stamp of when the Application Version was released.
Results	Shows if the deployment completed with a success or fail status.

Blast Radius

The Blast Radius shows a graphic representation of how many Applications are consuming the Component. You can scroll through the graphic image to see a full view of your Component’s use across the organization.

Swagger

As many Components are APIs, DeployHub Pro gathers the Swagger information. Swagger is important because it plays a crucial role in API development and documentation. Swagger helps design, build, document, and consume RESTful web services. If available, the Swagger information is displayed in this section.

Note: Automate the Readme, SBOM, License, and Swagger Upload via Your Pipeline. You can automatically upload you readme, SBOM, License, and Swagger data using the Command Line Interface (CLI) added to your pipeline. For more information review the CI/CD CLI details.

Component with DevOps Details Section

DeployHub Pro gathers both security insights and DevOps insights to provide a comprehensive view of a Component’s security posture. The DevOps details shows the owner of the Component, Build information, Helm and Git details, Key Value data, and DeployHub Pro deployment engine information if used.

Component Details

Field	Description
Full Domain	The fully qualified path of the Domain that the Component is to be associated, showing all parent Domains.
Name	The name of the _Component.
Description	A short text field with a description of the Component.
Component Owner	The owner of the Component, whose default value is the creator of the
Component Owner Email	The email of
Component Owner Phone	The phone number of the Component owner.
PagerDuty Business Service URL	Enter the address to the PagerDuty page that is associated to the business service for this Component.
PagerDuty Service URL	Enter the address to the PagerDuty page that is associated to the Component itself
Slack Channel	Enter what Slack Channel that can be used to report issues about this Component.
Discord Channel	Enter the Discord Invite Link you would like your consumers to use for this Component_.
HipChat Channel	Enter the HipChat Channel that can be used to report issues about this Component.

Build Details

When integrated with your CI/CD engine, DeployHub Pro tracks the DevOps data from the build including:

Field	Description
Build Date	The timestamp from when this build job was completed
Build ID	The ID of the CI/CD Workflow that created the Component.
Build URL	The URL to the CI/CD Workflow.
Container Registry	The Container registry where the Container is stored.
Container Digest	The SHA number of the Container image.
Container Tag	The tag that was assigned to the Container image.

Helm Details

Helm can be used for deploying Container Components. DeployHub Pro interfaces with Helm to support a Kubernetes Cluster deployment. Follow the steps at Helm for Container Deployments.

A Container Component has the following optional attributes:

Field	Description
Helm Chart	The Helm Chart used to deploy the Component.
Helm Chart Namespace	The sub-division of the Kubernetes cluster where your Component Container should run.
Helm Chart Repo	The repository used to store the Helm Chart, for example DockerHub, ArtifactHub.
Helm Chart Repo URL	Enter the URL to where the chart is located.
Helm Chart Version	The Helm Chart Version from the Helm Repository.

Git Details

The following Git information is gathered for each Component.

Field	Description
Git Commit	The Git SHA number. Populated when integrated into Continuous Delivery Pipelines.
Git Repo	The Git Repository that triggered the build.Populated when integrated into Continuous Delivery Pipelines.
Git Tag	The last tag for the Git Repository. Populated when integrated into Continuous Delivery Pipelines.
Git URL	The link for the Git Repo.

Deployment Engine

DeployHub Pro includes an agentless deployment engine, but can also integrate with external deployment tools. The following information is needed when configuring the internal DeployHub Pro engine for the Component.

Field	Description
Change Request Data Source	This Data Source is assigned to the Component for tracking Change Request. A Change Request Data Source must be pre-defined for this field to be used.
Category	Assigning a Category to an Object allows lists of Objects based on Categories to be used throughout DeployHub Pro. Add a new Category in the entry field or use an existing Category displayed in the drop down. Categories are most commonly associated with Actions, Functions and Procedures. Pre-defined Categories include: Build - Actions, Functions and Procedures for calling ANT (SalesForce integration). Database - Actions, Functions and Procedures for database updates. Deploy- Actions, Functions and Procedures for Deployments. Dropzone- Actions, Functions and Procedures for interacting with the Dropzone. File Logic- Actions, Functions and Procedures related to File manipulation. Flow Logic- Actions, Functions and Procedures for if then else in DMScript. Loops- Actions, Functions and Procedures for file looping. General-Non-categorized Objects (default). WebLogic- Actions, Functions and Procedures for deploying to WebLogic. WebSphere- Actions, Functions and Procedures for deploying to WebSphere. Windows- Actions, Functions and Procedures used for Windows deployments.
Always Deploy	The Component is deployed to the associated Endpoints in the Target Environment regardless if the Component is already present on the Endpoints. This is useful for monolithic applications where you want to copy over a binary for example.
Deploy Sequentially	Normally when a Component in an Application is deployed to several Endpoints in an Environment, it is deployed to each Endpoint at the same time (in parallel). The “Deploy Sequentially” option changes this behavior to force the Component to deploy to each Endpoint in turn, sequentially.
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.
Pre-Action	An Action that is to be run prior to the deployment of this Component. This can be used to perform prerequisite requirements, such as creating directories, creating files from scratch, or moving files between directories.
Post-Action	An Action that is to be run after the deployment of this Component. This can be used to execute actions on the target Endpoint after the Component has been deployed.
Custom Action	An Action that replaces the usual Deployment Engine processing. Custom Actions can be used to call Ansible, Helm or other external deployment tools.
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.
Target Directory	The directory under the Base Directory where the file will be deployed, or final “Target” Directory.
Repository	Choose the Repository that contains your Application binaries, files, etc. 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 a list of the Repositories See Connecting Your Repositories for more information. Filepath Override: Enter a filepath that will override the default filepath defined at the Repository level. Pattern Override: Enter a pattern that will override the default pattern defined at the Repository level. Patterns are file types you want to pull from the Repository, such as *.exe, *.dll, *.war. Recursive Override: Select the box in order to override the default recursive behavior defined at the Repository level. This will turn recursion on or off depending on the setting at the Repository level. Version Override: Overrides the default template of your versioning pattern defined at the Repository level.

Key Value Configurations

Key Value pairs are stored for any configuration setting that needs to be persisted with the version of the Object. For example, pairs can be used to store issue numbers from Jira or GitHub issues with the Component Version and/or Applications Version.

For users of the DeployHub Pro internal deployment engine, Key Value pairs can be stored by DeployHub Pro and referenced during a deployment.

Key Value pairs can be assigned at multiple levels, from the Global Domain down to an individual Component and have a “scope.” Lower level Objects can override a higher level Object. Below is the order in which Key Value Pairs can be overridden:

Object	Description
Global	Contains all Environment variables and any “additional Key Value Pairs” set by the user when running that task.
Environment	Overrides any Global Key Value Pairs during a deployment.
Application	Overrides the Environment Key Value Pairs during a deployment.
Endpoint	Overrides the Application Key Value Pairs during a deployment.
Component	Overrides the Application Key Value Pairs during a deployed.

Key Value Pairs can be given any Name and a Value. Use +Add to add Key Value Pairs to the table. Use Save to confirm. Use the checkbox to Delete or Edit a Key Value Pair.

Audit Trail

The Audit Trail displays audit entries for any changes that impact this Object.

• Comment: Click on ‘Comment’ to add information. There is a field above the list labeled “Say something about this Object” that can have written comments placed into it, or files can be attached to the comment. Entering text into this field activates the Add Message button. Click to save the comment as a line in the list.

• Add Files to Comments: Click on the paperclip icon to add a file to the message. Once done, click on the “Add Message” button. These attachments can later be retrieved by clicking on the paperclip icon which then displays the name of the file within a list. Choose the file to download it into the your default Download directory on your local computer.

Deployment Audits

For deployment audits, select a deployment number to see the details including:

Access	Description
Log	The output of the deployment.
Files	Any files or objects deployed.
Step Duration	Deployment Steps with time required to execute.
Feedback Loop	Shows what was updated starting from Component.

When using the internal DeployHub Pro deployment engine, all log output is automatically persisted with the Application Version and Component Version.

If you are using another deployment solution, you can persist the log via the CI/CD workflow. The output from the deployment can be passed to the CLI to be persisted with the Application Version and Component Versions. Learn more about the CI/CD CLI Integration

Access Section

The Access Section allows Users within designated Groups to update or view the Component. 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 that appear in one of the Access lists will be granted access to the Component:

Access	Description
View	This allows any User that belongs to any Group in this list to see the selected Component in the List View.
Change	This allows any User that belongs to any Group in this list to make changes to the Component.