What Is the Difference Between Severity and Exploitability?

Geplaatst op: 22 October 2026

The difference between severity and exploitability determines how dangerous a vulnerability truly is in practice. Severity describes the potential impact if a vulnerability is exploited, while exploitability indicates how easily an attacker can actually carry out that exploitation. Both scores together provide a far more realistic picture of risk than either one alone. In this article, we answer the most important questions about how to interpret these scores and how to set the right priorities based on them.

How do you determine which vulnerability is the most dangerous?

The most dangerous vulnerability is not automatically the one with the highest severity score. A vulnerability is only truly dangerous when it both has a large potential impact and is relatively easy for an attacker to exploit. The combination of severity and exploitability determines the actual risk to your organization.

Many organizations make the mistake of looking exclusively at the severity of a vulnerability on paper. A vulnerability with a critical CVSS score of 9.8 sounds alarming, but if that vulnerability can only be exploited from an internal network that no attacker has access to, the actual risk is considerably lower. Conversely, a vulnerability with a lower score can be urgent if it is easily exploitable remotely and provides access to sensitive systems.

Attackers do not think in lists of findings. They look for the path of least resistance: the combination of weaknesses that gets them to their goal the fastest. This means that when assessing vulnerabilities, you should always ask: how does this finding fit into a broader attack chain?

What exactly does the CVSS score measure?

The CVSS score, or Common Vulnerability Scoring System score, is a standardized method for measuring the severity of a vulnerability on a scale of 0 to 10. The score combines multiple factors, including the attack vector, the required privileges, user interaction, and the impact on confidentiality, integrity, and availability.

The CVSS score is built from three groups of metrics:

• Base metrics: the inherent properties of the vulnerability itself, such as whether it can be exploited remotely and what impact it has on a system
• Temporal metrics: factors that change over time, such as the availability of a public exploit or a patch from the vendor
• Environmental metrics: adjustments based on the specific environment of your organization, such as how critical the affected system is

In practice, most tools and reports use only the base score, without taking into account temporal or environment-specific context. This makes the score useful as a first indication, but insufficient as a basis for prioritization. A CVSS score says something about the potential severity of a vulnerability, but nothing about the specific situation of your organization or the likelihood that an attacker will actually exploit that vulnerability.

Why does a critical severity sometimes have low priority?

A critical severity score does not always justify immediate action, because the score does not take into account the specific context of your environment. If a vulnerability with a high CVSS score can only be exploited via direct physical access, or only applies to software you do not use at all, the actual threat is minimal.

There are several reasons why a vulnerability with a high severity score may still receive low priority:

• The affected system is not reachable from the internet or from the network segment where an attacker is located
• There is no known public exploit for the vulnerability
• Compensating controls are active, such as network segmentation or additional authentication requirements
• The system contains no sensitive data and is not critical to business operations
• The vulnerability requires a high level of privileges that an attacker realistically does not have

This is precisely why manual pentesting is more valuable than a purely automated vulnerability scan. A scanner reports based on the CVSS score; an experienced tester assesses whether a vulnerability is actually exploitable in your specific environment.

How do attackers use exploitability when choosing a target?

Attackers evaluate exploitability as one of the first filters when choosing an attack path. They look for vulnerabilities that are remotely exploitable, require no or minimal privileges, require no user interaction, and for which public exploits or tools are available. The lower the barrier, the more attractive the target.

A good example is the difference between a vulnerability that an attacker can exploit remotely without any authentication, and a vulnerability that only works if the attacker already has administrator privileges. The first has high exploitability and immediately attracts the attention of automated attack tools and opportunistic attackers. The second requires the attacker to already be deep inside the system, which raises the barrier considerably.

What attackers also do — and what is often missed in traditional risk assessments — is combining multiple vulnerabilities with a low individual severity into one working attack path. A misconfigured cloud setting, combined with overly permissive permissions and a weak identity configuration, can together lead to full access to cloud resources, while none of the three findings is considered critical on its own. Attackers do not see isolated findings. They see attack paths.

What factors determine whether a vulnerability is truly exploitable?

Whether a vulnerability is actually exploitable depends on a combination of technical and environment-specific factors. The most important ones are the attack vector, the required privileges, the availability of a working exploit, and the presence of compensating security controls in your specific environment.

The key factors at a glance:

• Attack vector: is the vulnerability exploitable via the internet, via the local network, or only with physical access?
• Required privileges: does an attacker already need an account or administrator access to exploit the vulnerability?
• User interaction: does a user need to click or open something before the exploit works?
• Availability of exploits: does a public, working exploit exist, or is the technical knowledge required to write one limited?
• Compensating controls: are there firewalls, network segmentation, MFA, or other controls that reduce exploitability?
• Patch status: is a patch already available, and how quickly is it deployed within your organization?

Assessing all these factors together requires insight into how your environment is set up. A thorough security analysis goes beyond checking off CVE scores and assesses vulnerabilities in the context of your specific architecture, identities, and permissions.

How do you prioritize vulnerabilities based on both scores?

Effective vulnerability prioritization combines severity and exploitability in a risk model that also takes into account the context of your organization. The rule of thumb: prioritize vulnerabilities that both have a high impact and are relatively easy to exploit, and factor in how critical the affected system is to your business operations.

A practical framework for prioritization works in three layers:

1. Known vulnerabilities with public exploits: CVEs with a high CVSS score and an available public exploit require immediate action. These are the low-hanging fruit for attackers and should be addressed first.
2. Individual weaknesses in configuration and identities: misconfigured cloud settings, overly permissive permissions, and weak identity configurations often have a lower CVSS score but high exploitability in practice. They deserve a higher priority than their score suggests.
3. Correlated attack paths: the most dangerous category is often the combination of multiple small weaknesses that together form an attack path. No single finding appears critical on its own, but together they can lead to full access to systems or cloud resources.

When prioritizing, it is also important to consider which systems are most attractive to attackers and which are most critical to your organization. A vulnerability in an internal test system has a different priority than the same vulnerability in a production environment containing customer data.

Annual pentests provide a snapshot, but the environment changes continuously. New applications, modified permissions, and new vulnerabilities mean that a prioritization list quickly becomes outdated. Continuous insight into attack paths is therefore not a luxury but a necessity for organizations that take their security seriously.

How Q-Cyber helps assess severity and exploitability

At Q-Cyber, we believe that a list of vulnerabilities only has value when you understand which of them are truly exploitable in your specific environment. That is why we assess vulnerabilities not only based on CVSS scores, but in the context of your architecture, identities, permissions, and attack paths.

What we concretely do:

• We conduct manual pentests in which our ethical hackers think like a real attacker, including identifying correlated attack paths that automated scanners miss
• We assess vulnerabilities at three levels: known CVEs, individual weaknesses in configuration and identities, and combined attack paths
• We deliver concrete prioritization based on both severity and actual exploitability in your environment, not based on generic scores
• We provide continuous insight through Continuous-Q®, so you know where you stand not just on the day of the test but throughout the entire year
• We give pragmatic advice on which measures eliminate the most risk, independent of software vendors or suppliers

Want to know which vulnerabilities in your environment are truly exploitable and how to best prioritize them? Contact us and we will be happy to think along with you.

Lees meer

How Can Overly Broad User Permissions Lead to a Cyberattack?

Geplaatst op: 21 October 2026

Excessive user permissions are one of the most common causes of successful cyberattacks. When employees have access to systems, folders, or applications they don’t need for their work at all, it dramatically increases the attack surface. An attacker who compromises one account can rapidly move through to critical systems via surplus permissions. This is called privilege escalation, and it is a technique hackers apply on a daily basis.

In this guide, you’ll work through step by step how to address excessive user permissions, implement the least privilege principle, and transform access management from a one-time action into a continuous process. Every step is immediately actionable, even if your organization does not yet have a formal access policy.

