Using the Vulnerability dimension
The Vulnerability dimension helps you identify, prioritize, and remediate Common Vulnerabilities and Exposures (CVEs) and non-CVE exposures across your applications and environments. Based on ingested vulnerability scan data and your configured vulnerability priority and risk score settings, Concert assesses and prioritizes vulnerabilities so you can focus remediation efforts on the issues that pose the greatest risk.
Concert also supports remediation workflows through automated remediation actions, proactive vulnerability alerts, IDE-based remediation capabilities, and integration with external ticketing systems.
The Vulnerability dimension supports applications that are automatically discovered from source code repositories. Vulnerability findings are correlated across shared repositories, build artifacts, and runtime environments, enabling consistent risk visibility across related application components.
Before you begin
- Define applications and environments in your Concert instance to assess and prioritize vulnerabilities in context of your application topology.
- The following definitions apply to repository and build artifact management:
- Correlated: Any version or instance of a repository or build artifact that is related to an application or environment is considered correlated.
- Uncorrelated: Any version or instance of a repository or build artifact that is not related to an application or environment is considered uncorrelated.
Note: Correlated and uncorrelated repository and build artifacts can be viewed under the Correlated and Uncorrelated tabs in the and , respectively.Vulnerability data is initially displayed based on correlated repositories, build artifacts, and environments. If an application is updated to remove an associated repository or build artifact, the related vulnerability findings continue to appear until the uncorrelated artifacts and their associated findings are explicitly deleted.
- You must have object-level access to an application or environment to view its associated vulnerability data. This includes instance-level Admin users since access to individual objects must be granted explicitly.
The following steps overview the core steps in using the Vulnerability dimension to highlight and prioritize CVEs and non-CVE exposures impacting your application components, environments, and public access points.
Step 1: Reviewing CVE priority and risk score settings
- To adjust vulnerability settings globally, go to .
- To adjust vulnerability settings for each application, go to , click the name of the application, and then click the Settings tab.
From either of these pages, you can assign weights to individual risk score factors (IBM risk score, CVSS score, and/or a custom score) to adjust the way Concert calculates risk score for each identified CVE. You can also adjust the risk score ranges for each priority level. For example, if you have a high number of prioritized CVEs, you can increase the minimum value for the Priority 1 range to reduce the number of prioritized CVEs in focus.
Step 2: Importing vulnerability scans
Concert ingests Vulnerability scan data from your existing third-party tools such as Prisma Cloud, Aqua Security, Sysdig or other vulnerability scanning tool. You can import scan data manually or automate the ingestion process.
Manual scan upload
Generate a vulnerability scan file in one of the Concert supported formats, then upload the file to Concert to assess and prioritize CVEs or non-CVE exposures impacting your applications and environments.
For details about supported formats, see Supported vulnerability scan formats.
For upload instructions, see Upload a vulnerability scan.
Automated scan ingestion
Configure Concert Workflows to automatically import vulnerability scans from your scanning tools, enabling continuous vulnerability monitoring without manual intervention.
For more information, see Importing scans using Concert Workflows.
Proactive vulnerability alerts
Enable proactive vulnerability management to receive early warnings about vulnerable packages directly in GitHub pull requests as soon as new commits are added. This enables you to identify and address vulnerable packages earlier in the development lifecycle.
For more information, see Proactive vulnerability management alerts.
Step 3: Reviewing vulnerability data
- From the Vulnerability page (), you can view a detailed list of CVEs and non-CVE exposures.
CVEs
- The CVEs page provides a summary of CVEs impacting your applications, as well as a table containing details about each identified CVE including its severity, CVSS score, number of open findings, the highest priority instance (finding) of the CVE and the risk score of that specific finding. Click the name of the CVE to view more details, including its individual blast radius in the topology view.
Note: For CVEs, you can set the following Assessment state based on your assessment:
- Unassessed
- Assessment in progress
- False positive
- Exception requested
- Exception approved - Only users with Admin and Manager access roles are able to perform this action
- Fix in progress
- Closed
Additionally, you can update Assessment custom details such as Effort, Comments, Guidance and Complexity through API.
Exposures- The Exposures page provides a summary of non-CVE exposure data; including the number of exposures found and the top priorities. It also includes a table containing details about the rules with which the scan detected a finding or deviation from the expected behavior. Expand each row to view details about each rule.
- The CVEs page provides a summary of CVEs impacting your applications, as well as a table containing details about each identified CVE including its severity, CVSS score, number of open findings, the highest priority instance (finding) of the CVE and the risk score of that specific finding. Click the name of the CVE to view more details, including its individual blast radius in the topology view.
- From the Arena view, you can use the toggles to show or hide Priority 1 CVEs and Priority 1 exposures vulnerability data in your application topology view. When enabled, you can see the specific components impacted by each vulnerability and hover over the vulnerability node to highlight the dependencies.
- From the Applications page (), you can click the name of an application definition, repository, or build artifact to view the specific CVEs impacting it.
Use any of these methods to quickly assess and take action against the vulnerabilities associated with your applications as this informs your overall security and risk posture.
Step 4: Remediating vulnerabilities
Concert provides multiple approaches to remediate identified vulnerabilities, enabling you to choose the most appropriate method based on your environment and workflow.
Automated remediation workflows
Configure Concert Workflows to automatically detect vulnerabilities, generate AI-assisted remediation actions powered by IBM watsonx.ai, and apply patches across supported operating systems, web servers, and container environments. This end-to-end automation reduces manual effort and accelerates vulnerability resolution.
For more information, see Auto-remediation using Concert Workflows.
IDE-based remediation
Use the IBM Concert extension for Visual Studio Code (VS Code) to remediate code vulnerabilities and upgrade vulnerable dependencies directly in your development environment using AI-generated recommendations. This approach enables developers to fix vulnerabilities as they write code, before issues reach production.
For installation and usage instructions, see Remediate vulnerabilities with the Concert IDE plugins (VS Code extension).
Manual ticket creation
As you review impacting CVEs and non-CVE exposures, you can open tickets directly in the Concert UI to populate your connected external ticketing system. Alternatively, you can create an automation rule to automatically create a ticket in the external system whenever Concert identifies a prioritized CVE. Both methods require you to establish a connection with your external issue tracking system, such as GitHub, Jira, ServiceNow and Salesforce.
For details, see Opening tickets to address vulnerabilities.