SonarQube articles

AI writes the code – but who guarantees its security?

2026.10.27

AI is now an everyday tool for developers, but in many places verification has not kept pace. The answer is not banning AI, but structure and independent verification.

This was the main message of the talk given by Dr. Kabai Márton Tamás, Managing Director of Szitár-Net Kft., on 26 October 2026 at the VISZ Cybersecurity Professional Forum. The title of the talk was a question: AI writes the code – but who guarantees its security? In this article we summarise the key ideas, and the full presentation can be downloaded at the end.

AI is already everyday practice – verification is not yet

According to the Stack Overflow 2025 Developer Survey, 84% of developers use or plan to use AI tools, and 51% of professional developers already do so daily. A year earlier, the figure was still 76%.

Trust, however, has not grown at the same rate. According to Sonar’s January 2026 survey (more than 1,100 developers), 96% do not fully trust the correctness of AI-written code, yet only 48% always check it before committing. 42% of committed code is already produced with AI, and developers expect this to reach 65% by 2027.

The conclusion is simple: as AI adoption grows, verification practices have to evolve too.

Working code is not yet secure code

Newer models code more accurately, but not necessarily more securely. In its own measurement, Sonar compared GPT-5.5 and GPT-5.6 Sol on 4,444 Java tasks. The functional test pass rate improved from 78.66% to 81.99%, but over the same period the density of vulnerability findings per million lines of code rose from 68 to 197, roughly 2.9 times higher. The number of blocker-severity vulnerabilities, meanwhile, fell from 18 to 9: the risk did not disappear, it moved into areas that human review is more likely to miss.

The lesson: after a model update, the security profile of the code has to be measured again, and with a tool that is independent of the model.

Two independent studies paint a similar picture:

• According to a January 2026 study, more than 60% of PowerShell scripts written by GPT-4o and o3-mini without structured security guidance are insecure.
• According to an award-winning study presented at USENIX Security 2025, on average 21.7% of the software packages recommended by open models do not even exist. If an attacker uploads a package under such a name, an unsuspectingly installed dependency can bring malicious code into the system.

The ten risks presented in the talk were based on a talk by Shaked Reiner, including the impact of switching models, weakening human control, and the conflict of interest that arises when the same provider writes, checks and fixes the code.

Control is lost where the volume can no longer be reviewed

AI produces more code than humans can meaningfully review. In Shaked Reiner’s words: we are accumulating code faster than we are able to understand it. Where the volume is already too large, manual review needs to be complemented by automated checkpoints.

At the same time, verification has to be independent of the code’s author. Another of Reiner’s sentences became one of the central ideas of the talk: the code should not be checked by the same provider that wrote it. Using AI does not shift responsibility onto the tool either: the decision remains a human one.

SonarQube and DORA

In the financial sector, source code verification is no longer just good practice, but a requirement. DORA has applied since 17 January 2025, and the detailed rules on development are set out in Commission Delegated Regulation (EU) 2024/1774. SonarQube supports meeting several of these requirements:

DORA requirement	Reference	SonarQube support
Static source code review; analysis of vulnerabilities, action plan, follow-up	Article 16(3)	Static analysis and issue management
Security testing no later than the integration phase	Article 16(4)	Analysis on every pull request and in CI
Verification of security requirements for every change	Article 17(1)(a)	Quality gate
Testing of third-party and open source code, tracking of libraries	Article 16(8), Article 10(2)(d)	Advanced Security: SCA, SBOM
Evidence of follow-up	Article 16(3)	Compliance and PDF reports (Enterprise edition and above)

Dynamic testing, protecting the integrity of source code and incident management are not covered by SonarQube. Responsibility for compliance lies with the financial institution: SonarQube is a tool, not a certification.

Advanced Security: the layers beneath the code

Your own code is only the top layer. Beneath it are the libraries pulled into the project, and their dependencies too, the so-called transitive dependencies. SonarQube Advanced Security is a paid add-on available from Enterprise edition upwards, and it makes this layer visible:

• SCA (software composition analysis): known vulnerabilities in direct and transitive dependencies, malicious packages, and licences that violate the organisation’s licence policies. Reachability analysis also shows whether our code actually calls the vulnerable function.
• SBOM (software bill of materials): export of the complete set of dependencies in CycloneDX or SPDX format.
• Intelligent SAST: taint analysis follows user input from our own code into the code of external libraries.

With banking and public administration clients, the first question is always whether the source code leaves the premises. In SCA’s default mode of operation, manifest and lock files are processed by the bank’s own SonarQube Server; only queries for vulnerability and licence data go to Sonar, not source code. New vulnerabilities appear daily, even without re-analysis.

SonarQube’s AI tools

In SonarQube Server 2026.5, six AI tools support development, each at a different point in the process. The foundation everywhere is SonarQube’s independent, deterministic analysis: the AI tools build on it rather than replace it.

Tool	What does it do?	Where does it come in?
AI Code Assurance	Flags projects containing AI code and applies an AI-specific quality gate to them	Quality gate, pull request
AI CodeFix	Suggests a fix for an issue; the model is selectable, even your own, including without internet access	Developer environment, SonarQube interface
Remediation Agent	Fixes the issue and opens a pull request; only a human will merge it	Failed quality gate, backlog
Hunter Agent	Looks for logic and authorisation flaws that static analysis cannot see	Main branch
Sonar Vortex	Guides the AI agent before it writes, and checks after it writes	Coding, inside the agent
MCP Server	Connects the AI agent to SonarQube; can also run in read-only mode	Coding

The Hunter Agent, the Remediation Agent and Sonar Vortex are separate subscriptions on top of the Enterprise or Data Center edition, and they run on the bank’s own infrastructure.

Key takeaways

The talk closed with five recommendations that any development team can start on tomorrow:

1. Structured use of AI: document which tools are used, for what, with what data, and who is responsible.
2. Verification for every AI output: the machine checks the volume, the decision remains human.
3. Have a different model do the checking: the code should not be reviewed by the same model or provider that wrote it.
4. Static code analysis with AI support: independent analysis provides the foundation, and the AI capabilities build on it.
5. Measure and track: re-measure the code after switching models, and keep the list of dependencies up to date.

The message of the talk in one sentence: Structure + independent verification = secure AI development – with the source code staying in-house.

Download the presentation

AI írja a kódot – de ki garantálja a biztonságát? (PDF, 2.7 MB, in Hungarian)

Sources

1. Stack Overflow Developer Survey 2025 – AI
2. Sonar – Sonar data reveals critical verification gap in AI coding
3. Sonar – An Evaluation of OpenAI GPT-5.6 Sol & Terra
4. Zhang et al. – Lightweight Yet Secure (arXiv:2601.06419)
5. Spracklen et al. – We Have a Package for You! (USENIX Security 2025)
6. Regulation (EU) 2022/2554 – DORA
7. Commission Delegated Regulation (EU) 2024/1774
8. SonarQube Advanced Security – product page
9. Analyzing projects for dependencies (SCA)
10. Agentic capabilities – SonarQube Server
11. AI Code Assurance
12. Sonar – DORA Compliance for Financial Services

AI in SonarQube: what do the new agentic features mean for developers?

2026.10.02

AI-based development tools have quickly become part of everyday development work. GitHub Copilot, Claude Code and Codex no longer just complete a few lines; they write complete features, refactor, create tests, hunt for bugs and, increasingly, carry out multi-step development tasks from start to finish.

At the same time, the question of what happens to AI-generated code once it has been written has become ever more important.

Faster code generation does not in itself solve problems of quality, security or maintainability. In fact, at higher development speeds these can pile up more easily if there is no adequate verification layer in the process.

SonarQube’s new AI and agentic features are essentially an attempt to address this problem. Sonar is not trying to build its own coding AI to replace Copilot or Claude Code. Instead, it is strengthening the layer that decides whether finished code meets the project’s quality and security requirements.

AI CodeFix: issues now come with a suggested fix

SonarQube’s classic way of working is simple: the analysis runs, the system finds the issue, shows where the problem is and explains why it should be fixed.

AI CodeFix adds to this the ability to suggest a concrete code change for the issue in question.

This is not the same as pasting an error message into a general-purpose AI assistant. The starting point here is the problem identified by SonarQube itself, so behind the fix there is already a static analysis result and the rule that goes with it.

This can be useful mainly for recurring or relatively well-defined problems. If, for example, a larger system has several hundred similar maintainability issues, the developer does not necessarily have to interpret each one from scratch and rewrite it by hand.

In SonarQube Server 2026.5, enterprise AI connections can also be managed centrally, and organisations can use their own model provider. This is particularly relevant in environments where it matters which external service the source code reaches.

MCP: when the AI agent sees more than just the repository

The MCP integration is a somewhat more important change.

With the Model Context Protocol, an AI coding agent can directly access certain SonarQube information. This means that, for example, an agent based on Claude Code or Cursor sees not only the source code but can also make use of the issues and other analysis results uncovered by SonarQube.

In practice, the difference is significant.

In the traditional process, the AI writes the code, the developer commits, and only later, in the CI pipeline, does it turn out what SonarQube has found.

With MCP, the analysis results can flow back more directly to the agent, which can respond to them while development is still under way.

This can cut out the unnecessary loop in which the agent produces a solution, CI rejects it, and the developer then manually hands the same problem back to the AI.

Vortex: more context for the coding agent

In larger codebases, one of the biggest problems for AI coding agents is not necessarily code generation itself, but finding the right context.

In a large monolith or a system made up of dozens of services, it is not a trivial question what uses a given class, where the implementation of an interface lives, which component needs to be worked with, or which project-specific rules apply.

Sonar Vortex is built around this problem.

Its aim is to help the coding agent navigate the codebase better and to give it information so that it attempts changes less “blindly”.

From a developer’s point of view, this is probably more important than it first sounds.