Map existing user permissions

Before you can change anything, you need to know what exists. Many organizations have granted permissions over the years without maintaining a central overview. Accounts accumulate permissions after role changes, projects, or temporary exceptions that were never reversed. Start, therefore, with a complete inventory.

1. Export an overview of all active user accounts from your identity provider (such as Active Directory, Azure AD, or a comparable system).
2. Map out per account which permissions have been granted: local administrator rights, access to shared folders, application licenses, and cloud permissions.
3. Also note service accounts and shared accounts, as these are regularly overlooked during rights audits.
4. Compare the permissions found with the current role of each user.

After this step, you’ll have a concrete picture of the current situation. You’ll likely immediately encounter accounts with permissions that have long since ceased to be necessary. That is normal, but it is also exactly what an attacker is looking for. A manual pentest can further expose these kinds of hidden weaknesses.

Identify surplus and high-risk permissions

With the inventory in hand, you now analyze which permissions actually pose a risk. Not every redundant permission is equally dangerous, but some combinations can give an attacker direct access to critical systems. Hackers don’t look at isolated vulnerabilities, but at how they can combine multiple small weaknesses into a single working attack path.

1. Flag accounts with administrator rights that do not have an administrator role. These are direct risk factors.
2. Look for accounts belonging to departed employees or inactive users that are still active.
3. Pay attention to accounts with simultaneous access to multiple sensitive systems, such as financial data and HR systems.
4. Identify permissions that were granted for a temporary project but were never revoked.
5. Check service accounts for unnecessarily high permissions, as attackers are fond of abusing these accounts due to their high privileges and limited monitoring.

Prioritize your findings based on risk: the more sensitive the system to which access exists and the greater the likelihood of misuse, the more urgent the adjustment. This gives you a working list for the next step.

Establish role-based access profiles

Using the risk analysis as a foundation, you now establish role-based access profiles. This principle, also known as Role-Based Access Control (RBAC), ties permissions to roles rather than to individuals. This prevents permissions from being granted ad hoc and then forgotten. The least privilege principle is the guiding rule here: every user receives only the permissions needed to perform their own tasks.

1. Define the key role groups within your organization, such as employee, team lead, IT administrator, and management.
2. Determine per role group which systems, applications, and data must be accessible for day-to-day work.
3. Document each profile in an access matrix, so that future assignments can always be traced back to an approved profile.
4. Set up an approval process for exceptions, whereby temporary expansions of permissions always receive an expiry date.

A well-documented access matrix is also valuable for compliance and policy. When an auditor or regulator asks how your access management is structured, you have a clear answer at hand. Ensure the matrix is approved by both IT and management, so there is broad support for the implementation.

Implement changes in phases

Now that the profiles have been established, it is time to adjust the existing permissions. Do this in phases to limit disruptions. Adjusting all permissions at once risks employees suddenly losing access to systems they genuinely need, resulting in loss of productivity.

1. Start with the accounts that pose the highest risk: former employees, accounts with unnecessary administrator rights, and inactive service accounts.
2. Communicate in advance to the employees and managers involved which changes will be made and when.
3. Preferably implement the changes outside of office hours to minimize direct disruption to work.
4. Set up a helpdesk point where employees can go if they no longer have access to something after the change.
5. Document every change, including the date, who carried out the change, and which old permission was replaced by which new permission.

Expect reports to come in during the first week after a major change from employees who can no longer access something. That is normal and even a sign that the approach is working. Handle every report through the approval process you set up in the previous step, so that exceptions are always granted consciously and with documentation.

Check and validate the new permissions structure

After implementation, you validate whether the new permissions structure actually works as intended. This is a step that many organizations skip, but without validation you don’t know whether the changes have been implemented correctly or whether new gaps have emerged.

1. Perform spot checks by verifying for a selection of accounts whether the permissions match the established profile.
2. Test whether former permissions have actually been revoked by attempting to log in to systems that an account should no longer have access to.
3. Check the log files of your identity provider for unusual access attempts or error messages that may point to incorrect configurations.
4. Have an independent party carry out a technical review, so that you receive an objective assessment of the effectiveness of the new structure.

A technical security analysis can provide additional value here by investigating whether combinations of permissions still exist that together form an attack path. Individual permissions may each appear acceptable on their own, while in combination they still pose a serious risk.

Make access management a continuous process

Access management is not a one-time project. Every time an employee changes roles, a new system is introduced, or a supplier is granted temporary access, the permissions profile of your organization changes. Without a structural process, permissions will naturally grow out of control again, and with them the risk of a cyberattack via privilege escalation.

1. Schedule a permissions review at least every quarter in which you compare active accounts with the applicable access profiles.
2. Link role changes and departures directly to an automated process for adjusting or revoking permissions.
3. Set up alerts for unusual access patterns, such as login attempts outside of working hours or access to systems an account normally never uses.
4. Also periodically evaluate the access profiles themselves, as the needs of roles change along with the organization.

By structurally embedding access management in your security processes, you build dynamic resilience rather than a static defense that becomes outdated over time. Combine this with periodic technical tests to verify whether the measures also hold up in practice.

How Q-Cyber helps address excessive user permissions

We see across organizations of all sizes that excessive user permissions are one of the most underestimated risk factors. An attacker who compromises one account often has access to critical systems within a short time via surplus permissions, without any spectacular technical exploit being required. We help organizations address this risk structurally.

• Pentests: Our ethical hackers investigate your environment the way a real attacker would, including mapping attack paths via identity and permission weaknesses that standalone vulnerability scanners miss.
• Advisory and policy development: We help you draw up an access matrix, set up RBAC profiles, and write policy that aligns with your organizational structure.
• Continuous-Q®: Through our Continuous-Q® program, we maintain continuous visibility into changes in your environment after the initial pentest, so that new risks are identified before an attacker discovers them.
• Independent: We are not tied to software vendors or suppliers, which means our advice is always in your best interest.

Want to know how your organization currently stands when it comes to access permissions and privilege escalation? Contact us for a no-obligation conversation.

Lees meer

Which Parts of a Pentest Require Human Expertise?

Geplaatst op: 20 October 2026

Some aspects of a pentest indispensably require human reasoning. Automated tools can quickly identify known vulnerabilities, but discovering complex attack chains, understanding business context, and creatively combining multiple weaknesses into a single dangerous attack path is reserved for an experienced ethical hacker. This article answers the most frequently asked questions about where human expertise makes the difference in a penetration test.

What can automated tools not discover during a pentest?

Automated tools miss attack chains that arise from the combination of multiple small weaknesses. They scan for known patterns and published vulnerabilities, but are blind to the creative connections a human attacker makes. It is precisely those connections that are most dangerous in practice, because no individual finding is then considered critical.

To understand this, it is useful to distinguish three layers within a manual pentest:

• Layer 1: Known vulnerabilities – Published CVEs, public exploits, and missing patches. This is the domain where automated scanners excel.
• Layer 2: Individual weaknesses – Incorrect cloud configurations, overly broad permissions, identity weaknesses, and insecure application settings. Tools partially pick this up, but miss the context.
• Layer 3: Correlated attack paths – The combination of multiple small findings that together lead to full access. This is the level where automated tools structurally fall short.

A concrete example makes this clear. Suppose a scanner reports four separate findings: an SSRF vulnerability, a managed identity with broad permissions, an Azure RBAC misconfiguration, and access to a Key Vault. Each of these findings seems manageable on its own. But a human tester sees how they chain together, leading to the role of subscription owner, with full control over cloud resources as a result. Attackers don’t see isolated findings. They see attack paths.

Which pentest phases are most dependent on human reasoning?

