Findings

The Security and risk management findings page displays a filtered list of findings. By default, you are shown the findings that are currently opened and this list is sorted by Latest findings found. You can click on the sort dropdown to sort the findings by detection date - latest or oldest. Use this page to review and prioritize findings and track the progress of your security efforts.

To access the findings page, access the overview page and click the Findings tab.

On the left section of the page, besides sorting, you can update the filtering criteria by clicking the Segments , Repositories, Severities, Statuses, Security categories, or Scan types dropdowns above the list.

Check out how to enable and configure Segments

On the right section, you can view the filtered list of findings. Each finding card offers a quick overview of the vulnerability found, including its title, source platform, scan type, security category, and related information such as the repository name, Jira issue key, or affected URL targets. To find out more, click this overview to navigate to the finding details on the source platform.

Dependency chain

For findings on transitive dependencies, the finding also displays the dependency chain: the ordered path from a direct (top-level) dependency in your manifest down to the vulnerable package (for example, direct-package → intermediate-package → vulnerable-package). This helps you identify which of your direct dependencies you need to update to resolve the finding.

Affected functions

For vulnerable dependency and container scanning findings linked to an advisory (a CVE or a GitHub Security Advisory) where Codacy has identified which functions in the dependency are affected, the finding's Advisory Information tab shows the list of affected functions.

Click Check if you're affected to copy a ready-made prompt for your AI coding assistant (such as Cursor, Claude Code, or GitHub Copilot). The prompt asks your assistant to search your repository for calls to the affected functions and recommend whether to upgrade the dependency or, if the functions aren't used, ignore the finding as Not exploitable.

Note

This is a signal, not a guarantee. Review your coding assistant's findings before upgrading a dependency or ignoring a finding.

Note

Not every advisory lists specific affected functions—some vulnerabilities (for example, configuration issues) aren't tied to specific functions, so this section doesn't appear for every finding.

Affected functions are also available from the terminal—see checking affected functions with the Codacy Cloud CLI.

To review reachable dependencies across one or multiple repositories at once, instead of one finding at a time, see auditing affected functions across one or multiple repositories with the Codacy Cloud CLI.

Severity changes

The same Common Vulnerability and Exposure can be classified with different severities in different sources, like cve.org or NVD, and Trivy uses these and other sources to update their database. As such, there may be situations where the severity attributed to a Finding by Trivy isn't in line with a specific source. Subsequent analysis can then close a Finding and re-open it with a different severity, if a Trivy database update occurs.

Sharing a filtered view of findings

To share the current view of the overview or findings page, click the Copy URL button in the top right-hand corner of the page. This action copies the URL with the current filters applied to the clipboard.

Segments filter won't be considered when sharing the filtered view

Ignoring findings

This feature is available only to organization admins and organization managers except for findings detected on Git repositories. For those findings, repository permissions are respected

You can ignore a finding using the context menu both in the findings list page and the findings details page. When ignoring a finding you can optionally specify a reason for doing so.

From an organization standpoint, ignoring a finding means that you accept the risk it poses and you're not planning on addressing the issue.

From Codacy's standpoint, ignoring a finding means it will be removed from the metrics featured in the overview page. Note that the Open Findings history chart will only be changed at the start of next week.

Jira findings can't be ignored in Codacy. You should closed the issue directly in Jira.

Ignoring findings detected on Git repositories will also ignore the issue at the repository level.

You can still see Ignored findings in the findings list, by filtering for the Ignored status in the Statuses dropdown. You can assess which status a finding has at his overview, on the right top corner.

An Ignored finding can be unignored directly from the findings list or by going to the same menu in the finding details page. Note that in this page you can also find out more about who ignored the finding and why, if such a reason was provided.

Unignoring a finding reverts the effects of ignoring it.

Unignoring findings detected on Git repositories will also unignore the issue at the repository level.

Ignoring and unignoring findings are auditable actions.

Exporting findings

This feature is available only to organization admins and organization managers

To export a list of findings as a CSV file, click the options menu in the top right-hand corner of the page and select Export findings (.csv). The exported list always includes all findings, ignoring any applied filters.

Reviewing severity rules and integration settings

To review the severity assignment rules or manage the integration with Jira or Slack, click the options menu in the top right-hand corner of the page and select respectively See severity rules or View integrations.

How Codacy manages findings