LLMs often produce poor solutions not because they cannot write the necessary code, but because they cannot see the wider relationships within the system clearly. A technically correct solution can easily be architecturally wrong, or simply not fit the project’s existing patterns.

Vortex tries to reduce this problem by providing the agent with more relevant project context.

Remediation Agent: fixing Sonar issues can be automated too

There is a fundamental difference between AI CodeFix and the Remediation Agent.

AI CodeFix suggests a fix. The Remediation Agent, by contrast, can carry out a more complete remediation process.

The starting point here is again a SonarQube issue. The agent makes the change, and the modified code then goes through SonarQube’s checks again.

This matters because an AI-generated fix does not in itself prove that the problem has actually been resolved.

From the development process’s point of view, the useful part is precisely that the check runs again after the fix.

This can be particularly interesting where there is a large amount of technical debt. In many systems, the biggest cost is not the complexity of the problems, but having to deal with hundreds or thousands of smaller issues one by one.

Some of these tasks may be good candidates for automated remediation.

Hunter Agent: searching for a different kind of security problem

The Hunter Agent targets a different area.

Classic static code analysis is very effective where a vulnerability can be recognised from specific code patterns or data flows. Many security problems, however, are not like that.

Faulty access control, for example, does not necessarily stem from a particular function being badly written. Every component may be correct on its own, yet a check is missing from the overall flow.

The same is true of certain authentication flaws and business logic vulnerabilities.

Sonar positions the Hunter Agent precisely for these more complex problems.

Here the role of AI is to examine a broader context and look for relationships that a traditional rule-based analysis would find harder to detect.

Importantly, Hunter does not replace traditional SAST. Rather, it appears alongside it as an additional layer of analysis.

Where does Advanced Security fit into all this?

Advanced Security is worth treating separately from the AI features.

SonarQube Advanced Security is not primarily a generative AI product, but an extension of security analysis.

One of its key elements is SCA, which examines the project’s external and open source dependencies. This covers, among other things, known vulnerabilities, transitive dependencies, licence issues and SBOM management.

The other important area is Advanced SAST, which can perform deeper analysis of data flows between your own code and external libraries.

This solves a different problem from the Hunter Agent or the Remediation Agent.

The goal of Advanced Security is to map actual security risks as accurately as possible. AI agents, on the other hand, can interpret additional context, produce fixes or look for problems where classic static analysis alone is not enough.

The two directions therefore complement each other rather than compete.

How might this change the development process?

The change will probably not happen overnight.

Until now, for many teams SonarQube has mainly been one of the checkpoints in the CI/CD pipeline:

commit, build, SonarQube analysis, Quality Gate.

In agentic development, however, verification can move closer to the development process itself.

A coding agent might, for example, make a change, request or receive SonarQube’s feedback, fix certain problems, and then check the result again. By comparison, the developer receives something much further along for review.

This does not mean that human code review disappears.

Rather, it is about separating the tasks that genuinely require a developer’s decision from those that the machine can reliably detect or even fix.

Review time is better spent on architectural, business logic or security questions than, for example, on manually fixing dozens of identical code smells.

AI writes the code. But who is going to check it?

2026.09.10

AI-based development tools became part of everyday software development in a very short time. Today it is nothing special for a developer to have artificial intelligence generate code snippets, tests or even complete features.

The advantage is fairly clear: you can move faster.

The problems usually start when we confuse speed with quality.

AI-generated code can be fully functional while at the same time being hard to maintain, containing a security issue, or simply not fitting properly into the existing system.

And this will probably be one of the most important questions in AI-assisted development in the period ahead.

Not whether AI can write code.

It can.

But how we check the volume of code we are producing ever faster.

Working code is not necessarily good code

This is, of course, not a new problem.

Software development has always had code that worked but was not a particularly good solution technically.

What AI changes is mainly the scale of the problem.

A developer might, for example, ask the AI to build a database query or write an API endpoint. A few seconds later, a working solution is there.

But just because the code runs and produces the desired result does not mean it is free of, say, improper input handling, a security vulnerability or an unnecessarily complicated solution.

Nor is it certain that it follows the same development rules that the company or development team has previously defined.

This is a particular problem in larger systems.

When we are talking about a few hundred lines of code, human review is still relatively easy to manage. But when a development team uses thousands of lines of AI-generated or AI-modified code every day, the situation is quite different.

In such cases it can easily happen that the bottleneck is no longer development itself, but its verification.

AI can also produce technical debt faster

For a long time, technical debt built up in a system gradually.

A quick fix here, a temporary patch there, a few duplicated code fragments, and over months or years you ended up with a codebase that is hard to maintain.

With AI, this process can speed up significantly.

Generated code may contain unnecessary repetition, overly complex functions, or solutions that are technically correct but not a good idea in the longer term.

Individually, these usually do not cause any visible problems.

In a large system, however, they add up.

And a few years down the line, the question will no longer be how much faster a given feature was delivered, but how much it costs to keep maintaining the system.

Security is a particularly sensitive area

With AI-generated code, security is perhaps the area where unconditional trust can least be afforded.

A piece of code can look entirely correct at first glance while containing a flaw that only shows up under specific conditions.

There may be, for example, faulty input validation, inadequate access control, or a data handling approach that could later lead to a vulnerability.

On top of this comes a human factor.

If an AI gives a good solution nine times out of ten, a kind of trust in it develops very easily.

But the tenth case still has to be found.

Whether a human or an AI wrote it is probably not the right question

After a while, this may not even matter much.

From the point of view of the development process, it is far more practical to treat the question this way: all code has to pass the same quality and security checks.

Whether it was written by a senior developer.

A junior developer.

Or an AI assistant.

This is the approach in which automated code analysis really comes into its own.

What does SonarQube bring to this?

The essence of SonarQube is that source code analysis should not be an occasional task, but part of the development process.

The system can continuously examine issues relating to code quality, maintainability and security, among other things.

In my view, this is particularly important in AI-assisted development.

If the volume of code being produced grows, it is simply not realistic to check every single change through manual code review alone.

Automated checks can then act as a first filter.

They do not replace the developer or professional review, but they can flag a great many problems earlier that would otherwise only surface later.

The Quality Gate may become even more important than before

One of SonarQube’s useful features is the Quality Gate.

It lets you define which quality conditions new code must meet.

If these are not met, this becomes immediately visible in the development process.

In a CI/CD environment, the check can also be built directly into the build and deployment process.

This is a particularly good approach for AI code.

There is no need to create a separate set of rules for what AI has generated. The same requirements can be applied to every change.

In my view, this is far more sustainable in the long run than trying to separate code written by humans from code produced by artificial intelligence.

AI does not make the developer redundant

On the contrary, in a certain sense it actually increases the value of good developers’ knowledge.

If less and less time has to be spent actually typing code, more emphasis falls on someone defining the task well, understanding the architecture, recognising the risks and being able to decide whether a solution proposed by AI is genuinely good.

As a result, the developer’s role will probably change gradually.

Less “code production”, more design, verification and technical decision-making.

Faster development needs faster control too

It is probably no longer worth trying to stop or ignore the spread of AI coding.

Developers will use it, because it genuinely speeds up a great many tasks.

For companies, the question will rather be what kind of controls they build around it.

If AI multiplies development speed, verification processes have to be adapted to match.

Human code review will remain important, but on its own it will probably be less and less sufficient.

Automated code quality and security checking is therefore not an alternative to AI, but much more its natural counterpart.

AI writes code faster. And SonarQube can help ensure that quality and security do not fall behind the pace of development.

Szitár-Net Kft. – SonarSource Silver SVAR Partner

As a SonarSource Silver-certified SVAR partner, Szitár-Net Kft. provides support with SonarQube licences, implementation and professional services.

AI is writing more and more code – which is why SonarQube is becoming ever more important

2026.08.11

Artificial intelligence has quickly become one of the most important tools in software development. AI-based coding assistants no longer just complete a few lines of code: they can create complete functions, APIs, database queries, tests, configurations and even entire application components.

This can bring a significant increase in productivity. At the same time, it raises a fundamental question:

If more and more code is created with the help of AI, who checks the quality and security of that code, and how?

AI speeds up the creation of code, but on its own it does not solve the problem of code quality, security, maintainability and compliance with corporate development rules. Quite the opposite: with the mass adoption of AI coding, these become even more important.

This is where SonarQube can become one of the key control points of a modern, AI-assisted development process.

We develop faster with AI – but we can also produce faulty code faster

One of the greatest advantages of AI-based development is speed.

A developer might previously have spent hours building a more complex function, database operation or integration. With an AI assistant, a first version can be created in minutes.

This, however, has an interesting consequence. If a developer used to produce, say, 300 lines of new code a day without AI, and can produce 600–900 lines with AI, then it is not only development output that increases. So does the amount of code that needs to be checked.

If 1% of the code contains some kind of problem, then with two or three times as much generated code there are potentially two or three times as many problems to detect and handle.

AI can therefore significantly increase development capacity, but this must be matched by adequate quality assurance capacity. The solution is not necessarily to have more people checking code manually. Rather, it is to automate the checking as well.

AI-generated code is source code too

An important realisation is that, from SonarQube’s point of view, it essentially makes no difference how a given piece of code was created. It may have been written by:

• a junior developer,
• a senior developer,
• an external supplier,
• or it may have been created with the help of AI.

Source code entering the repository must meet the same quality and security requirements.

This is especially important in an enterprise environment. AI can generate. But the company must still control what goes into its applications.

Example 1 – AI generates working SQL code, but is it also secure?

Suppose a developer asks the AI assistant:

“Write a function that retrieves a customer’s data from the database based on the customer ID.”

The AI produces a working solution. For example, to build the query it directly appends the parameter coming from the user.