The reconnaissance, privilege escalation, and reporting phases are most strongly dependent on human expertise. In the reconnaissance phase, an ethical hacker decides which information is relevant and which attack vectors are worth exploring. During privilege escalation, creative connections are made that no script can produce. And in reporting, technical depth is translated into actionable business advice.

During the reconnaissance phase, it is not just about gathering information, but about interpreting it. Which employee likely has overly broad permissions? Which application was recently changed and is therefore potentially vulnerable? These are questions that require context, not computing power.

In the exploitation phase, the difference is even greater. An automated tool executes known exploits against known vulnerabilities. A human tester adapts techniques to the specific environment, improvises based on what they encounter, and thinks about what an attacker with a specific goal would do. That is precisely the difference between an automated scan and red team ethical hacking.

How does an ethical hacker think differently from an automated scanner?

An ethical hacker thinks in a goal-oriented and contextual way. Rather than assessing each vulnerability in isolation, a human tester asks: what does an attacker want to achieve, and which path leads there most quickly? That goal-oriented way of thinking is fundamentally different from the pattern-recognition model of an automated scanner.

Scanners work on the basis of signatures and known rules. They compare what they find with a database of known vulnerabilities and report matches. That is valuable for basic checks, but the model is by definition reactive: a vulnerability must already be known before a tool can recognise it.

An ethical hacker works differently. They combine technical knowledge with creativity, adapt their approach based on what they discover along the way, and think from the perspective of a real attacker. They ask questions such as: why is this port open, who has access to this data, and what could I do if I had that access? That kind of reasoning cannot be automated.

Moreover, a human tester understands the business context. A misconfiguration in a test environment is less urgent than the same misconfiguration in a production environment that processes customer data. A scanner does not make that distinction. An ethical hacker does.

When is an automated scan sufficient and when is it not?

An automated scan is sufficient for basic checks on known vulnerabilities, patching, and standard configurations. As soon as an organisation wants to know whether it can withstand a targeted attacker, or when the environment is complex, cloud-based, or heavily intertwined with external parties, an automated scan falls short.

Concrete situations in which an automated scan is adequate:

• Periodic checks to verify that patches have been correctly applied
• Quick inventory of known CVEs in a stable environment
• Compliance checks where a baseline is required

Situations in which a manual penetration test is necessary:

• Complex cloud environments with multiple identities and roles
• Organisations that work with sensitive customer data or critical infrastructure
• Environments that have recently been changed or expanded
• When you want to know how far an attacker can actually get
• Managed Service Providers that bear responsibility for the security of their clients

The number of vulnerabilities found says little about how secure an organisation truly is. That is one of the most underestimated insights in cybersecurity. Ten low-severity findings that together form a critical attack path are more dangerous than one high-severity finding that connects to nothing.

Why does an annual pentest provide an incomplete picture?

An annual pentest is nothing more than a snapshot of a moving target. Cybercriminals develop new attack techniques throughout the year, while an annual test captures the situation at only one specific moment. In the months that follow, the environment changes, systems are updated, and new vulnerabilities emerge that go unnoticed until the next test.

The problem is not that an annual pentest is bad. The problem is that organisations believe they are secure after such a test. But security is not a destination. Attackers do not come around once a year. They try continuously, looking for the moment when a new vulnerability has not yet been discovered or a recent configuration change has inadvertently created a gap.

Moreover, the environment of most organisations is constantly changing. New applications are rolled out, employees receive different permissions, and cloud configurations are adjusted. Every change can open a new attack path that did not exist at the time of the previous test. A continuous testing programme closes that gap, because it measures security the way attackers also work: continuously and adaptively.

How Q-Cyber helps with human expertise in pentesting

At Q-Cyber, certified ethical hackers carry out penetration tests that go beyond what automated tools can offer. We look not only at individual vulnerabilities, but at the complete attack chain. That is precisely the level at which real attackers operate, and therefore also the level at which a good pentest must work.

What we offer:

• Manual penetration tests carried out by experienced ethical hackers who think like an attacker
• Attack path analysis in which multiple small vulnerabilities are combined into a realistic attack scenario
• Clear reporting with concrete priorities, so you immediately know where action is required
• Continuous-Q® for organisations that want continuous insight into their actual security level
• Independent advice without dependency on software vendors or other suppliers

Want to know how secure your organisation truly is? Contact us and discover what a manual pentest by Q-Cyber can do for you.

Lees meer

How Does an Attack Path Arise Within Microsoft Azure?

Geplaatst op: 19 October 2026

An attacker who gains access to your Microsoft Azure environment rarely operates through a single major vulnerability. In most cases, they combine small weaknesses, misconfigurations, and identity issues into a connected route toward your organization’s crown jewels. That is an attack path: a series of steps an attacker can take to move from limited access to full control. Understanding how such an attack path arises is the first step toward breaking it.

In this guide, you will walk through the complete process of analyzing an Azure attack path: from preparation to validation and remediation. Whether you are conducting an Azure pentest, performing a security review, or simply want to better understand how attackers think, these steps give you a concrete framework to work with.

What you need to analyze an attack path

Before you begin the actual analysis, make sure you have the right access and tools at hand. An attack path analysis of an Azure environment requires insight into the configuration of the tenant, the identities, and the permissions. Without that foundation, you cannot draw reliable conclusions.

These are the minimum requirements for a thorough analysis:

• Read access to the Azure tenant via the Azure Portal or via the Azure CLI
• Access to Microsoft Entra ID (formerly Azure Active Directory) for identity and role data
• A tool for visualizing permissions and relationships, such as BloodHound for Azure (AzureHound) or Microsoft’s own tools such as Defender for Cloud
• Insight into the scope: which subscriptions, resource groups, and services fall within the assessment?
• Documentation of existing security controls, such as Conditional Access policies and MFA settings

Also make sure you have clearly defined the scope before you start. An Azure environment can be large and complex. By determining in advance which components you are analyzing, you avoid getting lost in details that fall outside the relevant attack surface.

Map Azure identities and permissions

Most Azure attack paths start with identities. Attackers look for accounts with excessive permissions, service principals with unmanaged credentials, or managed identities that have more permissions than strictly necessary. The first step is therefore a complete overview of who or what has access to what.

1. Export all users, groups, and service principals from Microsoft Entra ID via the Azure Portal or via PowerShell with the Get-AzureADUser and Get-AzureADServicePrincipal cmdlets.
2. Inventory the role assignments per subscription and resource group via Get-AzRoleAssignment. Pay specific attention to broad roles such as Owner, Contributor, and User Access Administrator.
3. Use AzureHound to automatically collect the relationships between identities, groups, and resources and visualize them in BloodHound. This makes it easier to see indirect permissions and group memberships.
4. Identify service principals with client secrets or certificates that have not been rotated in a long time, or that have owner rights on resources.

After this step, you have a complete picture of the identity landscape within the Azure environment. You will likely encounter accounts and principals that have more rights than expected. That is normal, and exactly what attackers find too. Note all anomalies for the next step.

Identify weak links in the chain of trust

With the permission map in hand, you now look for the weak links: the points in the chain where an attacker can gain a foothold and move further from there. In Azure pentests, these are the most common weak points that attackers actively exploit.

Check the following categories systematically:

• Misconfigured Conditional Access policies: are there users or locations that are excluded from MFA? Are there legacy authentication protocols still active that bypass MFA?
• Overprivileged accounts: does an account have Owner rights on a subscription while it only manages a specific application?
• Managed identities with broad scope: a managed identity assigned to a VM with Contributor rights on the entire subscription is an attractive target.
• Public storage with sensitive data: Azure Blob Storage containers that are publicly accessible and contain configuration files, credentials, or certificates.
• Unmanaged app registrations: applications in Entra ID with high API permissions and credentials that are no longer actively managed.

Link each weak link to the identities and permissions you inventoried in the previous step. This way you start to see the outlines of possible attack paths: an attacker who gains access to account A can, via group membership B, take over the rights of principal C, and thereby reach resource D.

