SonarQube in the Service of Code Security

SonarQube in the service of code security — compliance with the requirements of Act LXIX of 2024.

2025.04.24

Introduction

Alongside the explosive growth of digital services, increasing emphasis is being placed on the security, reliability and regulated development of software. Legislators are following this trend too: Act LXIX of 2024 (the Hungarian Cybersecurity Act on the cybersecurity of Hungary) — the Hungarian transposition of the NIS2 Directive — has raised the security requirements for IT systems to a new level, with particular regard to development and code quality. The new regulation also extends to areas that were previously the internal responsibility of development teams. Guaranteeing the security of source code, identifying and documenting risks, and making development processes transparent are no longer merely a professional minimum but also a legal requirement. In this environment, static code analysis becomes crucial as one of the most effective tools of preventive risk management. SonarQube — one of the best-known open-source code analysis platforms — effectively supports development teams in achieving legal compliance. The aim of this article is to show, from a practical point of view, how SonarQube can be used to meet the requirements of Act LXIX of 2024 and how it can be built seamlessly into the everyday development lifecycle.

The Essence of Act LXIX of 2024

Act LXIX of 2024 — the Hungarian legal implementation of the NIS2 Directive, which aims at a higher level of protection for the security of network and information systems — introduces a new, unified set of requirements for essential and digital service providers. The aim of the Act is to reduce the vulnerability of IT systems, ensure the prevention of cyber threats and facilitate rapid response to incidents.

The regulation places particular emphasis on the documentability of processes, the existence of security controls, and the regular performance of risk analysis and risk mitigation. The Act sets out expectations not only at the level of operations but also at the level of software development — in particular along the following lines:

Establishing security-conscious development processes (e.g. secure coding practices)
Detecting and handling code defects and vulnerabilities
Creating and retaining development and operations logs
Traceability and reporting of incidents
Ensuring development documentation and auditability

The Role of Static Code Analysis in Compliance

Static code analysis (SAST) is an automated method of examining source code without running the program. The aim is to uncover, already in the development phase, the bugs, risks and bad practices that could later lead to vulnerabilities, operational problems or a lack of legal compliance.

Under Act LXIX of 2024, the organisations concerned must be able to:

continuously assess the risks of their IT systems,
verifiably check the security status of software components,
and document the protective measures applied.

This is exactly what static code analysis provides. Analysis engines — as in the case of SonarQube — go through the entire codebase on the basis of predefined rule sets and produce reports on the following areas:

Bugs: Logic errors, misused APIs, possible null pointer exceptions, etc.
Vulnerabilities: Security problems such as SQL injection, XSS and password-handling flaws.
Code Smells: Non-critical problems that impair the maintainability, readability or extensibility of the code.
Leakage of secrets: Hardcoded passwords, keys and configuration data in public repositories.

These results can easily be exported and archived, so continuous inspection and compliance can be demonstrated not only to the development team but also to authorities or internal audit units conducting an audit.

Static code analysis is therefore not only a debugging tool but also a compliance assurance mechanism, which can also be integrated into a DevSecOps approach. In the next section we describe in detail how SonarQube becomes a key player in this process.

Introducing SonarQube

SonarQube is an open-source static code analysis platform used by software development teams worldwide to monitor code quality and security. Its capabilities go far beyond classic “linting” or syntax checking: SonarQube can provide comprehensive technical debt and vulnerability analysis and can also support compliance audits.

Operating model and architecture

SonarQube is based on a client-server architecture: a client-side tool that analyses the source code (e.g. SonarScanner) collects the data and then forwards it to the central server, where the entire analysis and reporting process takes place. Developers, project managers and security professionals can all review the results of the analyses through the web interface.

Broad language support and extensibility