The program works. It gives the right result with the test data. So the developer can easily move on.

However, with certain implementations this can create an SQL injection risk. It is a perfect example of how working code ≠ secure code.

In this case, the AI’s job was to support the developer and create the code. The job of code analysis, on the other hand, is to check whether the resulting solution meets the expected requirements.

The two technologies are therefore not competitors. They complement each other.

Example 2 – AI solves the problem but creates technical debt

Suppose that in an enterprise system the same business logic has to be used in several modules. Developers quickly build the individual features with AI. Each time, the AI creates a similar solution. Each one works.

A few months later, however, it turns out that several different implementations of the same business logic have found their way into the system.

In the short term this does not necessarily cause errors. In the long term, however, it can increase:

• code complexity,
• maintenance costs,
• the risk of changes,
• technical debt.

AI often optimises for solving the task at hand. The company, however, has to think in terms of the entire software lifecycle.

In this environment, SonarQube can help with continuous and consistent examination of code quality.

Example 3 – AI-generated code that is “too complicated”

A developer asks an AI assistant to implement a complex business rule. The AI creates a 150-line function. The function:

• works,
• runs,
• gives the right result.

At first glance, then, everything is fine. The solution, however, may be full of nested conditions, branches and hard-to-follow logic.

Six months later another developer has to modify it. That is when the real problem emerges: the code works, but it is hard to understand and hard to maintain.

The lifecycle of an enterprise application, however, can be 5–10–15 years. So during development it is not enough to ask: “Does it work?” We also need to ask: “Will it still be maintainable years from now?”

AI + SonarQube: two different tasks

The relationship between AI coding and SonarQube can therefore be put very simply:

• AI → helps create the code.
• SonarQube → helps check the quality and security of the code that has been created.

Together, the two can form the basis of a much more controlled development process.

The goal is not to restrict the use of AI. Quite the opposite. Proper control allows the company to take advantage of the productivity gains offered by AI with greater confidence.

Quality Gate: don’t just flag the problem

One of SonarQube’s key concepts is the Quality Gate. The company can define quality conditions that determine whether a code change meets the expected requirements.

This can become particularly valuable in AI-based development. Imagine the following process:

1. The developer builds a feature with the help of AI.
2. The code enters the development process.
3. SonarQube analyses it automatically.
4. The Quality Gate checks the predefined requirements.
5. If there is a problem, the developer receives feedback.
6. The problem is fixed – possibly again with the help of AI.
7. Another automatic check takes place.

This results in a very interesting development cycle:

AI generates → SonarQube checks → developer/AI fixes → SonarQube checks again.

In this way, automated quality assurance can accompany the speed of AI.

One of the biggest risks of AI: it is too easy to accept the answer

AI assistants can generate code extremely convincingly. The code:

• looks professional,
• is well formatted,
• seems logical,
• and often even works on the first attempt.

This also presents an interesting psychological problem. The better the AI, the more easily a feeling can develop: “If the AI made it and it works, it’s probably fine.”

Yet AI can also apply bad patterns, create unnecessary complexity or generate a solution that does not comply with a particular company’s development rules.

That is why a control layer is needed that does not “trust” the author of the code. It does not matter whether it was written by a human or by AI – the code must be examined according to the same rules.

Even more important at financial institutions

In banking, financial, telecommunications, government and other critical systems, AI-based development raises particularly interesting questions. In these environments it is not enough to say: “The developer checked the AI-generated code.”

Reproducible, consistent and, where possible, automated controls are also needed.

In a large organisation, hundreds of developers and numerous external suppliers may be working at the same time. Different people bring with them:

• different AI tools,
• different prompts,
• different development methods,
• different experience.

The common point must be the company’s quality requirements. SonarQube can help establish uniform control here.

AI does not make static code analysis redundant – quite the opposite

A few years ago, one might have thought that increasingly intelligent development tools would gradually reduce the importance of static code analysis. In practice, the opposite may well happen.

AI increases development speed, which increases the amount of code being produced, which increases the number of changes to be checked, which makes automated quality assurance even more important.

In other words, the more successful AI becomes in software development, the greater the need may be for systems that check the finished code automatically and consistently.

The development model of the future

The enterprise development environment of the coming years is unlikely to be about “human or AI”. It will be much more about a collaborative model:

Developer + AI + automated code quality checking + automated testing + CI/CD + security controls.

In this model, each participant has a different role.

• 🤖 AI – Helps create and modify code faster.
• 👨‍💻 Developer – Defines the goal, evaluates the solution and takes responsibility for the implementation.
• 🔍 SonarQube – Provides continuous and automated control for examining the quality and security of the source code.
• 🧪 Automated testing – Verifies how the system behaves.
• ⚙️ CI/CD – Automates the development and release process.

Together, these can form the modern software development infrastructure of the AI era.

The question is not whether to use AI

For companies, the interesting question will soon no longer be “Should we allow developers to use AI?”, but rather: “How do we build AI into our development processes in a controlled way?”

To do this, at least three questions need to be answered:

1. Who may use which AI tools?
2. What data and source code may be handed over to these tools?
3. How do we check code created with the help of AI?

One important technological answer to the third question is SonarQube.

AI speed + SonarQube control

Artificial intelligence represents a huge opportunity for software development. But speed alone cannot be the goal. The company still needs secure, reliable, maintainable and controlled source code.

That is why the relationship between AI and SonarQube can perhaps best be summed up in a single sentence:

Let AI help you code faster. Let SonarQube help you keep code quality under control.

Together, the two are not simply a technological improvement. They are one possible foundational model for enterprise-level quality assurance in AI-based software development.

Szitár-Net Kft. – SonarSource Silver SVAR Partner

As a Silver-certified SonarSource SVAR partner, Szitár-Net Kft. helps Hungarian companies and institutions select, license, implement and integrate SonarQube solutions into their development processes.

Our SonarQube references include leading Hungarian organisations such as:

Magyar Nemzeti Bank | OTP Bank | K&H Bank | IdomSoft | One Magyarország

With the rapid spread of AI-based development, one of the defining questions of the coming years will not simply be how much faster we can produce code, but also how we can check the quality and security of ever more rapidly created code just as quickly.

This is where SonarQube is playing an increasingly important role.

SonarQube and AI code analysis: a safety barrier in ever faster development

2026.06.04

AI-based development tools have fundamentally changed the pace of software development in just a few years. Today, developers no longer use artificial intelligence only to search, document or fix bugs; they also have it generate entire functions, components, tests, configurations and even complete parts of applications. This is a huge opportunity, but also a serious risk: the volume of code is growing faster than it could be checked with traditional methods.

It is in this environment that the role of SonarQube becomes particularly important. SonarQube has long been a well-known static code analysis tool that helps uncover bugs, vulnerabilities, code smells, maintainability problems and security gaps. With the rise of AI, however, its task has expanded: it is no longer just a matter of examining the quality of human-written code; AI-produced code must also be kept under control.

AI speeds things up, but takes no responsibility

The greatest advantage of AI coding tools is speed. A developer can create code snippets in minutes that previously would have taken hours. This is especially useful for prototypes, writing documentation, producing unit tests, generating repetitive code or understanding older codebases.

The problem begins with the fact that AI-written code often looks convincing but is not necessarily correct. It may be syntactically correct and may work with the first test data, yet still contain a hidden bug, a vulnerability, a poor architectural decision or a solution that is hard to maintain in the long term. AI does not fully understand the organisation’s business logic, internal rules, security expectations and operating environment.

That is why AI-generated code must not automatically be treated as a finished result ready to be integrated. It is better seen as a quickly produced first draft that must be checked just as thoroughly — and in certain cases even more strictly — than human-written code.

Why is SonarQube important in AI development?

This is exactly where SonarQube provides significant support. It provides an objective, repeatable and automatable verification layer in the development process. Its purpose is not to replace developer thinking or code review, but to automate the first line of defence in code checking.

Among other things, SonarQube can identify:

• potential bugs;
• security vulnerabilities;
• SQL injection, XSS, path traversal and other typical attack vectors;
• hardcoded passwords or sensitive data;
• excessive complexity;
• duplicated code;
• maintainability problems;
• poor or misleading solutions;
• improper exception handling;
• non-compliant or inconsistent coding patterns.

This is especially important for AI-generated code, because AI tends to produce solutions that appear to work at first glance but do not necessarily meet security, quality or corporate development requirements.

AI Code Assurance: verification instead of trust

Among SonarQube’s newer AI capabilities, AI Code Assurance is of particular importance. Its aim is to place projects generated by or involving AI under stricter quality and security control.

In practice, this means that the organisation can separately flag the projects or parts of code where AI code generation has taken place, and then assign higher-level quality gates, checking rules and compliance requirements to them. This is an important change of mindset: the use of AI should not be banned; instead, it must be ensured that AI-created output cannot reach production without control.

The essence of AI Code Assurance is therefore not distrust, but clarifying responsibility. The question is not “may AI write code?”, but “how do we prove that AI-written code is secure, maintainable and meets the organisation’s expectations?”

AI CodeFix: faster fixes, but under developer control

SonarQube’s AI CodeFix feature is another important direction. This capability not only detects problems but can also provide AI-based fix suggestions for issues identified by SonarQube. This can be a great help to developers, because they do not have to interpret every rule violation or vulnerability from scratch.

CodeFix can be particularly useful for:

• quickly fixing common bugs;
• eliminating simpler vulnerabilities;
• refactoring suggestions;
• reducing technical debt;
• supporting junior developers;
• cleaning up larger codebases.

It is important, however, that AI CodeFix does not mean automatic approval either. The developer must still understand, check and test the suggested fix. A good working model is one in which AI speeds up the fix, SonarQube checks the quality and security requirements, and the developer makes a professionally responsible decision on accepting the change.

The new logic of the development process