Simulate the attack route step by step

Now that you know where the weak links are, it is time to reason like an attacker. The goal of this step is not to test arbitrary vulnerabilities, but to determine which combination of weaknesses leads to a working attack path toward a valuable target, such as a database with customer data, a key vault with secrets, or Global Administrator rights in Entra ID.

Walk through the simulation as follows:

1. Choose a realistic starting point for the attacker: a compromised user account with limited rights, or a leaked service principal credential.
2. Define the end goal: which resource or permission level is most valuable to an attacker in this environment?
3. Map the route from starting point to end goal, step by step. Which permissions are needed? Which intermediate resources or identities are used?
4. Technically validate each step: is the permission actually present? Can the attacker perform the action without additional authentication or approval?
5. Pay specific attention to privilege escalation opportunities: situations where an attacker with limited rights can grant themselves higher rights, for example via a misconfigured role assignment or an overprivileged managed identity.

A common Azure attack path in practice looks like this: an attacker compromises a user account without MFA via a phishing attack, discovers that this account is a member of a group with Contributor rights on a subscription, finds via that access a storage account with a configuration file containing credentials for a service principal with Owner rights, and then takes full control of the environment. Each step individually seems manageable, but the combination makes it dangerous. More background on how attackers build these kinds of routes can be found in our cyber research.

Validate and document the attack path

After identifying a potential attack path, thoroughly validate the finding before drawing conclusions. An attack path that seems technically possible but is blocked in practice by a compensating control is not a working path. Conversely, a path you overlook because you have not validated a step can be a critical risk.

1. Actually execute each step in the attack route in a controlled test environment, or verify the permissions via the Azure Portal and CLI without actually triggering the action.
2. Check whether compensating controls block the path: are there Azure Policies that prohibit certain actions? Are there alerts configured that would make the attack route visible?
3. Document the path visually: draw the route with the involved identities, permissions, and resources. BloodHound makes this automatically insightful for complex environments.
4. Classify the severity based on impact (what can an attacker achieve?) and exploitability (how difficult is the path to traverse?).

Good documentation is essential, not only for the people who need to resolve the attack path, but also for management that needs to set priorities. A clearly documented attack path shows why a combination of weaknesses is more dangerous than the individual components suggest. That is precisely the difference between a list of individual vulnerabilities and a real attack path analysis.

Close the attack path with targeted measures

With the attack path validated and documented, the final step is to actually close the route. The key here is to prioritize: not every weak link needs to be resolved immediately, but the link that most effectively breaks the attack path has the highest urgency. Focus on the step in the chain that is least complex to fix and has the greatest impact.

1. Remove or restrict overprivileged role assignments via the principle of least privilege: give accounts and service principals only the rights they actually need.
2. Enforce MFA for all accounts without exception, and block legacy authentication protocols via Conditional Access.
3. Rotate credentials of service principals and app registrations identified as weak links, and set up automatic rotation where possible.
4. Remediate misconfigurations in storage accounts, key vaults, and other resources that are unintentionally accessible.
5. Set up detection rules via Microsoft Defender for Cloud or Microsoft Sentinel that monitor the critical steps in the attack path, so that an attempted abuse becomes visible.

After implementing the measures, verify that the attack path has actually been closed by walking through the route again. A fix that looks correct on paper but has not been properly implemented in practice gives a false sense of security. Repeat the validation step until the path is demonstrably blocked. Keep in mind that Azure environments are constantly changing: new resources, adjusted permissions, and new accounts can open a new attack path as early as tomorrow. One-time testing is therefore rarely sufficient. More about how to approach this structurally can be found on the page about Continuous-Q.

How Q-Cyber helps with analyzing Azure attack paths

An attack path analysis of a Microsoft Azure environment requires technical depth, knowledge of identity and permission structures, and the ability to reason like a real attacker. That is precisely what we specialize in. We do not run automated scans that produce a list of individual vulnerabilities, but investigate how an attacker can combine various weaknesses into a working attack path toward your organization’s crown jewels.

What we concretely offer for Azure environments:

• A manual pentest focused on Azure identities, permissions, and cloud misconfigurations
• Full attack path analysis including visualization of the attack route
• Insight into privilege escalation opportunities and weak links in the chain of trust
• A clear report with concrete priorities, focused on breaking the most critical attack paths
• Pragmatic remediation advice tailored to your specific environment and organization
• Optional: continuous monitoring of new attack paths via our red team and Continuous-Q program

Want to know how your Azure environment stands and which attack paths already exist? Get in touch and we will look together at the best approach for your situation.

Lees meer

What Is CVSS and How Is the Severity of a Vulnerability Determined?

Geplaatst op: 18 October 2026

When a new vulnerability in software is discovered, the immediate question arises: how serious is this, really? Is it a problem that needs to be resolved today, or can it wait until the next maintenance cycle? To answer that question in a structured and consistent way, the Common Vulnerability Scoring System exists, better known as CVSS. In this article you will learn what CVSS is, how the score is calculated, what the severity categories mean, and how to apply CVSS wisely within your own security practice.

We build the knowledge step by step: from the origin of the system, through the technical workings, to the practical application. By the end, you will understand not only what a CVSS score says, but also what it does not say, and why that distinction is crucial for good cybersecurity.

What is CVSS and where does it come from?

The Common Vulnerability Scoring System is an open standard for assessing the severity of vulnerabilities in software and systems. The system provides a standardized way to compare vulnerabilities, regardless of the type of system or vendor where they were found.

CVSS was developed by the Forum of Incident Response and Security Teams (FIRST) and was first published in 2005. Since then, the system has been revised several times. The most widely used version is CVSS 3.1, but CVSS 4.0 is now available and introduces further refinements for more modern IT environments. The scores are published through the National Vulnerability Database (NVD) of the US government, which maintains a CVSS score for virtually every known vulnerability.

The goal of CVSS is simple: to provide a common language so that security teams, vendors, and organizations around the world can discuss the severity of a vulnerability in the same way. Without such a standard, every party would use its own measuring stick, making comparison and prioritization virtually impossible.

How does the CVSS score work and what do the base metrics measure?

A CVSS score is a number between 0.0 and 10.0, where a higher score indicates a more severe vulnerability. That score is calculated based on a set of metrics, divided into three groups: the base metrics, the temporal metrics, and the environmental metrics. The base metrics form the foundation and are applied most consistently.

The base metrics: what is being measured?

The base metrics describe the intrinsic characteristics of a vulnerability, independent of the specific context of an organization. They are divided into two categories:

• Exploitability: How easy is the vulnerability to exploit? This includes factors such as the attack vector (does the attacker need to be on the network, or can it be done via the internet?), the complexity of the attack, and whether special privileges or user interaction are required.
• Impact: What is the potential damage if the vulnerability is exploited? This is measured along three axes: confidentiality (can data be viewed?), integrity (can data be modified?), and availability (can the system be disrupted?).

A concrete example: a vulnerability that can be exploited remotely without authentication and grants full access to a system scores high on virtually all base metrics. A vulnerability that can only be exploited locally and exposes only limited information scores considerably lower.

Temporal and environmental metrics

In addition to the base metrics, there are temporal metrics that take into account the current exploitation status of a vulnerability. Is there already a working exploit available? Does a patch exist? These factors can adjust the effective score up or down. The environmental metrics go one step further and allow organizations to adjust the score based on their own IT environment and the value of the affected systems. For more depth on how vulnerabilities are tested in practice, it is useful to understand how a professional pentest works.

What do the severity categories mean in practice?

The numerical CVSS score is translated into five severity categories, which help with quickly assessing priority:

