Managing security and risk#
The Security and risk management feature helps you quickly identify, track, and address security across your organization by automatically opening time-bound, prioritized findings whenever security problems are detected in your organization repositories, in your connected Jira instance, or as a result of penetration testing.
Under Security and risk management, you can find the following pages to help you monitor the security of your repositories:
In addition, on these pages, you can share filtered views of findings, export findings as a CSV file, and review severity rules and integration settings
Overview#
The Security and risk management overview page provides a high-level view of the security posture of your organization, including the number of open findings, the distribution of open findings by severity, the history of finding resolution, and a breakdown of the most high-risk repositories and most detected security categories.
Use this page to assess your organization's security posture and its progress over time, identify areas for improvement, and share findings with stakeholders.
To access the overview page, select an organization from the top navigation bar and select Security and risk on the left navigation sidebar.
The overview page includes six panels:
- Open findings overview
- Open findings distribution
- Open findings history
- Activity history
- Top 10 high-risk repositories
- Top 10 common security categories
To limit the information displayed in each panel to a specific set of repositories, use the filter drop-down above the main area.
Open findings overview#
The Open findings overview panel displays the total number of open security findings and the number of findings of each severity, helping you quickly assess the overall security posture of your organization and quickly review findings that are critical or overdue.
To access the findings page with the corresponding filter applied, click on a number.
Open findings distribution#
The Open findings distribution panel shows the relative distribution of open findings by scan kind, severity, or status, helping you evaluate the distribution of risk across different scan kinds and identify areas that may need immediate attention.
To select the desired distribution, use the drop-down in the top right-hand corner of the panel.
To access the findings page with the corresponding filter applied, click on a number.
Open findings history#
The Open findings history graph shows the open findings trends over the past three months, grouped by week and severity. It details the progression of your organization's risk and security posture over time and can, for example, help you understand if the right issues are being addressed.
For a detailed view of the distribution on a specific week, hover over the graph.
Activity history#
The Activity history graph shows weekly counts of open and closed findings over the past three months, overlaid on the overall open findings trend. It complements the Open findings history graph with more information, such as the volume of findings addressed each week and a visual representation of the new/closed ratio.
For a detailed view of the counts on a specific week, hover over the graph.
Top 10 high-risk repositories#
The Top 10 high-risk repositories list shows the repositories with the highest number of open findings, ordered by severity.
Note
This panel may list fewer than ten repositories if there are fewer than ten repositories with open findings in the organization or if fewer than ten repositories are selected in the dropdown Repository filter.
Top 10 common security categories#
The Top 10 common security categories list shows the most common security categories of open findings, ordered by count.
To access the findings page with the corresponding filter applied, click on a category.
Findings#
The Security and risk management findings page displays a filtered list of findings. By default, this list is sorted by status, and you can click the First detected column name to sort the findings by the detection date. 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.
When viewing the findings, you can update the filtering criteria by clicking the Severity, Status, Repository, or Security category drop-downs above the list.
To find out more about a finding in the list, click its Details column to navigate to the finding details on the source platform.
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.
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 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 new finding when penetration testing results are published by our partner.
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 |
Finding severities and deadlines#
Note
Currently, Codacy doesn't support customizing the severity rules for security findings.
The following table defines finding severities and days to fix the associated security issue, based on the importance of the underlying issue:
| Finding severity |
Days to fix |
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 |
1 Those listed are the default Jira priority names. If you rename a default Jira priority, it keeps the correct mapping.
Languages checked for security issues#
Security and risk management supports checking the languages and infrastructure-as-code platforms below for any Codacy security issues reported by the corresponding tools:
| Language | Tools that report security issues |
|---|---|
| Apex | PMD, Semgrep 1 |
| AWS CloudFormation | Checkov, Trivy 2 |
| C | Clang-Tidy 3, Cppcheck, Flawfinder, Semgrep 1, Trivy |
| C# | SonarC#, Semgrep 1, Trivy |
| C++ | Clang-Tidy 3, Cppcheck, Flawfinder, Semgrep 1, Trivy |
| Dart | Trivy |
| Dockerfile | Hadolint, Semgrep 1, Trivy |
| Elixir | Credo, Trivy |
| GitHub Actions | Semgrep 1 |
| Go | Gosec 3, Semgrep 1, Trivy |
| Groovy | CodeNarc |
| Helm | Trivy 2 |
| Java | Semgrep 1, SpotBugs 3 4, Trivy |
| JavaScript | ESLint 5, Semgrep 1, Trivy |
| JSON | Trivy |
| Kotlin | Semgrep 1 |
| Kubernetes | Trivy 2 |
| Objective-C | Clang-Tidy 3 |
| PHP | PHP_CodeSniffer, PHP Mess Detector, Semgrep 1, Trivy |
| PowerShell | PSScriptAnalyser |
| Python | Bandit, Prospector, Pylint, Semgrep 1, Trivy |
| Ruby 6 | Brakeman, RuboCop, Semgrep 1, Trivy |
| Rust | Semgrep 1, Trivy |
| Scala | Codacy Scalameta Pro, Semgrep 1, SpotBugs 3 4 |
| Swift | Semgrep 1 |
| Shell | ShellCheck Semgrep 1 |
| Terraform | Semgrep 1, Trivy |
| Transact-SQL | TSQLLint |
| TypeScript | ESLint 5, Semgrep 1, Trivy |
| Visual Basic | SonarVB |
1: Semgrep supports additional security rules when signing up for Semgrep Pro.
2: Currently, Trivy only supports scanning YAML files on this platform.
3: Supported as a client-side tool.
4: Includes the plugin Find Security Bugs.
5: Includes the plugins no-unsanitized, security, security-node, and xss.
6: Currently, Codacy doesn't support any static code analysis tool for Ruby 3.1.
Supported security categories#
Note
Due to a recent update, some issues may be temporarily assigned the Not yet categorized category. To categorize these issues, you can reanalyze the default branch of the relevant repository. For a list of repositories that have issues with this category, use the Security category filter on the Findings page.
Each Codacy issue reported by Security and risk management belongs to one of the following security categories:
| Security category | Description |
|---|---|
| Android | Android-specific security issues. |
| Authentication | Broken authentication and authorization attacks consist in gaining access to accounts that allow disclosing sensitive information or performing operations that could compromise the system. |
| Command Injection | Command injection attacks aim to execute arbitrary commands on the host operating system. |
| Cookies | Security issues related to insecure cookies. |
| Cryptography | Cryptography attacks exploit failures related to cryptography (or lack thereof), potentially leading to exposure of sensitive data. |
| CSRF | Cross-Site Request Forgery (CSRF) attacks force an end user to execute unwanted actions on a web application in which they're currently authenticated. |
| Denial of Service | Denial of Service (DoS) attacks make a resource (site, application, server) unavailable for legitimate users, typically by flooding the resource with requests or exploiting a vulnerability to trigger a crash. |
| File Access | File access security issues may allow an attacker to access arbitrary files and directories stored on the file system such as application source code, configuration, and critical system files. |
| HTTP Headers | Insecure HTTP headers are a common attack vector for malicious users. |
| Input Validation | Client input should always be validated to prevent malformed or malicious data from entering the workflow of an information system. |
| Insecure Modules and Libraries | Security issues related to modules or libraries that can potentially include vulnerabilities. |
| Insecure Storage | Security issues related to insecure storage of sensitive data. |
| Malicious Code | Security issues related to code patterns that are potentially unsafe. |
| Mass Assignment | Unprotected mass assignments are a Rails feature that could allow an attacker to update sensitive model attributes. |
| Regex | Regular expressions can be used in Denial of Service attacks, exploiting the fact that in most regular expression implementations the computational load grows exponentially with input size. |
| Routes | Badly configured routes can give unintended access to an attacker. |
| SQL Injection | SQL injection attacks insert or "inject" malicious SQL queries into the application via the client input data. |
| SSL | Security issues related with old SSL versions or configurations that have known cryptographic weaknesses and should no longer be used. |
| Unexpected Behaviour | Security issues related to potentially insecure system API calls. |
| Visibility | Logging should always be included for security events to better allow attack detection and help defend against vulnerabilities. |
| XSS | Cross-Site Scripting (XSS) attacks inject malicious client-side scripts into trusted websites that are visited by the end users. |
| Other | Other language-specific security issues. |
Share your feedback 📢
Did this page help you?
Thanks for the feedback! Is there anything else you'd like to tell us about this page?
255 characters left
We're sorry to hear that. Please let us know what we can improve:
255 characters left
Alternatively, you can create a more detailed issue on our GitHub repository.
Thanks for helping improve the Codacy documentation.
Edit this page on GitHub if you notice something wrong or missing.
If you have a question or need help please contact support@codacy.com.