In the AI era, the centre of gravity of the development process is shifting. Previously, writing the code itself was often the biggest resource demand. Today, checking, interpreting, validating and safely integrating code is increasingly becoming the critical task.

This requires a new development logic:

• AI helps to produce the first version of the code quickly.
• The developer interprets the result and adapts it to the business logic.
• SonarQube automatically checks for bugs, vulnerabilities and code quality problems.
• The CI/CD pipeline prevents non-compliant code from entering the main branch or production.
• Code review no longer looks only for formal errors, but examines business, architectural and security compliance.

In this model, SonarQube is not a simple add-on tool, but a quality assurance gate. It is a control point that helps maintain development speed without the organisation losing control over code quality.

Why is this particularly important in an enterprise environment?

In an enterprise system, faulty code is not merely a technical problem. It can cause business disruption, data protection incidents, loss of customers, compliance risk or even legal consequences. AI-produced code is therefore only a real advantage if the organisation is able to control its quality.

SonarQube supports companies in this at three levels.

At the first level, it provides technical control: it uncovers bugs, vulnerabilities and maintainability problems.

At the second level, it provides process control: with quality gates, rule sets and CI/CD integration it prevents non-compliant code from moving further.

At the third level, it provides management and compliance support: it makes technical debt, security risks and development quality measurable.

This is especially important for organisations where development takes place in a regulated environment, for example in the financial, public administration, healthcare, industrial or cybersecurity sectors.

AI does not reduce but increases the importance of code checking

Many expect AI to make development simpler. This is partly true: producing code does indeed become faster. At the same time, the importance of checking grows. The easier it is to generate code, the more code can get into the system, and the greater the danger that defects also spread faster.

In a modern development environment, therefore, it is not enough to measure how much code has been produced. The more important question is how much code has been produced securely, in a verified way and sustainably.

SonarQube plays a key role in this. It helps to ensure that AI is not an uncontrolled accelerator, but a regulated development tool. The goal is not to restrict the use of AI, but to ensure that AI-assisted development does not come at the expense of quality, security and maintainability.

A new tool in the SonarSource portfolio: SonarQube Enterprise Advanced Security

2025.12.04

In enterprise software development it is no longer in question that code quality and security go hand in hand. The vast majority of vulnerabilities still appear in in-house source code and in defects of open source components — while development teams deliver features at an ever faster pace in CI/CD pipelines using agile methodologies. In this environment a “classic” static code analyser is no longer enough: an integrated security solution is needed.

This is the role filled by SonarQube Enterprise Advanced Security, which can be positioned as a new, premium, specialised product for customers who require high code quality, developer-friendly operation and strict security compliance at the same time.

What is SonarQube Enterprise Advanced Security?

SonarQube is already a comprehensive code quality and code security platform out of the box, supporting more than 30 programming languages and integrating into CI/CD processes in an automated way.

The Advanced Security module extends this core solution with deeper security analysis, specifically for Enterprise Edition 2025 R3 and later server releases. It tightly integrates advanced SAST (Static Application Security Testing) and Software Composition Analysis (SCA) capabilities, so protection extends not only to in-house code but to the entire software supply chain — including open source components.

In short: the Advanced Security module is the extra layer that turns a “plain” SonarQube Enterprise into a comprehensive, developer-first application security solution.

Main capabilities

1. Advanced SAST and taint analysis

SonarQube’s security engine has already included SAST, which analyses source code and identifies potential vulnerabilities, security weak points and security hotspots.

Building on this is Advanced SAST, which, as part of the Advanced Security module:

• uses taint analysis to trace the path of user input through the code, even across multiple files and layers;
• detects typical injection attacks, for example:
  • SQL injection (CWE-89),
  • cross-site scripting (XSS, CWE-79),
  • code injection (CWE-94), etc.

One of the key points of Advanced Security is that taint analysis examines not only the data flow within in-house code, but also how the code interacts with third-party libraries and components, so hidden defects that traditional SAST tools typically miss can also come to light.

2. Secrets detection — preventing leaks of passwords and keys

The module’s built-in secrets detection capability automatically searches code, configuration files and repositories for:

• API keys,
• passwords,
• certificates, tokens and other sensitive credentials.

This is particularly important in environments where developers, DevOps teams or AI tools generate and commit code quickly: a few mishandled secrets are enough to seriously compromise a system.

3. IaC scanning — cloud and infrastructure code security

Advanced Security targets modern, cloud-based architectures by also analysing Infrastructure as Code (IaC) definitions.

It can:

• detect incorrect permission settings,
• poorly sized or overly permissive security rules,
• potentially vulnerable network and storage configurations, for example in Terraform, Kubernetes and CloudFormation definitions.

4. Software Composition Analysis (SCA) — full visibility of open source risks

One of the biggest new features of Advanced Security is the SCA module, which handles the security and licence risks of open source components and third-party libraries.

The module:

• identifies vulnerable component versions based on CVE databases;
• helps prioritise the defects to be fixed using metrics such as CVSS, EPSS and KEV;
• automatically maps the licence terms of components and flags any legal conflicts;
• makes the software supply chain transparent by generating an SBOM (Software Bill of Materials).

This capability adds particular value for organisations where supply chain transparency, licence compatibility and software supply chain protection are regulatory expectations.

5. Reports, standards and compliance

In a SonarQube Enterprise environment, Advanced Security extends the range of security reports and supports compliance with frameworks such as:

• OWASP Top 10,
• OWASP ASVS,
• CWE Top 25,
• PCI DSS, STIG and other industry standards.

These reports support the CISO, audit teams and management in ensuring that code and application security is not only “technically in order” but also demonstrable with documentation.

The product is therefore not merely “a new licence”, but a complex, value-adding solution: platform + expertise + implementation + operational support.

Typical use cases

• Banks, insurers, financial service providers — high security and compliance expectations, complex layered architectures, a heavily regulated environment.
• Public sector and critical infrastructure providers — compliance with cybersecurity laws and NIS2-type requirements, auditability, transparent risk management.
• Enterprise development centres — hundreds of projects, many languages, microservice architecture, heavy dependence on open source.
• Development teams using AI — automatic security checking of AI-generated code, integrated into the familiar Sonar workflow.

Business value — why is it worth it for the customer?

1. Lower cyber risk, fewer incidents

   By filtering out injection flaws, hardcoded secrets, IaC defects and vulnerable open source libraries early, the likelihood and expected cost of a successful attack can be significantly reduced.

2. Faster development, less “firefighting”

   If developers receive feedback already at commit or merge request level, fixing defects is orders of magnitude cheaper and less painful than if the problem only came to light during a production incident.

3. Compliance and auditability

   Standards-based reports (OWASP, CWE, PCI DSS, etc.) can easily be fitted into internal and external audit processes, supporting the demonstration of compliance.

4. Developer-first approach

   SonarQube is fundamentally a developer tool, used daily by millions worldwide. The Advanced Security module extends this familiar environment, so there is no separate “security tool pain”: developers receive quality and security feedback in the same tool.

Don’t just generate it, verify it: AI code quality with Sonar

2025.12.04

With the explosion of generative AI tools (GitHub Copilot, Cursor, Windsurf, etc.), developers are writing code at an unprecedented speed. At first this seems like a huge gain, but Sonar’s official “AI Code Quality” page is quite clear: the volume of code is growing exponentially, while actual developer review capacity is not. This gives rise to what they call the “engineering productivity paradox” — productivity seemingly increases, but the risk is very real.

Throughout, the page shows how AI acceleration and code quality can be combined without the risk getting out of hand: “vibe, then verify” — in other words, developers can freely “spin up” code with AI, but at the end an automated, reliable verification layer closes the process.

What is the problem with AI-generated code?

Sonar highlights three main risks:

1. “Mind the gap” — the capacity gap

   AI dramatically speeds up code writing, but people’s time for review is finite. The volume of code grows, while the proportion of time that can be spent on genuine review shrinks — this is what leads to the productivity paradox mentioned above.

2. A crisis of trust in AI code

   Developers often do not trust complex or unfamiliar solutions suggested by AI. They fear hidden bugs, instability and security flaws.

3. Hidden security vulnerabilities and lax standards

   LLMs can “pass on” bad patterns, vulnerable code snippets and poor practices found in their training data. Without control, injection flaws, bad dependencies, or simply solutions that deviate from the team’s own coding standards can slip into the code unnoticed.

All in all: with AI more code is produced, but it becomes harder to keep track of and to maintain quality, and there is a serious risk that defects multiply “silently”.

The role of SonarQube: AI code, fast but supervised

From Sonar’s perspective, the solution is not to block the use of AI, but to put a security and quality framework around it. According to the page, SonarQube promises that it:

• supports the acceleration of AI-based development,
• while enforcing quality and security control on every line of code,
• and makes the inflow of AI code manageable at the organisational level.

The emphasis throughout is that developers should not slow down, but whatever AI produces should pass through a consistent set of rules — the same quality and security expectations as “classic” hand-written code.

Key features: how does Sonar “verify” AI code?

Sonar organises its AI-code-specific features into four major capability groups.

1. AI-ready quality gates

The familiar Sonar quality gate logic (“it can’t be merged if it’s red”) is applied specifically to AI code as well. The essence:

• AI-generated code passes the same — or even stricter — quality and security thresholds as human code,
• the merge can only happen if these are met (based on metrics such as bugs, code smells, vulnerabilities, coverage, duplication, etc.).

This layer provides the basic confidence that the AI code being merged is not “second-class” compared with the rest.

2. AI Code Assurance — automatic feedback in the DevOps platform

AI Code Assurance is essentially Sonar automation focused on AI code, which:

• checks quality, security and compliance at pull request level,
• gives feedback directly in the DevOps platform developers use (GitHub, GitLab, Azure DevOps, etc.),
• helps to separate and handle changes created by AI separately.