• None (0.0): No vulnerability or negligible risk.
• Low (0.1 – 3.9): Limited impact; exploitation is difficult or has few consequences.
• Medium (4.0 – 6.9): Moderate impact; exploitation requires specific circumstances.
• High (7.0 – 8.9): Serious vulnerability with significant potential damage.
• Critical (9.0 – 10.0): Maximum severity; immediate action required.

In practice, security teams use these categories as a first filter when prioritizing patches. A Critical vulnerability in a publicly accessible system typically receives the highest priority and requires swift action. A Low vulnerability in an internal system without sensitive data can be included in the regular maintenance cycle.

It is important to realize, however, that the severity category is a starting point, not a final verdict. The actual urgency always depends on the broader context, such as which system is involved, who has access to it, and how the system is connected to the rest of your environment.

Why is a high CVSS score not always the greatest danger?

This is perhaps the most important lesson you can take away from this article: a high CVSS score does not automatically mean that a vulnerability poses the greatest risk to your organization. And conversely, a low score can sometimes be misleading.

CVSS measures the severity of a vulnerability in isolation. The system does not account for the way vulnerabilities can be combined into an attack path. An attacker who has access to a system does not always need to exploit the most critical vulnerability. Sometimes a combination of a medium-score vulnerability, an incorrect permission setting, and a misconfiguration in the cloud is together more dangerous than a single standalone Critical vulnerability.

Consider the following: a poor-quality lock on a back door that nobody uses is less urgent than a slightly better lock on the front door that is always left open. CVSS tells you how bad the lock is, but not which door is most attractive to a burglar. For that insight you need a broader perspective, such as that provided by red team exercises or in-depth security research.

A common mistake is simply working through all vulnerabilities in order of CVSS score. You can resolve twenty Medium vulnerabilities and still remain exposed, because the combination of remaining low-score findings together forms a working attack path.

Applying CVSS within your own vulnerability management

Building on an understanding of what CVSS measures and what it does not measure, the next step is: how do you use the system effectively in practice? CVSS is an excellent tool when you treat it as one input in a broader assessment, not as the sole measure.

Effective vulnerability management based on CVSS works as follows:

1. Start with the base metrics as a filter: Use the CVSS score to create an initial prioritization. Critical and High vulnerabilities deserve prompt attention, especially if they are present in publicly accessible systems.
2. Add context: Ask yourself which system is involved, how sensitive the data it processes is, and how the system is connected to the rest of your environment. A Critical vulnerability in an isolated test system is less urgent than a Medium vulnerability in your customer database.
3. Look at attack paths, not just individual findings: Analyze how vulnerabilities can be combined. Are there combinations of low and medium vulnerabilities that together form a serious risk?
4. Keep an eye on the temporal metrics: If there is an active exploit in circulation for a vulnerability, that significantly increases the urgency, even if the base score is not extremely high.
5. Ensure continuous monitoring: Your environment changes constantly. New systems are added, configurations change, new vulnerabilities are discovered. A one-time assessment is therefore always just a snapshot in time. See how continuous security monitoring can help with this.

The goal is not to remediate every vulnerability with a high CVSS score first, but to identify the vulnerabilities that pose the greatest actual risk to your organization.

How Q-Cyber helps with assessing vulnerabilities

CVSS provides a valuable standard for assessing the severity of vulnerabilities, but it does not tell the full story. At Q-Cyber we understand that the real threat often does not lie in a single high score, but in the combination of vulnerabilities, misconfigurations, and permissions that together form an attack path.

This is how we help organizations go beyond the CVSS score alone:

• Our ethical hackers perform manual pentests that go beyond automated vulnerability scans, and discover attack paths that tools structurally miss.
• We translate technical findings into concrete priorities, so you know exactly which action has the greatest impact.
• Through our Continuous-Q program, we keep your security up to date throughout the year, not just on the day of the test.
• We provide independent advice, without dependency on software vendors or other suppliers.

Want to know how vulnerable your organization truly is and which risks deserve priority? Contact us for a no-obligation conversation.

Lees meer

What Are Identity Weaknesses?

Geplaatst op: 17 October 2026

Identity weaknesses are vulnerabilities in the way an organization manages digital identities: user accounts, service accounts, permissions, and access roles. They arise when identities are poorly managed, granted excessive privileges, or insufficiently monitored. Unlike technical vulnerabilities such as unpatched software, identity weaknesses are often invisible in standard security scans. In this article, we answer the most frequently asked questions about identity weaknesses and what you can do about them.

How do identity weaknesses arise in an organization?

Identity weaknesses almost always develop gradually, as a byproduct of growth and change within an organization. When employees change roles, systems are expanded, or new cloud environments are set up, permissions and accounts are rarely maintained as carefully as they are created. The result is an accumulation of unnecessary access, forgotten accounts, and unclear responsibilities.

Concrete causes include:

• Onboarding and offboarding without a strict process: accounts remain active long after an employee has left
• Accumulated permissions: with each new role or project, a user receives additional access that is never revoked
• Service accounts without an owner: technical accounts for applications or automation are created and then forgotten
• Cloud migrations without an identity policy: during the transition to Azure or Microsoft 365, permissions are often set too broadly to enable fast onboarding

Each of these situations may seem manageable on its own. But over time, and especially in a growing organization, they together form a complex web of weak identities that is difficult to oversee.

Which types of identity weaknesses are most common?

The most common identity weaknesses are excessive access permissions, dormant accounts, poorly managed service accounts, and misconfigurations in cloud identities such as Azure Active Directory. These categories occur in virtually every organization, regardless of size or sector.

A closer look at the most frequently observed forms:

• Excessive permissions: users or accounts have more rights than necessary for their role, violating the principle of least privilege
• Dormant accounts: accounts of former employees, interns, or vendors that are still active in the system
• Privileged accounts without MFA: administrator accounts that are not protected with multi-factor authentication
• Misconfigured Azure roles: incorrect assignments of Azure RBAC roles that unintentionally grant access to sensitive resources such as Key Vaults
• Shared accounts: multiple individuals using the same account, making it impossible to trace individual actions

What these weaknesses have in common is that they are rarely directly visible in a standard vulnerability scan. They only surface when someone actively investigates how identities and permissions are configured.

Why are identity weaknesses so attractive to attackers?

Identity weaknesses are attractive to attackers because they provide access without requiring a technical exploit. An attacker who takes over an account with excessive permissions moves through the network as a legitimate user. Security systems raise no alarm, because technically nothing is going wrong.

Attackers do not think in isolated vulnerabilities. They look for attack paths: combinations of small weaknesses that together lead to significant access. A classic example is a chain in which an attacker reaches a managed identity via a Server-Side Request Forgery (SSRF), then reads out a Key Vault via Azure RBAC permissions, and ultimately obtains subscription owner rights. None of these steps needs to be critical on its own. Together, they are.

This is precisely why identity security is such a high priority for attackers: identities form the bridge between technical systems and the data or infrastructure they want to reach. Moreover, identity-based attacks are harder to detect, because they mimic normal user behavior.

What is the difference between an identity weakness and a vulnerability?

A vulnerability is a technical flaw in software or systems, such as an unpatched CVE or a bug in the code. An identity weakness is a weak point in how access and identities are managed: not a bug, but a configuration or policy problem. The distinction matters, because each requires a different approach.

Vulnerabilities are generally discoverable with automated tools that query known CVE databases. Identity weaknesses are not. They require insight into the organizational structure, the way roles are configured, and how accounts are used in practice. A scanner does not see an account with broad permissions as a problem. An attacker does.

From the perspective of an offensive security specialist, identity weaknesses operate at the second level of a three-layer model:

1. Layer 1: known vulnerabilities and CVEs that are resolved through patches
2. Layer 2: individual weaknesses such as misconfigurations, excessive permissions, and identity weaknesses
3. Layer 3: correlated attack paths where multiple layer 2 findings are combined into a working attack chain

