Project compliance reports

Compliance reports show how your project's code measures up against security-focused, regulatory, and accessibility standards.

To simplify the classification of findings, we are gradually transitioning security hotspots to vulnerabilities. As a result, rules that previously raised security hotspots will start raising vulnerabilities (type) or security issues (software quality).

This feature is only available in the Enterprise plan.

Before you can view the Enterprise-level reports, your organization must be added to an enterprise. For more information, see Managing your enterprise.

Introduction

A project compliance report covers the main branch or another long-lived branch of your project. For each supported standard, it shows the findings from your latest analysis that relate to that standard, so security, compliance, and audit teams can track the project against the standards they must meet.

To see the same standards aggregated across several projects, see Portfolio compliance reports.

Compliance reports are different from project regulatory reports, which are downloadable ZIP snapshots of a branch for audit and governance purposes. See Viewing project regulatory reports for details.

Retrieving project compliance reports

Go to your project > Reporting > Compliance reports. See Retrieving projects for how to find your project.
Select the main branch or another long-lived branch.
In Browse by standard type, select a standard type to filter the list of standards: All standards, Security-focused, Regulatory, or Accessibility.
Select a standard for which you want to view the report.
The report is generated on the right side of the screen.

Standards

The compliance reports page groups the supported standards into three types: security-focused, regulatory, and accessibility. Select All standards to list every standard, or select a type to show only the standards of that type.

Security-focused

Security-focused standards help you understand where you may have issues related to industry security frameworks. The project compliance report covers the following security-focused standards:

OWASP Top 10 (versions 2025, 2021, 2017)

OWASP Top 10 security standards covered by Sonar for version 2025

Regulatory

Regulatory standards come from laws, regulations, and industry bodies that set requirements for particular markets or types of products. The project compliance report covers the following regulatory standards:

EU Cyber Resilience Act (CRA): the European Union regulation that sets cybersecurity requirements for products with digital elements placed on the EU market. It's maintained by the European Commission. For details about how SonarQube features map to the CRA requirements, see Cyber Resilience Act capability mapping.

EU Cyber Resilience Act security standards covered by Sonar security features

Requirement

Security

Dependency Risks

Part I - Cybersecurity requirements relating to the properties of products with digital elements

(partial)

1.1 Risk-Based Security Standards for Digital Products

1.2 Security Obligations Derived from Risk Assessments

1.2.a be made available on the market without known exploitable vulnerabilities

1.2.b be made available on the market with a secure by default configuration, unless otherwise agreed between manufacturer and business user in relation to a tailor-made product with digital elements, including the possibility to reset the product to its original state

1.2.c ensure that vulnerabilities can be addressed through security updates, including, where applicable, through automatic security updates that are installed within an appropriate timeframe enabled as a default setting, with a clear and easy-to-use opt-out mechanism, through the notification of available updates to users, and the option to temporarily postpone them

1.2.d ensure protection from unauthorised access by appropriate control mechanisms, including but not limited to authentication, identity or access management systems, and report on possible unauthorised access

1.2.e protect the confidentiality of stored, transmitted or otherwise processed data, personal or other, such as by encrypting relevant data at rest or in transit by state of the art mechanisms, and by using other technical means

1.2.f protect the integrity of stored, transmitted or otherwise processed data, personal or other, commands, programs and configuration against any manipulation or modification not authorised by the user, and report on corruptions

1.2.g process only data, personal or other, that are adequate, relevant and limited to what is necessary in relation to the intended purpose of the product with digital elements (data minimisation)

1.2.h protect the availability of essential and basic functions, also after an incident, including through resilience and mitigation measures against denial-of-service attacks

1.2.i minimise the negative impact by the products themselves or connected devices on the availability of services provided by other devices or networks

1.2.j be designed, developed and produced to limit attack surfaces, including external interfaces

1.2.k be designed, developed and produced to reduce the impact of an incident using appropriate exploitation mitigation mechanisms and techniques

1.2.l provide security related information by recording and monitoring relevant internal activity, including the access to or modification of data, services or functions, with an opt-out mechanism for the user

1.2.m provide the possibility for users to securely and easily remove on a permanent basis all data and settings and, where such data can be transferred to other products or systems, ensure that this is done in a secure manner

Part II - Vulnerability handling requirements

2.1 identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products

2.2 in relation to the risks posed to products with digital elements, address and remediate vulnerabilities without delay, including by providing security updates; where technically feasible, new security updates shall be provided separately from functionality updates

2.3 apply effective and regular tests and reviews of the security of the product with digital elements