From the developers’ point of view, this means there is no need to open a separate tool — the “Sonar verdict” appears in the same place where they work anyway.

3. Real-time in-IDE feedback

SonarQube’s “AI code quality” solution also addresses the IDEs in which AI assistants (Cursor, Windsurf, Copilot integrations) now work. According to the page:

• the developer receives immediate feedback in the IDE on AI code that has been pasted in or modified,
• this helps quality and security problems surface while the code is being written, not just in the pipeline,
• the source (AI, developer, copy-paste) essentially does not matter — Sonar performs the check.

This is especially important where developers really are “chatting in code” with the AI assistant: it matters in what state quickly accepted suggestions end up in the repo.

4. Built-in security review

Sonar’s AI solution does not stop at code quality; the page highlights that:

• it uses automated analysis to look for critical vulnerabilities — e.g. injection flaws,
• it also examines dependency risks, which LLMs tend to “reproduce” based on their training data,
• this layer is particularly important with AI, because the model does not “know” that a given version of a library is already vulnerable — it just copies patterns.

In effect, this builds an AI security shield around the code, relying on Sonar’s classic security capabilities but specifically tailored to AI scenarios.

Summary — what are the key takeaways?

The problem: AI dramatically speeds up code writing, but this increases the risk of unchecked, inconsistent and vulnerable code getting into the system.

The solution: around SonarQube, Sonar builds a framework that,

• with AI-ready quality gates,
• AI Code Assurance,
• real-time feedback in the IDE
• and built-in security review, automatically checks AI code and brings it up to the same level as the output of human development.

The message: using AI is not risky in itself — what is risky is letting it into the product without control. Sonar’s solution promises that the organisation can retain control over code quality and security while confidently allowing developers to rely on AI assistants in their daily work.

What is “compliance & reporting” at Sonar?

2025.11.26

Introduction

SonarSource’s “Compliance & Reporting” module is designed to make it demonstrably traceable whether a given piece of code — be it written by humans, open source or even AI-generated — complies with the relevant standards, regulations and security requirements.

The goal is not merely to improve code quality, but to ensure compliance automatically during development, integrated into the existing CI/CD pipeline, with audit-ready evidence available at all times.

The traditional challenges

In modern software development, meeting compliance requirements is no longer optional; it is a fundamental business and security prerequisite. Various standards — such as PCI DSS, HIPAA, SOC 2, STIG or various industry compliance frameworks — set increasingly complex expectations regarding code quality, data handling and the application of security controls. In practice, however, meeting them is often extremely cumbersome, especially if the organisation still relies on manual tools. In many places, checking code compliance is based on slow, monotonous workflows in which developers or quality assurance specialists have to review code snippets one by one, document the defects and then collect evidence for audits. This is not only resource-intensive but also carries a significant risk of error.

The specifics of the audit environment make the situation even more difficult. During an audit, every claim must be based on verifiable evidence, which means that organisations must support with detailed and traceable documentation that their code genuinely meets the requirements prescribed by the standards. In practice, this often takes the form of separate Excel spreadsheets, screenshots, manually compiled reports and informal notes, which can take many hours or even days to prepare. Moreover, updating and maintaining manual documentation is usually neglected, so by the time of the audit it often no longer accurately reflects the current state of the system. This also distracts developers, since instead of building new features they are forced to deal with administrative tasks.

The greatest risk, however, arises when compliance problems are discovered late, in the testing phase or just before release. In such cases a drastic rewrite is often needed, which can stall the entire development process, lead to missed deadlines and generate significant costs. If the defects are security-related — for example in the form of vulnerabilities, improper data handling or missing controls —, late detection can even entail business risk, reputational damage or legal consequences. This is precisely why it has become so important for compliance checking to become an integral part of development: automated, consistent and traceable, from the moment the code is written.

How SonarQube helps: in automated compliance

SonarQube makes compliance transparent and automated in the following ways:

• Centralised rule management — every project follows the same quality and compliance rules, so development work becomes consistent.
• Automatic audit trail — defects, vulnerabilities, changes and fixes are recorded automatically, so they can easily be traced during an audit.
• “One-click” reports — reports compiled according to various standards (OWASP Top 10, PCI DSS, CWE Top 25, STIG, etc.) can be generated at any time.
• CI/CD integration and PR checks — analysing pull requests and branches guarantees that non-compliant code does not get into the main branches.
• Quality gates and customisable standard profiles — the system can be configured to let code through only if it meets every requirement.
• SCA and SBOM support — the licences and security status of external components are checked automatically, including the software bill of materials.

In practice

Compliance & reporting is not just a supplementary feature: in modern development culture it provides a framework that builds compliance into everyday development. This is particularly useful for organisations that operate in a regulated environment, have audit obligations or develop critical systems.

Sonar’s solution is therefore not just a code quality checking tool, but an integrated compliance system capable of supporting development, audits, security and organisational rule-following at a systemic level.

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.

The NIS2 Directive and Source Code Analysis

2024.09.03

In 2022 the European Union set a new milestone in cybersecurity when it adopted the NIS2 Directive, which is designed to further strengthen the protection of network and information systems. The Directive aims to raise the level of cybersecurity in the Member States and to extend the scope of their protective measures. NIS2 imposes stricter requirements for risk management, security audits and incident response, particularly with regard to critical infrastructure and services. In this article we look at how source code analysis relates to this new regulation and what role it can play in meeting the requirements of NIS2.

The NIS2 Directive is a further development of the NIS (“Network and Information Security”) Directive adopted in 2016, broadening the range of sectors covered to include healthcare, energy, water management and digital infrastructure. The aim of the new Directive is to improve resilience against cyberattacks across the European Union, especially in the area of critical services. Accordingly, the introduction of risk management and cybersecurity measures takes centre stage, and organisations must make serious efforts to build up their technical and organisational defences.

Source code analysis can serve as a fundamental tool for meeting these requirements. By examining source code, security vulnerabilities, bugs and other problems in software that may pose a risk to organisations can be identified. There are two types of source code analysis: static and dynamic. They use different methods to help uncover software defects. Static analysis examines the quality of the code without executing it, whereas dynamic analysis continuously checks the security of software at runtime through real-time testing.

Source code analysis makes a significant contribution to risk management, as it makes it possible to uncover potential security problems before the code goes into production. This reduces the risk of cybersecurity incidents, since defects can be fixed in time, before attackers can exploit them. Continuous source code analysis helps organisations manage risks proactively and ensure regulatory compliance.

One of the key elements of the NIS2 Directive is the obligation to report incidents, under which organisations must report significant cybersecurity incidents to the competent authorities. The information gained through source code analysis not only plays a role in preventing incidents but can also be used during audits and inspections. The purpose of audits is to verify an organisation’s level of security, and data from source code analysis can help demonstrate that the organisation complies with the requirements laid down by NIS2.

A tool such as SonarQube can play a prominent role in carrying out source code analysis effectively. SonarQube is an open-source platform that is widely used by developers and cybersecurity professionals. It can examine source code in a variety of programming languages and produces detailed reports on the security status of the code. This makes it easier for organisations to identify the bugs and vulnerabilities in their code and to take the necessary steps to remedy the problems in good time.

All in all, the NIS2 Directive raises the importance of cybersecurity in the European Union to a new level, and source code analysis plays a key role in enabling organisations to meet the new requirements effectively. Regular code reviews, incident prevention and use in security audits all help companies protect their network and information systems against growing threats. Introducing SonarQube and similar tools not only helps organisations ensure compliance but also raises their overall level of cybersecurity in the long term.

A Comparison of Source Code Analysis Tools

2024.09.03

Source code analysis plays an essential role in software development and cybersecurity. Today there are numerous tools available whose purpose is to detect the bugs and security vulnerabilities hidden in code. SonarQube stands out among them, having become a major market player among analysis tools. In this analysis we compare SonarQube with two other popular competitors, Checkmarx and Veracode, highlighting their strengths and differences.

SonarQube: A Comprehensive Overview

SonarQube is an open-source platform widely used by software developers to analyse code quality and security. It supports numerous programming languages, such as Java, C#, JavaScript, TypeScript, Python, C and C++. The tool produces detailed reports on the issues found in the code and makes suggestions for fixing them. It integrates easily with various development environments, such as Jenkins or Azure DevOps, making continuous code inspection easier.

Checkmarx: The Security-Oriented Solution

Checkmarx is another leading source code analysis tool, specialising primarily in detecting security flaws and vulnerabilities. The tool supports many programming languages and frameworks, enabling it to perform wide-ranging analyses of the security status of code. It is particularly strong at checking compliance with various security standards, and it produces in-depth reports to help minimise potential risks.

Veracode: Automated Security Analysis

Veracode is a market-leading tool that likewise focuses on the automated checking of code security. It supports a variety of programming languages and application types and connects to many development environments. The tool provides wide-ranging reports on the security vulnerabilities in the code and offers effective suggestions for fixing them, thereby helping to make the development process secure.

SonarQube vs. Checkmarx vs. Veracode: Evaluation Criteria

Code Quality and Security Analysis

• SonarQube: This tool not only focuses on identifying code quality issues such as duplication and complexity, but also supports the latest security standards, such as the OWASP Top 10. The tool can also be used to identify stylistic inconsistencies and potential bugs that may degrade code quality.
• Checkmarx: This solution specifically targets security vulnerabilities, with detailed analyses and vulnerability discovery. The tool produces comprehensive reports that help developers and security professionals recognise and address risks in good time.
• Veracode: Like Checkmarx, Veracode also focuses on security analysis. It analyses code in an automated way and provides wide-ranging recommendations for avoiding potential threats. It also supports the latest industry standards.

Integration Options