Identity weaknesses are therefore not bugs. They are the result of decisions, processes, and growth that are not kept up to date.

How can you detect identity weaknesses in your organization?

Detecting identity weaknesses requires a combination of technical analysis and organizational insight. An automated scan is not sufficient: you need a method that actively investigates how identities, permissions, and configurations relate to each other and what attack paths are hidden within them.

Effective methods for identifying identity weaknesses include:

• Manual pentest with an identity focus: an ethical hacker investigates how accounts, roles, and permissions are configured and which combinations an attacker can exploit. Read more about this approach on the page about pentesting
• Azure AD and RBAC audit: a structured analysis of who has access to what, and whether that access is still justified
• Red team exercises: simulated attacks in which an attacker actively attempts to abuse identities to move deeper into the network. Explore the possibilities of red teaming
• Access review: periodic checks in which line managers confirm whether their employees still have the correct permissions

The most important principle: you cannot defend what you do not test. Identity weaknesses remain invisible as long as no one actively goes looking for them.

Which steps reduce the risk of identity weaknesses?

Reducing the risk of identity weaknesses starts with implementing the least privilege principle, actively managing the account lifecycle, and monitoring anomalous behavior. No single measure eliminates the risk entirely, but the combination of policy, technology, and awareness makes a significant difference.

Concrete steps organizations can take:

• Enforce least privilege: give users only the permissions they need for their current role, and nothing more
• Require MFA on all accounts: especially for privileged accounts and external access, multi-factor authentication is not optional but mandatory
• Tighten the offboarding process: ensure that accounts are immediately disabled or removed as soon as an employee or vendor leaves
• Periodic access reviews: have permissions regularly confirmed by the responsible managers
• Document service accounts: every technical account has an owner, a purpose, and an expiration date
• Audit cloud configurations: Azure RBAC roles and other cloud identities require specific attention, especially after migrations or expansions

Policy alone is not enough. The steps above are most effective when combined with regular technical testing. Read more about how to structurally embed this in your organization on the page about compliance and policy.

How Q-Cyber helps with identity weaknesses

Identity weaknesses are difficult to find without the right expertise and approach. At Q-Cyber, we combine technical depth with organizational insight to discover where identities and permissions form an attack path, even when no individual finding appears critical on its own.

What we concretely offer:

• Manual pentests in which our ethical hackers actively search for identity-based attack paths in your environment, including Azure AD, RBAC configurations, and service accounts
• Red team exercises in which we act as a simulated attacker and attempt to abuse identities to move deeper into the network
• Continuous-Q® for organizations that want not just a snapshot on the day of testing, but continuous insight as their environment evolves
• Advice and policy development around identity security, from drafting access policies to guiding access reviews

Want to know how your organization currently stands? Get in touch and we will look together at the best approach.

Lees meer

How Can MSPs Become Part of a Cyberattack?

Geplaatst op: 15 October 2026

Managed service providers are a prime target for cybercriminals, and that is no coincidence. A successful attack on a single MSP gives attackers immediate access to dozens or even hundreds of client environments at once. That makes an MSP not only attractive, but also particularly vulnerable: the impact of a single breach reaches far beyond the organization itself.

In this article you will find a step-by-step breakdown of what a cyberattack on an MSP looks like, where the weakest links in your environment are, and what you can concretely do to strengthen your defenses. Whether you are just starting to improve your MSP cybersecurity or want to sharpen your existing approach, this guide offers a practical starting point.

How cybercriminals use an MSP as a gateway

Understanding how an attacker thinks is the first step toward a better defense. Cybercriminals do not choose their target at random. They look for the place where a single breach causes the most damage, and an MSP fits that picture perfectly. By compromising one MSP, an attacker gains access to the systems, networks, and data of all connected clients. That is the core of a supply chain attack via an MSP.

An attacker rarely starts by firing off exploits. During the reconnaissance phase, they first examine the structure of the organization: which vendors have access, which identities exist, what permissions accounts hold, and what gaps exist between the security measures in place. Only once they have a clear picture of the environment do they choose their attack path. The most common entry points at an MSP are:

• Compromised administrator accounts with excessive privileges
• Insufficiently secured remote access tools such as RMM software
• Weak or reused passwords without multi-factor authentication
• Outdated software with known vulnerabilities
• Insecure API connections to client environments

What makes this extra dangerous is that attackers do not look at individual findings. They see attack paths: combinations of multiple small weaknesses that together lead to full access. A misconfiguration in Azure, combined with excessive permissions and a weak identity, can escalate step by step to complete control over a cloud subscription. Each component on its own may seem low risk; together they form a critical vulnerability.

Identify the weakest links in your MSP environment

Now that you know how attackers operate, the next step is mapping your own vulnerabilities. Many MSPs think they are secure because they have run a vulnerability scan or worked through a list of findings. But a list of resolved CVEs says little about how secure you actually are. The real risks often lie deeper.

Work through your analysis across three levels, from simple to complex:

1. Known vulnerabilities (Layer 1): Verify that patches have been applied correctly and known CVEs have been remediated. This is the baseline layer every MSP must have in order.
2. Individual weaknesses (Layer 2): Investigate incorrect cloud configurations, excessive permissions, identity weaknesses, and insecure application settings. These are often missed by automated scanners.
3. Correlated attack paths (Layer 3): Map out what happens when you combine multiple small weaknesses. Only at this level do you see how an attacker truly operates.

Conduct an internal audit that specifically examines which accounts have access to client environments, how that access is configured, and whether unnecessary privileges exist. Also document which external parties and tools connect to your infrastructure. Insight into your attack surface starts with fully mapping everything that is connected.

Ask yourself the following questions:

• Which accounts have administrator rights they do not need?
• Are all remote access tools protected with MFA?
• Which client environments are reachable from a single compromised account?
• Are there misconfigurations in your cloud platform that could escalate access?

Simulate an attack to expose blind spots

An internal audit gives you a good starting point, but does not expose everything. To know whether your environment can withstand a real attack, you need to simulate that attack. This is where a professional pentest or red team exercise becomes indispensable. An automated vulnerability scan finds known CVEs, but a human ethical hacker thinks like an attacker and discovers the combinations of weaknesses that tools systematically miss.

Carry out the simulation in layered steps:

1. External reconnaissance: Investigate what an attacker can see from the internet, including open ports, public services, and visible technology stacks.
2. Access attempt: Try to gain access through realistic methods, such as phishing, password attacks, or abuse of remote tools.
3. Privilege escalation: Once you have a foot in the door, investigate how far you can get with the access obtained. Can you move from one account into client environments?
4. Lateral movement: Test whether segmentation works. Can an attacker move from one client environment to another?

After the simulation you will have a realistic picture of your actual attack surface. Not only which vulnerabilities exist, but also which attack paths an attacker can realistically follow. Red teaming goes further than a standard pentest: a simulated attacker attempts to break in by every possible means, including social engineering and physical access attempts.

Strengthen access control and segmentation step by step

With the findings from your simulation in hand, you can take targeted action. The most impactful improvements for an MSP almost always lie in the areas of access control and network segmentation. This is also where the greatest opportunity for attackers exists, so this is where you must start.

Implement the following measures in order of priority:

1. Implement the principle of least privilege: Every account receives only the permissions that are strictly necessary for the task. Remove all unnecessary administrator rights.
2. Enable MFA on all accounts: Without exception, including service accounts and accounts that have access to client environments.
3. Segment client environments: Ensure that a compromised account in one client environment does not grant access to other clients. Use separate credentials and network segments per client.
4. Restrict and monitor remote access: Use only approved RMM tools, enforce strict access controls, and log all sessions.
5. Remediate misconfigurations in the cloud: Review Azure or other cloud platform settings for overly permissive roles, unsecured storage, and incorrect identity settings.