2.4 once a security update has been made available, share and publicly disclose information about fixed vulnerabilities, including a description of the vulnerabilities, information allowing users to identify the product with digital elements affected, the impacts of the vulnerabilities, their severity and clear and accessible information helping users to remediate the vulnerabilities; in duly justified cases, where manufacturers consider the security risks of publication to outweigh the security benefits, they may delay making public information regarding a fixed vulnerability until after users have been given the possibility to apply the relevant patch

2.5 put in place and enforce a policy on coordinated vulnerability disclosure

2.6 take measures to facilitate the sharing of information about potential vulnerabilities in their product with digital elements as well as in third-party components contained in that product, including by providing a contact address for the reporting of the vulnerabilities discovered in the product with digital elements

2.7 provide for mechanisms to securely distribute updates for products with digital elements to ensure that vulnerabilities are fixed or mitigated in a timely manner and, where applicable for security updates, in an automatic manner

2.8 ensure that, where security updates are available to address identified security issues, they are disseminated without delay and, unless otherwise agreed between a manufacturer and a business user in relation to a tailor-made product with digital elements, free of charge, accompanied by advisory messages providing users with the relevant information, including on potential action to be taken

MISRA C++:2023: guidelines for the use of C++ in safety-critical and mission-critical systems, published by The MISRA Consortium Limited. The report groups issues by the guideline categories defined in MISRA Compliance:2020: mandatory, required, and advisory.

When you select MISRA, the report displays the number of MISRA issues to address and a table with the Classification and Issues columns. The results are based on the relevant active MISRA rules in the quality profiles of your project. Each classification combines a guideline category with a guideline type (directive or rule):

Advisory directives
Advisory rules
Mandatory directives
Mandatory rules
Required directives
Required rules

For MISRA results to appear, your project must include C/C++ code and use a C/C++ quality profile with MISRA rules activated. Select one of the Sonar MISRA compliance quality profiles or activate MISRA rules in a custom C/C++ quality profile, then run a new analysis. See The Sonar MISRA compliance quality profiles for more information.

MISRA and MISRA C are the registered trade marks of The MISRA Consortium Limited.

Accessibility

Accessibility standards help you check that the user interfaces you build can be used by people with disabilities. The project compliance report covers the following accessibility standard:

WCAG (versions 2.0, 2.1, and 2.2, each at Level A, Level AA, and Level AAA): the Web Content Accessibility Guidelines, published by the World Wide Web Consortium (W3C). The conformance levels build on each other: Level A is the minimum and Level AAA is the highest.

When you select a WCAG version and level, the report displays a table with the Categories and Issues columns. The categories are the four WCAG principles:

Perceivable
Operable
Understandable
Robust

Each principle contains guidelines and success criteria. For the full list, see the WCAG standards and guidelines published by the W3C.

Dependency Risks in security reports

Dependency Risks are the security and compliance problems SonarQube detects in your project's open source and third-party dependencies through Software Composition Analysis (SCA). They include known vulnerabilities such as CVEs, malicious packages, and dependencies that use a prohibited license.

Dependency Risks ratings are included in SonarQube security reports in both the SonarQube Cloud UI and exported PDFs. To view Dependency Risks, you need access to SonarQube Advanced Security. See the Subscribing to the Advanced Security product article for signup instructions.

Checking compliance rules included in a project’s quality profile

Go to your project > Project > Project information.
Under Quality profiles used, select a quality profile to open it.
Once on the quality profiles page, select the active Security rules from the Software qualities table’s Active column. The Rules page opens.
In the left-side panel of the Rules page, scroll to the Compliance category and filter the results by specific standards to view the compliance categories covered by code review and analysis.

The Rules page with the Compliance Category filter expanded, listing standards such as EU CRA, PCI DSS, OWASP ASVS, and OWASP Top 10.

Downloading a Security report (PDF)

As a member of a security or compliance team, you can generate and download project security reports in a PDF format for any given branch.

Go to your project > Reporting > Compliance reports.
Select the main branch or another long-lived branch.
In the top right corner of the page click Download Security report (PDF).

Download options

The following download options are available:

Default: Includes Sonar, OWASP top 10 2025 and CWE TOP 25 2024 security standards.
Custom: Choose from a list of all security standards used by SonarQube.

Contents of the PDF Report

A Security Overview page that includes:

Project and branch information
The number of open Security issues, Security Hotspots, and Accepted Security issues on new code and overall code.
Overall code security ratings for Security issues and Security Hotspots, including the percentage of reviewed Security Hotspots

A report for a given standard that includes:

A list of categories for Security issues and Security Hotspots
Number of issues to address and their relevant rating per category
Breakdown by severity (Blocker, High, Medium, Low, Info)
Hotspots that need review

PreviousIntroduction

NextViewing project regulatory reports

Last updated 3 days ago

Was this helpful?