• SonarQube: It integrates widely with development and continuous integration tools such as Jenkins, GitLab and GitHub. This makes code inspection and the automation of the development process easier.
• Checkmarx: Similarly to SonarQube, Checkmarx can be flexibly integrated with various development platforms, providing automated security testing and continuous code monitoring.
• Veracode: This tool also supports integration with the most commonly used development environments, enabling automated security testing and regular code checks.

User Interface and Usability

• SonarQube: Thanks to its simple, well-structured user interface, it is easy to use for developers and security professionals alike. The tool’s visualisations are quick to take in and help in identifying problems.
• Checkmarx: Although it provides detailed and thorough reports, the complexity of Checkmarx’s user interface may mean a learning curve for new users.
• Veracode: It provides an intuitive interface that enables developers and security professionals to identify and fix security issues efficiently

Scalability and Performance

• SonarQube: It has a scalable architecture designed to handle large codebases, ensuring efficient analysis and high performance.
• Checkmarx: It is also capable of handling large projects, ensuring adequate performance even for complex security analyses.
• Veracode: It copes easily with large projects too, guaranteeing scalability through fast, automated security tests.

SonarQube, Checkmarx and Veracode are all outstanding source code analysis tools, each with its own advantages. While Checkmarx and Veracode have strong security analysis capabilities, SonarQube provides a more comprehensive analysis of both code quality and security. Thanks to its integration capabilities, user interface and performance, SonarQube is a versatile choice at every stage of the development process.

Why Is SonarQube the Market Leader Among Source Code Analysis Tools?

2024.09.03

Source code analysis is of outstanding importance in modern software development and cybersecurity, where it is an indispensable tool for developers and IT security experts in identifying bugs and vulnerabilities in code. Although several source code analysis tools are available, SonarQube stands out as one of the best-known and most widely used solutions. This article explains in detail why SonarQube has become the market leader and what benefits it brings.

An Overview of SonarQube

SonarQube is an open-source platform that focuses on improving code quality and uncovering security risks. It supports many popular programming languages, such as Java, C#, JavaScript, TypeScript, Python, C and C++. The system is capable of automated code analysis based on the latest standards and can be connected to numerous development environments and continuous integration systems (CI/CD), enabling continuous inspection and the rapid handling of security vulnerabilities.

The Key Benefits of SonarQube

1. Improving Code Quality

   

   One of SonarQube’s greatest advantages is that it produces thorough reports on code bugs, security vulnerabilities and suggested fixes. The system can detect problems such as duplicated code, excessive complexity and inconsistent style, and it also uncovers potential bugs. This information enables developers to optimise their code, which increases the reliability and maintainability of the software.

2. Advanced Security Analysis

   SonarQube has an extensive set of security rules capable of detecting vulnerabilities. The tool supports the latest security standards, such as the OWASP Top 10, and is regularly updated to take new threats into account. SonarQube makes it possible to identify security problems in good time, thereby minimising the risk of cyberattacks.

3. Seamless Integration

   SonarQube offers broad compatibility with development tools and continuous integration systems such as Jenkins, Azure DevOps, GitLab and GitHub. As a result, code quality can be checked continuously and any problems can be detected immediately, ensuring the stability and security of the software.

4. User-Friendly Interface

   

   The system has an intuitive, easy-to-follow user interface, so developers and security professionals can use it efficiently. Clear reports and visualisations help to identify and fix issues quickly. The customisable interface allows teams to shape their processes according to their own needs.

5. Performance and Scalability

   SonarQube is also suitable for handling large codebases, which is particularly useful for larger companies running several projects in parallel. The system delivers high performance, analysing code efficiently without slowing down development cycles.

SonarQube in the Service of Cybersecurity

1. Managing Cybersecurity Risks

   SonarQube can identify and uncover the security vulnerabilities hidden in source code that make software vulnerable. The system examines code according to the latest security guidelines and helps prevent potential cybersecurity incidents.

2. Automated Security Testing

   The system can continuously analyse code in an automated way after every update, ensuring that quality and security always remain up to date. Automation enables a rapid response to emerging problems.

3. Supporting Compliance Requirements and Audits

   SonarQube also makes it easier for organisations to comply with various standards, such as NIS2. The reports and logs produced by the system can also be used for auditing, thereby ensuring transparency.

Community Support and Services

1. Open-Source Community

   The active community behind SonarQube continuously contributes to the tool’s development, keeping the platform up to date with new features and updates.

2. Detailed Documentation and Training Materials

   Extensive documentation and training materials are available for the tool, helping users learn to use it effectively.

3. Professional Support

   Expert support is also available, ensuring that users can quickly find solutions to any problems that arise and use the system optimally.

SonarQube’s rise to market leadership is therefore no accident: the tool offers numerous benefits for developers and security professionals alike. Easy integration, detailed analyses, high-level security features and community support together make this platform the first choice in source code analysis.

The 10 Most Common Cyber Threats and How to Defend Against Them

2024.09.03

Today many different types of cyberattack can threaten not only individuals but also larger organisations. In this article we list the ways you can defend against them, so that your information and your business are as secure as possible.

Cyberattacks of all kinds can be extremely costly for the individuals and organisations that fall victim to them. According to the FBI Internet Crime Report, cyberattacks caused a dramatic USD 10.2 billion in losses in 2022. Moreover, this figure is expected to keep growing in the coming years, so cybercrime remains a significant cause for concern.

Many factors contribute to the rising number of cyberattacks. Among other things, inflation has increased the cost of preventing cyberattacks, so some companies struggle to fit cybersecurity measures into their budgets, which leaves them vulnerable. Global geopolitical tensions have also increased the number of politically motivated cyberattacks.

In this article we examine cyberattacks, the different types to watch out for, and the methods you can use to protect yourself or your organisation.

What Exactly Is a Cyberattack?

A cyberattack is an attempt to steal, alter, destroy, disrupt or disable information resources and systems in computer networks and systems. Cyberattacks fall into two categories: insider threats and external threats. Insider threats are committed by individuals who have legitimate access to the targeted systems and who use that access to exploit vulnerabilities, intentionally or unintentionally. They may be committed by a disgruntled or angry employee, or by a contractor with access to the organisation’s systems. External threats come from people with no connection to the system under attack, such as criminal organisations or hackers.

Who Do Attackers Target?

Cyberattackers frequently target the healthcare, government, non-profit and financial sectors. Of these, the healthcare sector is particularly vulnerable to attack, as healthcare organisations have access to the personal data of many people. Healthcare infrastructure is critically important, which is why ransomware attackers count on these organisations being likely to meet their demands quickly.

Because of confidential information such as social security numbers, government organisations are also among hackers’ favourite targets. Non-profit organisations are in a unique position, as they hold their donors’ financial data and details of their fundraising efforts, making them ideal targets for cyberattacks. In the financial sector, banks and insurance companies are also frequent targets of extortion and theft, given that they have access to significant sums of money.

Common Types of Cyberattack

Of course, cyberattacks do not always have financial motives. Some cyberattacks focus on destroying critical data or simply on gaining access to it.

Organisations and individuals may face the following most common cyberattacks:

1. Malware

   Cyberattackers use harmful software such as spyware, viruses, ransomware and so-called worms, collectively known as malware. They use it to gain access to all the data on a system. For example, when you click on a malicious attachment or link, the malware can easily install itself and activate on your device. The various viruses therefore fall into this category.

2. Phishing

   Phishing attacks rely on communication methods such as email, through which attackers try to persuade the recipient to open the message and follow the instructions it contains. If the victim follows the attackers’ instructions, they can gain access to the victim’s personal data, such as credit card details, and can also install malware on their device.

   

3. Spoofing, or Faking Contact Details

   Cyberattackers sometimes impersonate people or companies to try to get you to hand over your personal data. This can happen in several ways. A common spoofing strategy is to use a fake phone number, where the person being called cannot see that the number is fake. Other spoofing methods include tricking facial recognition systems, using a fake domain name or creating a fake website.

4. Trojan Horses

   So-called Trojan attacks involve malicious programs that can install malware or data and open a kind of “back door” into your computer system. As the name suggests, this is done entirely hidden from the victim, so once the attackers gain access to the back door, they can “hijack” the device without the user knowing about it.

   

5. Ransomware

   Ransomware is malicious software that cyberattackers can install on your device, allowing them to block access until you pay the attackers a ransom. However, paying the ransom does not guarantee that the software will be removed, which is why experts often advise that, if possible, no one should pay it and should seek help instead

6. Password Attacks

   Password attacks can be as simple as someone correctly guessing your password after many attempts. However, there are methods such as keylogging, where attackers monitor all the information you type in a day and identify passwords from it. The attacker may also use the phishing approach mentioned above, disguising themselves as a trustworthy site in an attempt to trick the victim into revealing their account credentials.

   

7. Internet of Things (IoT) Attacks

   This term essentially refers to various uniquely identifiable electronic devices that can detect some meaningful information and communicate it to another device over an internet-based network. The communication channels between connected IoT components can be vulnerable to cyberattacks, as can the applications and software on IoT devices. Because these IoT devices are connected to one another via the internet and may have limited security features, they offer a wider attack surface for attackers to target.

8. Cryptojacking

   So-called cryptojacking is the unauthorised use of a computer system, usually through malware that allows the attacker to use the computer’s resources to mine cryptocurrency. Cryptocurrency mining can involve significant operating costs, so cryptojacking is the easier route, giving attackers a way to avoid these costs.

   

9. Drive-By Downloads

   Drive-by download attacks occur when malicious code is downloaded onto someone’s device through an application, website or operating system whose security is flawed. This means that even though you have done nothing wrong, anyone can fall victim to a drive-by download, as it can result from a lack of security measures on a website that appears perfectly safe to users.

