Portfolio compliance reports

Portfolio compliance reports give an aggregated view of how the projects in your portfolio measure 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

Portfolio compliance reports are aimed at enterprise security teams, compliance and audit teams, and IT administrators who manage multiple projects and need an organization-wide view of their compliance status. The results come from the projects included in the portfolio. Unlike project compliance reports, portfolio compliance reports cannot be downloaded.

To see the compliance report of a single project branch, see Project compliance reports.

Retrieving portfolio compliance reports

Go to your portfolio > Compliance reports. See Viewing portfolios for how to find your portfolio.
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 portfolio 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 portfolio 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 the projects in your portfolio. 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, the projects in your portfolio 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 portfolio 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 projects' 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 portfolio compliance reports in the SonarQube Cloud UI. 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

Portfolio compliance reports are based on the active rules in the quality profiles of the projects in your portfolio. To check which compliance rules a project's quality profile includes, see Checking compliance rules included in a project’s quality profile.

PreviousViewing portfolios

NextViewing portfolio PDF reports

Last updated 6 days ago

Was this helpful?