After each change, verify that the measure has actually produced the intended effect. An access rule that looks correct on paper may behave differently in practice than expected. Test each adjustment before moving on to the next step.

Validate your defenses with continuous monitoring

Strengthening access control and segmentation is not a one-time action. Your environment changes constantly: new applications are added, accounts are created, permissions are adjusted, and new vulnerabilities are discovered. An annual pentest gives you a snapshot, but says nothing about how secure you are for the remaining 364 days.

Establish a structural monitoring process to validate your defenses:

1. Monitor access logs continuously: Set up alerting for anomalous behavior, such as login attempts outside business hours, unusual locations, or privilege escalation.
2. Repeat vulnerability analyses after every significant change: New cloud resources, new applications, or changed permissions require a fresh assessment.
3. Conduct periodic attack simulations: Not just annually, but aligned with the pace of change in your environment.
4. Evaluate attack paths, not just individual findings: After each round, verify that the combinations of weaknesses previously identified as risks have actually been resolved.

The goal of continuous monitoring is not to produce reports, but to maintain insight. Continuous testing and monitoring ensures that you not only know how secure you were on the test day, but also how secure you are while attackers develop new techniques. Verify your defenses by regularly checking whether the attack paths identified earlier are still closed, even after your environment has changed.

How Q-Cyber helps secure your MSP

As an MSP you carry a special responsibility: your security is in effect also the security of all your clients. We at Q-Cyber understand that responsibility and have specifically tailored our services to the challenges MSPs face. We help you not only find vulnerabilities, but also understand how attackers combine them into working attack paths.

What we concretely do for you:

• Manual pentests in which our ethical hackers think like a real attacker and expose correlated attack paths that automated tools miss
• Red team exercises in which we carry out a full attack simulation, including social engineering and escalation scenarios specifically for MSP environments
• Continuous-Q®, our program for ongoing security, in which we follow your environment after a thorough baseline pentest and flag new risks as soon as they emerge
• Independent advice on access control, segmentation, and cloud configurations, without dependency on software vendors or other suppliers

Want to know how vulnerable your MSP environment really is? Contact us for a no-obligation conversation and discover where the greatest risks lie for your organization and your clients.

Lees meer

Do You Need to Retest After a Major Software Release?

Geplaatst op: 15 October 2026

Yes, in most cases you need to retest after a major software release. A pentest is a snapshot in time: as soon as the software changes, the attack surface changes too. New features, modified authentication logic, or updated API integrations can introduce vulnerabilities that didn’t exist at the time of the previous test. The questions below help you determine when, how, and how often you need to do this.

Which changes in a release justify a new pentest?

Not every software update calls for a full new penetration test, but certain changes expand the attack surface to such an extent that testing becomes necessary. Think of new authentication or authorization logic, new external integrations or API connections, changes in how data is stored or processed, and new user roles with associated permissions. For these types of releases, retesting is not a luxury but a requirement.

A useful rule of thumb: ask yourself whether an attacker has different opportunities with the new release than before. If the answer is yes, that justifies a new test. Concrete examples of release changes that almost always require a pentest after a software release:

• New login methods or SSO integrations
• Addition of payment functionality or integrations with financial systems
• Changes to cloud configurations or infrastructure (for example new Azure roles or S3 buckets)
• Expansion of the system to new user groups or external parties
• Migrations to a new technology stack or framework

Minor bug fixes or purely visual changes generally do not justify a full pentest. But even then, a targeted vulnerability scan can be useful to check whether any unintended side effects have occurred.

How does a delta pentest differ from a full pentest?

A delta pentest focuses exclusively on the changes relative to a previously tested version of the software. A full pentest reassesses the entire system, including components that have not changed. The difference lies in scope, turnaround time, and cost: a delta pentest is faster and cheaper, but assumes that the previously tested components are still secure.

That last assumption carries risks. Even unchanged components can become vulnerable due to new attack techniques, modified dependencies, or a different environment. A delta pentest is therefore most suitable when:

• The previous full pentest was conducted recently (preferably no more than six months ago)
• The changes are well documented and clearly defined
• No major infrastructural changes have taken place alongside the release

Are there doubts about the scope of the changes, or has the previous test been some time ago? Then a full penetration test is preferable. A delta pentest saves time and money, but should never become an excuse to test less thoroughly than the situation requires.

Why is an annual pentest insufficient after frequent releases?

An annual pentest is insufficient when an organisation deploys software multiple times a year, because each new release potentially introduces new vulnerabilities. The test results from January are already outdated by June if five releases have taken place in the meantime. An annual penetration test then provides nothing more than a snapshot of a moving target.

Cybercriminals do not operate on an annual schedule. They continuously scan for new weaknesses, including in software that has just been released. Organisations that release regularly but only test once a year run an elevated risk for most months of the year without knowing it.

The problem grows as releases become more frequent. Teams working with agile or DevOps methodologies can deploy changes weekly or even daily. In that context, the question is not whether you should test more often, but how you organise that structurally. Continuous penetration testing provides an answer: instead of an annual snapshot, you create an ongoing picture of your security posture, aligned with the pace of your development cycle.

What is the difference between a pentest and a vulnerability scan after a release?

A vulnerability scan after a release automatically detects known vulnerabilities based on a database of public security issues. A pentest goes further: a human ethical hacker actively investigates how vulnerabilities can be combined into an attack path, just as a real attacker would. A scan tells you what is wrong; a pentest shows you what is possible.

This distinction is crucial when assessing a new release. Suppose an update introduces a new API integration with an incorrect permission configuration. A vulnerability scanner may not flag that configuration as critical, because the finding scores low in isolation. A human pentester, however, sees how that misconfiguration can be combined with an existing weakness elsewhere in the system, together leading to full access to sensitive data.

Attackers think in attack paths, not in isolated findings. That is precisely why an automated scan after a release is useful as a first check on basic hygiene, but a manual pentest is necessary to understand what an attacker can truly achieve. Read more about this difference on the page about cyber research.

How do you structurally embed pentesting into your release process?

Structurally embedding pentesting into a release process means determining in advance which types of changes require which level of testing, and recording those agreements in your development cycle. The goal is that security is not an afterthought following a release, but a fixed step in the process itself.

A practical approach works with three levels:

1. Automated scans with every release: Integrate vulnerability scanning into your CI/CD pipeline so that known vulnerabilities are automatically detected before production.
2. Delta pentests for significant changes: Establish clear criteria for which changes require a targeted test. Document the scope per release and have an ethical hacker assess the new components.
3. Full pentests at fixed intervals: Schedule a full penetration test at least once or twice a year, regardless of release frequency. This catches blind spots that fall outside the scope of delta tests.

Organisations with a high release frequency benefit from a model in which pentests are scheduled as part of sprint planning or the release calendar, not as a separate activity afterwards. This prevents security from always lagging behind.

An additional benefit of this approach is that teams build security awareness as a natural part of the development process. Developers who know their code will be tested think differently about the choices they make while building.

How Q-Cyber helps with pentesting after a software release

At Q-Cyber, we understand that a software release is not the endpoint of your security effort, but a new starting point. We help organisations structure and implement pentesting effectively, tailored to their release cadence and risk level. What we offer:

• Manual pentests carried out by certified ethical hackers, focused on attack paths rather than isolated findings
• Delta pentests for targeted assessment of new or modified functionality after a release
• Continuous-Q®: an ongoing testing programme for organisations that want continuous insight into their actual vulnerabilities, not just once a year
• Independent advice on how to structurally embed security into your development process, without dependency on software vendors
• Clear reports with concrete priorities, so that after every test you immediately know where action is required

Want to know whether your organisation needs to be retested after a recent release, or how to structurally set up pentesting? Get in touch with us and we will be happy to think along with you.

Lees meer