10. Denial-of-Service Attacks (DDoS)

    A denial-of-service attack takes down an entire device or operating system by overloading it with traffic, which eventually causes it to crash. Attackers do not often use this method to steal information. In return, however, it costs the victim time and money to get their systems working again. Cybercriminals generally prefer to use this method when the target is a commercial organisation or a government entity.

    

How Can We Prevent Cyberattacks?

An important first step in preventing cyberattacks is to ensure that both the head of the organisation and its other employees are aware of all the possibilities and variations of cyberattacks. It is extremely important to pay attention before clicking on a link, and checking that an email address is legitimate, among other things, is also key to fending off at least the surface-level attacks and keeping our systems’ data safe.

Here are some useful tips for preventing cyberattacks:

• Software Updates

  Up-to-date software systems are far more resilient than outdated versions, which may be prone to weaker performance. Updates can fix software bugs and weaknesses, so it is always best for your system to be running the latest version.

• Installing a Firewall

  Firewalls are useful in preventing many attacks, such as back doors and denial-of-service attacks. In essence, they control the network traffic passing through the system. A firewall stops all suspicious activity that it judges to be potentially harmful to the computer.

  

• Backing Up Your Data

  During a backup, data is moved to another, secure location for storage. This may involve cloud storage or a physical device such as a hard drive. In the event of an attack, backing up your data makes it possible to restore lost data immediately.

• Encrypting Data

  Data encryption is a popular method of preventing cyberattacks, ensuring that data is accessible only to those who hold the decryption key. To successfully attack encrypted data, attackers often have to rely on the brute-force method (also known as exhaustive search), trying different keys until they find the right one, which makes the encryption difficult to crack.

• Using Strong Passwords

  You should have strong passwords to prevent attacks and avoid using the same passwords for different accounts and systems. Reused passwords increase the risk of attackers gaining access to all your information. Updating passwords regularly and using passwords that combine special characters, upper- and lower-case letters and numbers can help protect your accounts.

  

• In Summary

  In summary, cyberattacks pose a significant threat to individuals and organisations alike, and their number is expected to keep growing. The attack types and defence methods presented in this article help us understand the threats we face and how to defend against them effectively. Using Sonar products, Szitár-Net provides its clients with high-level code analysis and cybersecurity solutions that make it possible to identify and eliminate software vulnerabilities, thereby guaranteeing the security of data and systems.

Clean As You Code

2023.09.12

Every business that writes software reaches a point where its development is expected to be clean and secure. If you do not pay attention to your development tooling, your development will quickly become costly and time-consuming, and you may put your business at serious risk.

1. Software bugs cost the economy trillions of dollars every year.
2. Developers working alongside auditors (under the traditional approach) spend 42% of their time fixing bad code.
3. 83% of security vulnerabilities are the result of mistakes rather than malicious attacks.
4. Security vulnerabilities go unnoticed for 4 years on average before they are identified.

Another great example of this is our Clean As You Code methodology, an effective and unique approach to clean code that eliminates many of the challenges associated with traditional approaches. As a developer, you focus on maintaining high standards and take responsibility for the new code you are working on (new code being, by definition, code that has been added or changed – the New Code Definition).

The benefit is that there is no longer any need to go back and fix inherited code. This happens automatically over time, simply because of the nature of software development: for example, take a company with 1 million lines of code – in the following year, it will on average change or rewrite about 20% of its codebase. If it introduces CAYC1, 20% of its codebase will be clean by the end of the year, and this percentage will keep growing every year until all earlier, inherited issues have been overwritten, without carrying the burden of technical debt.

The benefits of Clean Code:

1. Businesses gain greater productivity and strategic value when they reduce the time spent reworking bad code.
2. SonarSource is the only solution that looks for the cause at the “roots” of bad software and approaches the market from that angle.

1. Business:

1. Faster and more agile feature development
2. Lower operational and reputational risk
3. Longer code lifespan, as a genuine asset for long-term needs
4. A solid foundation for advanced security practices

2. Team:

1. Greater code ownership within the team
2. New foresight into key investment areas
3. More time for new features and technology development
4. Shorter development cycles

3. Developers:

1. Less time and cost spent fixing technical issues
2. More energy left for creating new features
3. More effective code review for better work
4. Greater job satisfaction

How should software development companies interpret Act XXIII of 2023 (the Hungarian Cybersecurity Act, ‘kibertan.tv’)?

2023.09.12

1. If the software development company is a medium-sized enterprise or larger, it clearly falls within the scope of the Act.

The Act classifies outsourced ICT services as a highly critical sector

provider of outsourced (managed) ICT services: an organisation that provides services relating to the installation, management, operation or maintenance of ICT products, networks, infrastructure, applications or any other electronic information systems, either at the customer’s premises or remotely

2. If it is a micro or small enterprise, it falls within the scope of the Act “only” indirectly.

2.1. The client for whom it develops or provides software falls within the scope of the Act because it belongs to one of the specified sectors and is not a micro or small enterprise.

2.2. The client for whom it develops or provides software falls within the scope of the Act because, although it is a micro or small enterprise, the organisation is a

• provider of electronic communications services,
• trust service provider,
• DNS service provider,
• top-level domain name registry, or
• domain name registration service provider

3. What must a company do if it is directly within the scope of the Act?

1. establish an information security management system;
2. appoint a person responsible for electronic security
3. carry out a risk analysis of its electronic information systems and the data processed in them;
4. assign its electronic information systems and the data processed in them to security classes;
5. implement the administrative, physical and logical protective measures prescribed for the applicable security classes,
6. have its systems audited every 2 years.

Organisations must ensure:

1. the handling of security incidents;
2. the establishment and maintenance of business continuity;
3. the integration of information security into the procurement, development and operation processes of electronic information systems and the software and hardware products they use;
4. the security training of the organisation’s staff

4. What exactly does this look like in chronological order?

• The company must determine that the Act applies to it and, by 30 June 2024, notify the Supervisory Authority for Regulated Activities (Szabályozott Tevékenységek Felügyeleti Hatósága) of this fact so that it can be registered.
• From October 2024, it must pay the supervisory fee to the Supervisory Authority for Regulated Activities.
• From October 2024, it must put the protective measures into effect.
• By 31 December 2024, it must sign a contract with an audit firm listed in the register of the Supervisory Authority for Regulated Activities.
• By 31 December 2025, it must also have completed its first audit

5. What needs to be done if the software development company’s client is also within the scope of the Act?

The ICT product developed and made available by the software development company must fit into the national cybersecurity certification schemes, which may specify one or more of the “basic”, “substantial” and “high” assurance levels for ICT products. The assurance level provides assurance that the ICT products concerned meet the relevant security requirements and security functions, and have undergone an evaluation at a level intended to

a. at the “basic” assurance level, the basic, known risks of security incidents and attacks, b. at the “substantial” assurance level, known cybersecurity risks and the risk of security incidents and cyberattacks carried out by actors with limited skills and resources, c. at the “high” assurance level, the risk of cyberattacks carried out by actors with significant skills and resources using state-of-the-art technology – minimise.

The assurance level must be commensurate with the level of risk associated with the intended use of the ICT product, in terms of the probability and impact of security incidents.

In summary, your client will classify the ICT product “under” the “basic”, “substantial” or “high” security level

6. What are the general requirements associated with the “basic”, “substantial” or “high” security level?

For the “basic” assurance level

1. the technical documentation (with regard to meeting the requirements of the given certification scheme)

For the “substantial” assurance level

1. the technical documentation (with regard to meeting the requirements of the given certification scheme)
2. verification of the absence of publicly known vulnerabilities;
3. testing to determine whether the ICT product correctly implements the necessary security functions

For the “high” assurance level

1. the technical documentation (with regard to meeting the requirements of the given certification scheme)
2. verification of the absence of publicly known vulnerabilities;
3. testing to determine whether the ICT product implements the necessary security functions correctly and in line with the state of the art
4. assessment, by means of penetration testing, of how resistant it is to attacks carried out by skilled actors.

7. How can it be demonstrated that the ICT product meets the requirements for the “basic” security level?

At the “basic” security level, for ICT products classified as low risk, conformity self-assessment is an option

The manufacturer issues a national statement of conformity confirming that it has been examined whether the requirements of the national cybersecurity certification scheme are met. The examination must include an evaluation of compliance with the requirements of the national cybersecurity certification scheme in accordance with the methodology set out in the certification scheme.

Within 15 days, for the purpose of registration, the following must be sent – also in an electronically searchable format – to the certification authority (the Supervisory Authority for Regulated Activities):

1. a copy of the statement of conformity,
2. the technical documentation, the national cybersecurity
3. evaluation report prepared on the basis of the evaluation method specified in the certification scheme, and all other relevant evaluation information relating to conformity with the designated certification scheme.

Based on the registration, the Authority verifies compliance with the statement

8. How can Szitár-Net Kft. help with carrying out the conformity self-assessment?

Our company, Szitár-Net Kft., holds silver SVAR (premier technical support partner) status in Hungary for SonarQube, the best-known source code analysis system. We have been working with source code analysis for more than 5 years and can provide consulting support for the conformity self-assessment of the system under examination.

9. How can it be demonstrated that the ICT product meets the requirements for the “substantial” and “high” security levels?

Conformity with the requirements for the “substantial” and “high” security levels can only be certified by conformity assessment bodies entered in the register of the Supervisory Authority for Regulated Activities.

Conformity assessment body currently in the register:

HUNGUARD Számítástechnikai-, informatikai kutató - fejlesztő és általános szolgáltató Korlátolt Felelősségű Társaság

Assurance level: High Status: Active

10. How can Szitár-Net Kft. help with meeting the requirements for the “substantial” and “high” security levels?

In the assessment methodology of conformity assessment bodies, too, one of the most important elements is source code analysis and the cybersecurity aspects associated with it.

The importance of automated source code analysis software from the perspective of company executives.

2023.09.12