Important

To open and close findings, Codacy must detect when the associated issues are introduced and fixed. The detection logic is platform-dependent and is described below.

Codacy opens a new finding whenever a source platform detects a new security issue. The new finding is automatically assigned a severity and a status:

• The priority of the issue on the source platform sets the severity of the finding. In turn, the severity of the finding defines a deadline to close the finding.
• The time to the deadline sets the status of the finding. The finding then moves through different statuses as the deadline is approached, met, or missed.

Codacy closes a finding when the source platform stops detecting the associated security issue.

The following section details when Codacy opens and closes findings for each supported platform.

How Codacy manages findings detected on Git repositories

Note

To make sure that Codacy detects security issues correctly:

• Enable code patterns belonging to the Security category. These patterns are enabled by default, but may not be on custom configurations.
• Alternatively, apply a coding standard that includes patterns belonging to the Security category.
• Confirm that the latest commits to the default branches of your repositories are analyzed.

Codacy opens a new finding when it detects a new security issue on the default branch of a repository.

Codacy closes a finding in either of the following cases:

• Codacy detects that the associated issue isn't present in the most recent analyzed commit and therefore is fixed
• You ignore the associated issue
• You disable the tool that found the associated issue

Important

Deleting a repository deletes all open findings belonging to that repository.

How Codacy manages findings detected during software composition analysis (SCA)

SCA findings behave like other Git repository findings. Codacy opens a finding whenever a commit to the default branch is analyzed and a vulnerable dependency is detected, and closes it when the dependency is no longer detected.

On the Business plan, Codacy also runs daily re-scans across all repositories—so newly discovered vulnerabilities are surfaced even without a new commit. Talk to us if you're interested in upgrading.

How Codacy manages findings detected on Jira

Note

• For Codacy to detect Jira issues, you must integrate Jira with Security and risk management.
• Codacy retrieves updates from Jira once a day. If an issue is opened and closed on the same day, Codacy may not detect it.
• To make sure that Codacy detects Jira issues correctly, assign the security label when creating the issue or immediately after.

Codacy opens a new finding when it detects a new Jira issue with a security label (case-insensitive).

Codacy closes a finding when it detects that the associated Jira issue is marked as Closed.

How Codacy manages findings detected during penetration testing

Note

Penetration testing is available upon request and is provided by a third-party partner. See how to request penetration testing for your organization.

Codacy opens a finding for each security issue detected during a penetration test.

Codacy closes a finding when a subsequent penetration test doesn't detect the underlying security issue.

How Codacy manages findings detected during application scanning (DAST)

Note

To view application scanning findings, also known as DAST (Dynamic Application Security Testing) findings, you must first generate a DAST report and upload it to Codacy.

Codacy opens a finding for each security issue detected in the DAST report. If subsequent reports identify the same issue, Codacy updates the existing finding.

Codacy closes a finding when it's not detected in a subsequent DAST report. If a previously closed issue reappears in a later report, Codacy reopens the finding.

Finding severities and deadlines

The following table defines finding severities and the default number of days to the deadline to fix the associated security issue, based on the importance of the underlying issue:

Finding severity	Days to deadline	Underlying Codacy issue severity	Underlying Jira issue priority 1
Critical	30	Critical	Highest
High	60	-	High
Medium	90	Medium	Medium
Low	120	Minor	Low and other/custom

¹ Those listed are the default Jira priority names. If you rename a default Jira priority, it keeps the correct mapping.

Customize deadlines

This feature is available only to organization admins and organization managers.

You can configure your findings deadline by clicking on the "Configure SLAs" button, on the right corner of the page.

In the open configuration modal you'll be able to input your deadline preferences for each severity. Each deadline must be between a minimum of 1 day and a maximum of 9999 days.

As soon as changes are saved, your open findings statuses will be updated accordingly. You are also able to reset to Codacy default deadline values (see table above) at any time.

Finding statuses

The following table describes how finding statuses map to deadlines:

Status category	Finding status	Deadline
Open	Overdue	The deadline has been missed
	Due soon	Fewer than 15 days to the deadline
	On track	15 days or more to the deadline
Closed	Closed late	Closed after the deadline
	Closed on time	Closed before the deadline

Was this page helpful?

Your feedback helps us improve the documentation.

Yes No

Edit this page on GitHub Contact support