SonarQube natively supports more than 30 programming languages (Java, C#, JavaScript, Python, PHP, C/C++, Go, etc.) and can be extended with further languages or custom rule sets. It also has a plug-in architecture, so it can easily be integrated with other tools, such as Jira, GitHub, GitLab, Jenkins, Azure DevOps, etc.

Key features

Quality Gates: Sets of rules that automatically decide whether a commit meets the required level of quality.
Historical analysis: Every analysis has a timestamp and a version, so earlier changes in the code and their impact on quality can easily be traced.
Security Hotspots and OWASP Top 10 checks: SonarQube can identify sections of code that require special attention from a security point of view.
Detailed reports: Dashboards, project summaries, risk matrices — everything a development team or compliance officer might need.

Editions and licensing

SonarQube is available in Community (open source), Developer, Enterprise and Data Center editions. The Community Edition on its own may be enough for smaller teams to get started with compliance, while for larger companies the Enterprise edition offers full scalability, auditability and SAML-based authentication.

In the next section we examine how exactly SonarQube supports meeting the requirements set out in Act LXIX of 2024. It is also no small consideration for the organisation concerned that “non-compliance” should not come to light during the audit — given the cost of audits (SZTFH Decree 1/2025 of the Hungarian Supervisory Authority for Regulatory Affairs), a repeat audit can also mean a significant financial disadvantage.

SonarQube from a Compliance Perspective

Act LXIX of 2024 sets out clear expectations for organisations regarding the secure development of software systems, documented risk management, and the continuous maintenance of technical and organisational protective measures. Within this compliance framework, SonarQube provides direct support in three critical areas:

1. Risk-based development control

SonarQube’s static code analyser enables the development team to carry out automated risk discovery already at the code-writing stage. The tool can identify:

Critical vulnerabilities (e.g. SQL injection, command injection),
Functional bugs (e.g. improperly handled exceptions, uninitialised variables),
Insecure patterns (e.g. hardcoded passwords, secret keys).

These findings are assigned a risk level (minor/major/critical/blocker), so developers and project owners can prioritise immediately.

2. Reporting and auditability

With every code analysis, SonarQube generates detailed reports that:

document the security and quality status of the code,
remain available retrospectively (versioned logging),
can be exported as PDF or CSV, or via the API into other compliance systems.

This is particularly important during the internal controls and external audits required by the Act, as compliance becomes demonstrable at code level too — not merely on the basis of policies on paper.

3. Quality Gates as compliance tools

Quality gates are sets of rules that the organisation can customise on the basis of its own risk assessment. For example:

“No merge is allowed if there is a critical vulnerability in the code.”
“Code coverage by unit tests must be at least 80%.”
“No new technical debt may be introduced on the main branch.”

These gates can be understood not only as technical but also as legal risk mitigation mechanisms, as they prevent problematic code from reaching production systems.

Linking with other compliance systems

SonarQube can be integrated with other security and compliance platforms (e.g. Jira, GitLab Issues, audit log aggregators), making it possible to build a unified compliance chain. Via the APIs, automatic compliance reports can even be generated — e.g. on a weekly basis.

Practical Application — Integrated into the Development Lifecycle

Compliance is not a one-off task but a continuous activity that must be present at every point of the development lifecycle. SonarQube offers strong support here: it integrates seamlessly into the most common CI/CD tools and developer workflows. As a result, code inspection and compliance controls operate in an automated, scalable way.

CI/CD pipeline integration

SonarQube can easily be built into modern development platforms such as:

GitHub Actions: analyses linked to pull requests, automatic comments on issues.
GitLab CI/CD: pipeline-level code analysis, build steps tied to the quality gate.
Jenkins: integrable via a plug-in, customisable runs.
Azure DevOps: integration into build and release pipelines, reports displayed on the dashboard.

In practice, this means that every new commit or merge request automatically triggers static code analysis, and if the quality gate is not passed, the build stops, so risky or faulty code cannot be deployed to production.

Quality Gate as part of the development workflow

Quality gates can be customised in every project according to the organisation’s risk management policy. An example compliance gate could be:

Number of critical or major issues = 0
Code coverage at least 80%
New technical debt < 5%
Number of new vulnerabilities = 0

These rules act as a kind of automatic “compliance checkpoint” — with every code change they check whether it meets internal and legal requirements.

Compliance-as-Code: compliance written into code

With SonarQube it is possible to define compliance requirements as code-level rules. This so-called “compliance-as-code” approach enables:

compliance rules to be versioned and transparent,
them to be enforced automatically in every development cycle,
them to be adapted quickly to a changing legal environment.

This methodology helps developers stay within the framework of legal compliance while writing code, so the system is not built on after-the-fact checks but becomes part of the daily routine.

Recommendations for Development Teams

Introducing SonarQube is not simply a matter of installing a new tool — it is a change in development culture that treats code quality as a factor of equal importance to compliance. Below we offer some practical advice for teams that wish to use SonarQube in line with the provisions of Act LXIX of 2024.

1. Gradual introduction, with realistic goals

Do not try to fix every issue on the first day. Start from the following principle:

“Whatever is new must be good.”

In other words, we set strict quality gates for new code, while applying gradual remediation to existing (legacy) code. SonarQube makes it possible to handle new and existing code separately, so development does not grind to a halt because of the sheer number of issues.

2. Tailoring the rule set to legal requirements

SonarQube’s rule set is modular. It is worth focusing on the following rule groups:

Security Rules (OWASP Top 10, CWE): essential for legal compliance.
Maintainability Rules: help reduce technical debt.
Code Convention Rules: ensure a consistent coding style.

For audited compliance, it is worth creating your own custom quality profile that meets both the internal security policy and the requirements of Act LXIX.

3. Documentation and knowledge sharing

SonarQube is an excellent opportunity to formally document and enforce internal development rules. It is recommended to:

Document quality gates and rule profiles (e.g. in an internal wiki).
Train developers in using the tool (as part of the onboarding process).
Actively use SonarQube results during code reviews.

This develops not only legal compliance but also developer competencies, reducing the opportunities for error.

4. Close cooperation with IT security and compliance officers

The reports generated by SonarQube can serve as valuable input:

For IT security analyses, where the risk levels of vulnerabilities need to be determined.
For internal or external audits, where documented evidence of quality control is required.
For risk management reports, as technical debt also counts towards system-level risk.

Closing Thoughts

Act LXIX of 2024 has opened a new era in the Hungarian regulation of digital system security. The requirements — in particular the transparency of development processes, the mapping of security risks and the documented handling of defects — leave no room for ad hoc operation. In this new environment, code quality and compliance go hand in hand.

SonarQube is not just a tool but the catalyst for a cultural change that helps development teams ensure that security and quality are enforced right down to the level of individual lines of code. Automatic, auditable and scalable — exactly what a legal compliance process needs.

Moreover, compliance need not be merely a “burden to get through”; it can also be a competitive advantage. An organisation that can demonstrate that its software is secure, reliable and well documented will find it easier to win public tenders, earn partners’ trust or even obtain international certifications.

Future development must be not only fast but also transparent, testable and auditable. In this future, SonarQube is not an optional tool but a strategic cornerstone of every responsible development process.