In the modern business world, software development plays a key role in the life of companies. The development of IT systems and applications is indispensable for maintaining a digital presence and staying competitive. For software development companies to create high-quality applications efficiently, the use of automated source code analysis software is essential. In this article, we explain in detail why it is important for executives of software development companies to recognise the critical role and wide-ranging applications of such software.

1. Code Quality and Bug Fixing

Automated source code analysis software plays a prominent role in checking code quality and identifying defects early. These tools can detect syntax errors and logic errors, as well as coding and formatting errors. Identifying defects early is crucial because:

• The cost of fixing defects falls significantly if they are identified and fixed in the early stages of development. According to research by IBM, fixing defects in the late stages of development can be up to 30 times more expensive. According to a study by the National Institute of Standards and Technology (NIST), the US software industry spends more than 60 billion dollars a year on fixing software defects.
• Saving time is crucial. Developers need to spend less time fixing defects and can move the project forward faster.

2. Code Style and Consistency

Code style and consistency are essential for code that is easy to maintain and develop. Automated source code analysis software can identify code style violations and formatting errors. For example:

• Incorrect use of spaces and indentation.
• Incorrect naming of variables and functions.
• Incorrect formatting of branches and loops.

A consistent code style and formatting help new developers settle into projects and make code easier to read and maintain.

According to information published by Google in 2012, automated code analysis software helped save a total of 13 years of time on their codebase by assisting with code organisation and maintaining code cleanliness.

3. Security and Data Protection

Cybersecurity is now a priority for every company. Automated source code analysis software plays a critical role in checking code security and identifying security vulnerabilities. Examples relating to cybersecurity:

• SQL injection: SQL injection is one of the most frequently exploited attack methods. Automated source code analysis software can identify this type of vulnerability in the code and suggest how to fix it.
• Cross-Site Scripting (XSS): XSS attacks put application users at risk. Automated analysers help identify potential XSS sources in the code and handle them appropriately.

4. Performance Optimisation

Application performance is crucial for the user experience. Automated source code analysis software can identify slow or inefficient pieces of code that may affect performance. By using resources more efficiently, applications become faster and more efficient. o Research by IDC has shown that poorly optimised applications use 10–25% more resources than they actually need, which can cause significant costs for companies.

5. Time Savings and Cost Reduction

Automated source code analysis software effectively reduces the time and resources spent on fixing defects. As a result, development projects are completed more efficiently and on time. In addition to cost savings, time savings also mean faster time to market, which can create a competitive advantage.

According to research by the Aberdeen Group, software development companies that use automated source code analysis software reduced their defect-fixing costs by 15% on average, and their product releases became 20% faster

The importance of source code analysis

2023.09.12

Software development is playing an increasingly leading role in the technology world. Because of rapid change and growing competition, software developers need to consider every tool and strategy in order to maintain quality, performance and security. In this article, we explain in detail why source code analysis is so important for software developers, and how clean code and static and dynamic source code analysis can contribute to the success of projects. We also recommend some effective software for source code analysis.

Why is source code analysis important?

Source code analysis is the process of evaluating and checking software source code from various perspectives. There are many reasons why source code analysis is vital:

• Quality control: Source code analysis helps identify bugs, syntax problems and style issues in the code. This improves code quality and makes maintenance easier.
• Performance optimisation: Analysis makes it possible to spot slow or inefficient pieces of code and to improve performance.
• Security: Source code analysis makes it possible to identify potential security gaps and vulnerabilities, which is crucial for cybersecurity and data protection.
• Maintenance and Development: Source code analysis simplifies maintaining and extending code, as it becomes easier to identify and understand how the code works.

The fundamental importance of clean code

Clean code is the foundation of successful source code analysis and efficient software development. Clean code is:

• Readable: The code is easy to understand and clear to other developers as well.
• Compact: It contains no unnecessary or duplicated code, which reduces the potential for errors.
• Compliant with coding guidelines: The code follows company or project-specific coding rules and conventions.
• Well documented: It contains appropriate documentation explaining how the code works and how to use it.

Clean code enables developers to work together effectively and makes the software easy to maintain and extend.

Code inheritance: The eternal question

Code inheritance is a principle in software development whereby new code inherits the functionality and properties of existing code, in part or in full. Code inheritance has many advantages, including reusability and simpler maintenance. However, code inheritance also carries risks, particularly the inheritance of bugs and vulnerabilities. In this context, source code analysis is especially important, as it helps identify potential problems in inherited code and makes it possible to fix them.

Static source code analysis

Static source code analysis is a technique in which code is examined without actually being executed. It offers many advantages:

• Early bug fixing: Analysis helps identify syntax errors, logic errors and style issues before the code is even run.
• Detecting security gaps: Static analysis helps identify potential security gaps, such as SQL injection or Cross-Site Scripting (XSS) vulnerabilities.
• Checking code quality: Static analysis helps check code quality and compliance with coding guidelines.

Some effective static source code analysis tools:

• SonarQube: An open-source tool that supports many programming languages and provides performance evaluation, code security analysis and various other checks.
• Checkmarx: A powerful tool for identifying security vulnerabilities that supports a wide range of languages and frameworks.

Dynamic Source Code Analysis

In dynamic source code analysis, the software is actually executed and its behaviour is monitored. It offers many advantages:

• Real-time debugging: It enables defects to be identified in real time and fixed immediately.
• Performance optimisation: It helps identify slow pieces of code and optimise the software’s performance.
• Checking memory management and resource usage: Analysis helps identify inefficient use of memory and resources.

Some effective dynamic source code analysis tools:

• Valgrind: An excellent tool for identifying memory management errors in C/C++ projects.
• Apache JMeter: An ideal choice for performance testing and stress testing of web applications.

Conclusion

Source code analysis is fundamental for software developers to maintain quality, security and performance. Clean code and static and dynamic source code analysis are all essential parts of code quality and project success. The recommended software tools can help make source code analysis more effective and contribute to the success of development teams. Do not overlook this critical practice if you want to guarantee the quality and security of your software products.

Static and dynamic source code analysis in software development: Which one, when and why?

2023.09.12

Software development is a complex and challenging process in which developers have to take many aspects into account for the sake of quality, efficiency and security. Two important techniques that can help improve code quality and identify defects early are static and dynamic source code analysis. In this article, we take a closer look at both types of source code analysis and use examples to illustrate when and why each is worth using.

1. Static Source Code Analysis

Static source code analysis is a technique in which code is analysed without actually being executed. The essence of it is that the code is thoroughly examined with the help of specialised software or a tool, and possible bugs, problems and issues affecting code quality are detected. During static analysis, we can examine the following aspects:

Syntax errors

One of its most important roles is identifying syntax errors, which essentially mean invalid code and can prevent the program from running. For example:

python
for i in range(10)
	print(i)

In this Python code, the colon is missing at the end of the loop header, which is a syntax error.

Logic errors

Static analysis can also identify logic errors that do not necessarily lead to error messages but can cause incorrect behaviour. For example:

int x = 5;

if (x > 10) {

printf("x is greater than 10");

} else {

printf("x is less than or equal to 10");

}

In this C code, the logic error is that the relational operator is worded incorrectly in the messages, since x is not greater than 10, yet the message says “x is greater than 10”.

Code style and formatting

Static analysis can help identify violations of code style and formatting rules. For example:

public void MyMethod(){

int x=5;

if(x>0)

{

System.out.println("x is positive");

}

}

In this Java code, the code style and formatting do not follow the usual conventions: for example, the method name should start with a lowercase letter, there should be spaces between the variables, and the curly braces are formatted incorrectly.

2. Dynamic Source Code Analysis

Dynamic source code analysis is a different approach in which the code is actually executed and its behaviour is monitored at runtime. Dynamic analysis makes it possible to examine the following:

Variable values and behaviour

During dynamic analysis, we can monitor the values of variables and the behaviour of the program at runtime. For example:

def divide(x, y):

result = x / y

return result

result = divide(10, 2)

In this Python code, dynamic analysis can help identify whether the variable values and operations work correctly, for example whether the “result” variable holds the correct result.

Performance and resource usage

Dynamic analysis makes it possible to monitor the program’s performance and its use of resources (memory, CPU, etc.). For example:

int main() {

int* arr = new int[1000000];

// ...

delete[] arr;

return 0;

}

In this C++ code, dynamic analysis can help identify a memory leak, as the “delete[]” operation is missing and the allocated memory is not freed.

Debugging and exceptions

Dynamic analysis makes it possible to monitor errors and exceptions, which helps with debugging and improving the stability of the program. For example:

public static void main(String[] args) {

int[] arr = {1, 2, 3};

System.out.println(arr[3]);

}

In this Java code, dynamic analysis reports that an index out of bounds error occurred when we try to display the fourth element of the arr array.

3. Static and dynamic analysis: When and why do we use them?

Both static and dynamic source code analysis have their own place and role in software development. As a general guideline, we use them as follows:

• Static Analysis: Usually used in the early stages of the development process to identify syntax errors, violations of code style and formatting rules, and possible logic errors. It helps improve code quality and identify defects early.
• Dynamic Analysis: Dynamic analysis is used more for monitoring runtime behaviour and performance. We use it to check the security and stability of the code, and to identify performance problems and memory leaks.

An example of when it is worth using both analysis methods:

Suppose we are developing a web application that reads its data from a database. Static analysis can help identify syntax errors and potential SQL injection risks in the code. At the same time, during dynamic analysis we monitor the code at runtime to make sure that it works correctly and uses memory efficiently.

4. Summary

Static and dynamic source code analysis are two different but complementary techniques for improving software quality and identifying defects early. One focuses on the code during development, while the other monitors the program’s behaviour at runtime. Both methods are worth using, depending on the project and the nature of the defects, in order to create software of the highest possible quality and security.