Why a CVSS Score Doesn’t Always Tell You How Much Risk You Actually Face

Geplaatst op: 14 October 2026

When a security scanner reports a vulnerability with a CVSS score of 9.8, alarm bells start ringing at many organizations. Understandable, as such a high score suggests a critical risk. But does a score of 9.8 automatically mean your organization is in great danger? Not necessarily. The CVSS score tells you something about the severity of a vulnerability in general, but says little about the actual risk you face in your specific situation.

In this article, we explain step by step what a CVSS score exactly is, how it is calculated, and why it is only one piece of a much larger puzzle. We build from the basic principles to practical tools for prioritizing vulnerabilities based on actual risk, not just a number.

What is a CVSS score and how is it calculated?

CVSS stands for Common Vulnerability Scoring System and is a standardized method for assessing the severity of a security vulnerability. The system assigns scores from 0.0 to 10.0, with a higher score indicating a more severe vulnerability. CVSS is used worldwide by security teams, software vendors, and auditors as a common language for risk assessment.

The score is calculated based on a series of metrics, divided into three groups:

• Base Score: The inherent properties of the vulnerability itself, such as how easy it is to exploit, whether authentication is required, and what impact a successful attack has on confidentiality, integrity, and availability.
• Temporal Score: Factors that change over time, such as whether a public exploit is already available and whether a patch exists.
• Environmental Score: Adjustments based on the specific environment of an organization, such as how critical the affected system is within your infrastructure.

In practice, the Environmental Score is rarely fully completed. Most tools only report the Base Score, which is immediately one of the biggest sources of misinterpretation in vulnerability management.

How the CVSS score ignores the context of your environment

The Base Score describes a vulnerability as if it exists in a vacuum, detached from any specific environment. That is useful for comparison, but dangerous if you use the score directly as a prioritization basis for your organization.

Consider this: a vulnerability has a CVSS score of 9.8 because it is remotely exploitable without authentication. But if the affected system sits behind a firewall that fully blocks external access, the chance that an attacker actually reaches this system is minimal. The score does not change, but your risk does.

The reverse also applies. A vulnerability with a score of 4.0, which looks “medium” on paper, can be catastrophic in your environment if the affected system has access to sensitive customer data or drives critical business processes. The CVSS score does not account for this, unless you carefully complete the Environmental Score — something that rarely happens structurally in day-to-day practice.

During a thorough pentest, an ethical hacker does not only look at individual scores, but specifically at how a vulnerability fits within the broader context of your systems and processes.

Exploitability and threat context as missing puzzle pieces

Two factors that the CVSS score structurally underrepresents are real-world exploitability and threat context. Together, they largely determine how urgent a vulnerability truly is.

Real-world exploitability

Not every vulnerability with a high CVSS score is also actively being attacked. Some vulnerabilities are technically complex to exploit and require specific access or circumstances that rarely occur. Others already have ready-made exploit tools available that even inexperienced attackers can deploy. This difference is enormously relevant for prioritization, but the Base Score does not make this distinction.

Threat context

Threat context is about the question: who wants to attack you, and for what purpose? A vulnerability in industrial control systems is particularly relevant if you are an energy company, but barely relevant if you run an online store. Threat actors target specific sectors, technologies, and organization types. A risk assessment that does not account for who would want to attack you and why is missing a crucial piece of the picture.

Building on what we established earlier: the CVSS score describes the vulnerability, but not the attacker. Attackers do not think in scores. They think in attack paths: which combination of weaknesses will get them to their goal? That is a fundamentally different perspective from a list sorted by CVSS score.

How do you prioritize vulnerabilities based on actual risk?

Effective risk assessment requires more than a single number. A workable prioritization framework combines the CVSS score with additional factors that determine the actual impact in your environment.

Consider the following questions for each vulnerability:

1. Is the system reachable by an attacker? A vulnerability on an internal system without external access is harder to exploit than a vulnerability on a publicly accessible web server.
2. How critical is the affected system? Systems that process customer data, handle payments, or drive critical processes deserve higher priority than test environments.
3. Is there an active exploit available? If public exploit code exists, the barrier for attackers is much lower. This significantly increases urgency.
4. Is the vulnerability part of an attack path? A vulnerability with a low score can become dangerous if, combined with other weaknesses, it leads to full access to critical systems.
5. Is there a patch or workaround available? If a fix exists, the priority to apply it quickly is higher than when you depend on a vendor.

This kind of context-driven analysis aligns with what is known in the security world as risk-based vulnerability management: not patching in order of CVSS score, but based on actual risk to your organization.

Common mistakes when interpreting CVSS scores

Even experienced security teams regularly make the same mistakes when working with CVSS scores. By knowing them, you can avoid them.

Mistake 1: Treating the Base Score as the definitive risk

The most common mistake is using the Base Score as the sole measure for prioritization. As discussed earlier, the Base Score completely ignores your specific environment. A score of 9.8 on a system that no one can reach is less urgent than a score of 5.0 on a publicly accessible system with sensitive data.

Mistake 2: Only looking at individual vulnerabilities

Attackers do not see isolated findings. They see attack paths. An incorrect Azure configuration, overly broad permissions, and an unsecured application setting may each be scored low on their own. But combined, they can lead to full access to cloud resources. Those who only look at individual CVSS scores completely miss this combined threat.

Mistake 3: Wanting to patch everything at once

Organizations that want to immediately fix every vulnerability with a high CVSS score quickly become overwhelmed. Without prioritization based on actual risk, security teams get consumed by urgency that exists on paper but is limited in practice. The result is that the truly dangerous vulnerabilities are sometimes addressed too late.

Mistake 4: Ignoring the Temporal and Environmental Score

Many tools display only the Base Score by default. The Temporal Score and Environmental Score exist precisely to refine the score to your situation. Completing the Environmental Score takes time, but delivers a considerably more realistic picture of your actual risk.

From CVSS score to a continuous risk picture

Building on everything covered above: a CVSS score is a starting point, not an endpoint. Those who base their vulnerability management on an annual scan and a sorted list of scores have insight at that one moment, but do not know what changes afterward.

IT environments are constantly in motion. Applications are updated, accounts added, permissions changed, and new cloud resources created. Every change can introduce new vulnerabilities or place existing vulnerabilities in a different light. A vulnerability that had low priority last month can suddenly become part of a dangerous attack path due to a configuration change.

Effective vulnerability management therefore requires a continuous risk picture: regular revision of priorities, combined with insight into how your environment changes and which new threats become relevant. That is fundamentally different from an annual snapshot.

Moreover, a continuous risk picture requires the ability to recognize attack paths, not just individual vulnerabilities. That demands the mindset of an attacker: who wants to target me, how would they go about it, and which combination of weaknesses would they exploit? Automated scanners do not answer that question. Human reasoning does.

How Q-Cyber helps with risk assessment beyond the CVSS score

At Q-Cyber, we believe that a CVSS score only gains meaning when it is placed in the context of your organization, your environment, and the threats that are relevant to you. We help organizations move from a list of vulnerabilities to a realistic and actionable risk picture.

Concretely, we do this through:

• Manual pentests in which our ethical hackers not only identify individual vulnerabilities, but also investigate how those vulnerabilities can be combined into attack paths that are truly dangerous.
• Attack path analysis that makes clear which combinations of weaknesses, misconfigurations, and permissions pave the way for an attacker to critical systems, even when individual findings score low.
• Context-driven prioritization so your security team knows which vulnerabilities are truly urgent in your specific environment, instead of working based on a generic score.
• Continuous insight through our Continuous-Q® program, so you are not dependent on an annual snapshot but maintain an up-to-date risk picture that moves with your environment.

Want to know how your organization truly stands, beyond the CVSS scores? Get in touch with us and we will look together at what your situation requires.

Lees meer