Critical Vulnerabilities in Code: A CWE and OWASP Perspective

Not every error in a piece of software's source code is a security vulnerability.

Some errors cause the application to crash.

Some affect performance.

Some spoil the user experience.

Others can let an attacker reach the system, escalate their privileges, access data belonging to other users, or run commands directly on the server.

This last group is the area that really matters for source code security.

In modern software security the aim is not merely to find "code errors".

The real aim is:

to detect as early as possible the code weaknesses an attacker could use.

Different reference models are used so that these weaknesses can be described in a common language.

The main ones are:

CWE – Common Weakness Enumeration

and

OWASP – Open Worldwide Application Security Project

.

CWE offers a comprehensive structure for classifying software security weaknesses.

OWASP helps in understanding the most critical risk categories, particularly in web and application security.

When these two structures are assessed together, you can answer not only "which vulnerability is present?" but also:

"Why did this vulnerability occur, which weakness class does it belong to, and how can it be prevented from recurring?"

In this chapter we will look at the most critical security vulnerabilities encountered in source code, together with the technical logic behind them.

1. What Is CWE?

CWE — Common Weakness Enumeration — is a structure that aims to gather software and hardware security weaknesses under a common classification.

The important word here is "weakness".

CWE does not directly describe a single vulnerability in a particular product.

It classifies the root cause or the weakness type behind the vulnerability instead.

SQL Injection may be found in an application, for example.

That single vulnerability is a security flaw.

But the fundamental weakness underlying it is user-controlled data being included insecurely in the structure of an SQL query.

CWE standardises root causes of this kind.

That standardisation matters particularly for large organisations.

Because recurring security problems can be analysed among thousands of findings.

An organisation might see these results, for example:

• Authentication errors recur frequently.
• Authorisation problems are concentrated in certain teams.
• Injection vulnerabilities appear more often in certain frameworks.
• The hard-coded secret problem recurs in certain repository groups.

This information can feed directly into Secure Coding training and development standards.

2. What Is the Difference Between CVE and CWE?

CWE and CVE are often confused.

But the two serve different purposes.

CVE – Common Vulnerabilities and Exposures is used to identify a known security vulnerability within a particular product or piece of software.

CWE explains what type of software weakness that vulnerability stems from.

With a simple example:

An SQL Injection flaw may exist in a particular version of a product.

A CVE number can be assigned to that flaw.

But the software weakness category of the problem is classified under CWE as an Injection or SQL Injection type.

In short:

CVE = A specific security vulnerability

CWE = The weakness type of the vulnerability

This distinction is quite important for source code analysis.

Because SAST usually does not look for a CVE.

It looks for CWE-type weaknesses inside source code.

3. What Is the OWASP Top 10?

The OWASP Top 10 is one of the best-known security references, making the most critical security risks in web applications visible.

It helps particularly in creating a common language among managers, developers and security teams.

But there is an important point:

The OWASP Top 10 is not a source code checklist.

Nor does testing an application only against the OWASP Top 10 mean the application is completely secure.

The OWASP Top 10 expresses broad risk categories.

CWE can classify far more detailed weakness types.

In professional source code security work, therefore:

OWASP + CWE + Secure Coding Standard + Application Business Logic

should be assessed together.

4. What Is Injection?

Injection is the vulnerability class that arises when data controlled by an attacker is interpreted by the application as part of a command or query.

Many different attack types fall into this class.

For example:

• SQL Injection
• Command Injection
• LDAP Injection
• NoSQL Injection
• XPath Injection
• Template Injection

What injection problems have in common is this:

Data and command have not been safely separated from one another.

The attacker can therefore make the input they send not just be processed as data but change the application's behaviour.

Injection flaws are one of the most critical areas of control in source code analysis.

5. How Does SQL Injection Occur?

SQL Injection arises when user-controlled data is included insecurely in an SQL query.

A developer might use this logic to fetch a username, for example:

SELECT * FROM users WHERE username = ' + userInput + '

A normal user sends this value:

ramazan

The query becomes:

SELECT * FROM users WHERE username = 'ramazan'

But an attacker can send special characters that change the SQL syntax.

If the application adds the input directly to the query, the attacker can change the query's structure.

The impact of this attack can extend to serious consequences such as:

• reading data,
• modifying data,
• authentication bypass,
• deleting data,
• further system access in some environments.

The fundamental root cause of the SQL Injection problem is usually this:

Building dynamic SQL through string concatenation.

6. How Is SQL Injection Prevented?

The basic solution to SQL Injection is not so much filtering user input as separating the data from the SQL command.

Using a parameterized query or prepared statement is therefore critically important.

The secure approach works on this logic:

SELECT * FROM users WHERE username = ?

User input is not added to the query's structure.

It is passed to the database engine as a separate parameter.

The database then interprets the user input as data, not as SQL syntax.

Additional controls such as:

• using an ORM,
• a least-privilege database account,
• input validation,
• secure error handling

can also be applied.

But using an ORM does not automatically mean SQL Injection is impossible.

If raw query or unsafe query functions are used incorrectly, the risk can return.

7. What Is Command Injection?

Command Injection is a critical vulnerability that arises when user-controlled data becomes part of an operating-system command.

An application might ask the user to enter an IP address so the system can run a ping test, for example.

The developer might use this logic:

ping + userInput

In that case the attacker can try to run different operating-system commands using command-chaining characters.

A successful Command Injection attack can lead to results such as:

• reading files,
• modifying files,
• running new processes,
• reconnaissance across the network,
• credential access,
• complete takeover of the server.

Command Injection is therefore generally assessed as a high or critical risk vulnerability.

8. How Is Command Injection Prevented?

The safest approach is not to pass user input directly into an operating-system shell command.

Where possible, secure programming libraries should be used instead of operating-system commands.

For a ping operation, for example, a network library can be used instead of calling the shell directly.

If calling an external process is unavoidable, controls such as:

• allowlist input validation,
• fixed parameter sets,
• disabling shell interpretation,
• a least-privilege service account

should be applied.

The basic principle is this:

User input must not become part of command syntax.

9. What Is Cross-Site Scripting (XSS)?

Cross-Site Scripting is a vulnerability that lets an attacker run script in other users' browsers as a result of user-controlled data being passed to a web page without being processed safely.

XSS is one of the problems encountered most often in web applications in particular.

A successful XSS attack can lead to results such as:

• user sessions being targeted,
• page content being changed,
• fake forms being created,
• operations being carried out in the user's name,
• sensitive data being stolen.

The fundamental problem with XSS is usually this:

Untrusted data and HTML/JavaScript output have not been safely separated.

10. What Is Stored XSS?

In a stored XSS attack the malicious data is first saved inside the application.

The attacker might add malicious content to a forum comment, for example.

That content is held in the database.

Later, when other users open the page in question, the malicious script runs in their browsers.

Stored XSS can therefore sometimes have a higher impact than reflected XSS.

Because the attacker may not have to direct users to a special link one by one.

The malicious content can be delivered to many users through the application's normal operation.

11. What Is Reflected XSS?

In a reflected XSS attack the malicious data is not stored permanently in the application.

The value the user sends is returned in the same HTTP response without being safely encoded.

A search page might show this text, for example:

"Search results for X"

If the value of X is controlled by the user and written directly into the HTML, the attacker can craft a specially prepared link.

When a user opens that link, the malicious script can run.

12. What Is DOM-Based XSS?

DOM-based XSS arises mostly in client-side JavaScript code.

Here the server response may be safe.

But the front-end JavaScript may pass user-controlled data into the DOM insecurely.

For example:

Passing a URL fragment value directly into risky functions such as innerHTML can create a problem.

Modern source code analysis should therefore be applied not only to back-end code but to front-end JavaScript and TypeScript code as well.

13. How Is XSS Prevented?

The fundamental defence against XSS is the context-aware output encoding approach.

That is, data must be encoded in a way appropriate to the context in which it will be used.

HTML content,

HTML attribute,

JavaScript,

CSS,

URL

are different contexts.

Modern frameworks' automatic output encoding features should also be used and not disabled unnecessarily.

Browser security mechanisms such as Content Security Policy can provide an additional defence layer too.

But CSP is not a substitute for secure coding.

14. What Is Broken Access Control?

Broken Access Control is an authorisation problem that lets users reach data or functions they should not normally be able to access.

It is one of the most critical risks in modern applications.

A user might be viewing their own invoice through this endpoint, for example:

GET /api/invoice/1201

If, when an attacker changes that value to:

GET /api/invoice/1202

another customer's invoice is displayed, an access control problem is present.

The application may have checked that the user is signed in.

But it has not checked whether they are authorised to access that invoice.

Authentication alone is therefore not enough.

An authorisation check is required for every critical operation.

15. What Is IDOR?

IDOR — Insecure Direct Object Reference — can arise where an application provides access to object identifiers directly but does not perform the necessary authorisation check.

For example:

/customer/1001

/customer/1002

predictable ID structures of this kind may exist.

But there is an important point here:

The problem is not that the ID is predictable.

The real problem is:

the absence of an authorisation check on the back end.

Using UUIDs can make the attack harder but is not a real security solution.

Authorisation must be verified server-side on every request.

16. What Is BOLA?

In the field of API security the concept of BOLA – Broken Object Level Authorization is used in particular.

BOLA means the API not performing the necessary authorisation check at object level.

A user might be sending an API request relating to their own bank account, for example.

The JSON may contain:

accountId: 5412

If the system still performs the operation when the attacker changes the accountId value to an ID belonging to another account, a BOLA problem is present.

Problems of this kind are critically important in API-based systems.

17. Broken Function Level Authorization

Authorisation must be applied not only at data object level but at function level too.

A standard user should not be able to call this endpoint, for example:

/api/admin/deleteUser

Hiding the admin button in the front-end interface is not a security control.

The attacker can call the endpoint directly.

The back end must therefore perform a role and privilege check on every request.

18. What Is Server-Side Request Forgery (SSRF)?

SSRF arises when an attacker makes the server send a network request to other systems.

An application may have a feature that takes a URL from the user, for example:

"Download the image at this URL."

If the back end sends a request to the URL supplied by the user, the attacker can try to specify different targets.

Systems such as:

• localhost
• internal servers
• private IPs
• management interfaces
• cloud metadata endpoints

can be targeted.

The attacker is trying to reach systems they cannot access directly, through the application server.

19. Why Is SSRF Critical in Cloud Environments?

In cloud environments application servers can sometimes reach metadata services.

Those services can supply instance configuration or critical information resembling credentials.

If an SSRF flaw lets the attacker have requests sent to those endpoints, a serious security risk can emerge.

SSRF should therefore be assessed specifically in cloud-native applications.

20. How Is SSRF Prevented?

Blocking particular words in a URL is not sufficient as an SSRF defence.

The stronger approach is to use controls such as:

• determining permitted domains through an allowlist,
• blocking internal IP ranges,
• checking the IP after DNS resolution,
• checking redirect chains,
• limiting the application server's network access

together.

Here code security and network segmentation work together.

21. What Is Path Traversal?

Path Traversal is a security problem that lets an attacker reach files outside the permitted directory, as a result of user-controlled data being used insecurely when building a file path.

An application might display:

/files/report.pdf

for example.

But if the user can control the filename parameter, the attacker can try to reach different files using directory traversal characters.

On some systems this attack can lead to sensitive configuration files or credential information being read.

22. How Is Path Traversal Prevented?

The safe approach is not to take a full file path from the user.

A predefined identifier with server-side mapping can be used instead.

If user input has to be used:

• canonical path validation,
• an allowlist of file names,
• preventing traversal outside a specific base directory,
• restricting access permissions

should be applied.

23. What Is Unrestricted File Upload?

File upload mechanisms can be abused by an attacker when they are not designed correctly.

An application may be checking only for the .jpg extension, for example.

The attacker can try to upload an executable file using various techniques.

Depending on the technology in use, the risk can reach results such as:

• hosting malicious files,
• stored XSS,
• malware distribution,
• disk consumption,
• remote code execution in some cases.

More than one control should be used together in file upload security.

24. Secure File Upload Controls

Checking only the extension during file upload is not sufficient.

The main areas that must be checked are:

• permitted file types,
• the actual content,
• MIME type,
• file size,
• file name,
• storage path,
• execution permission,
• method of access.

Keeping files outside the web root as far as possible and not letting the application execute them directly is important.

25. What Is Insecure Deserialization?

Serialization means converting an object into a storable or transmittable format.

Deserialization is the reverse.

If the application deserializes data from an untrusted source without control, the attacker can create unexpected objects or code paths.

In certain technologies and frameworks this can escalate to the level of Remote Code Execution.

Deserializing untrusted data must therefore be handled with great care.

26. How Is Insecure Deserialization Prevented?

Native serialized object formats from untrusted sources should be avoided as far as possible.

Simple data formats can be preferred.

In addition:

• allowlist type validation,
• signature verification,
• integrity checks,
• secure serializer settings

should be applied.

The most important principle is:

Limit which objects user-controlled data can turn into.

27. What Is Prototype Pollution?

Prototype Pollution is a security problem seen particularly in the JavaScript ecosystem.

As a result of misuse of JavaScript's prototype inheritance mechanism or uncontrolled object merge operations, an attacker can affect global object behaviour.

If user-controlled JSON data is passed to an insecure deep merge function, for example, the attacker can try to manipulate certain special properties.

Prototype Pollution can be chained with:

• authorization bypass,
• application logic manipulation,
• XSS or more advanced attacks in some cases.

28. What Is XML External Entity (XXE)?

XXE can arise when an XML parser processes external entities insecurely.

Using specially crafted XML, an attacker can cause the server to read local files or reach external network resources.

In some scenarios XXE can produce effects similar to SSRF.

Using secure configuration in modern XML parsers is critically important.

29. How Is XXE Prevented?

The basic approach is to disable external entity support entirely if it is not being used.

In addition:

• disabling DTD processing,
• using a secure parser,
• applying the framework's security configurations

are required.

This problem matters particularly in older or specially configured XML processing systems.

30. What Is Open Redirect?

Open Redirect is the application performing a redirect to a user-controlled URL without validation.

After login, for example, a structure like:

/login?returnUrl=https://example.com

may be used.

If the attacker can change the return URL value to their own malicious site, they can use the application's trusted domain for phishing purposes.

Open Redirect on its own may not always be critical.

But combined with OAuth flows or authentication systems it can turn into a higher security risk.

31. Hard-Coded Credentials

Keeping a password, API key or token inside source code is one of the code security problems encountered most often.

For example, information such as:

db_password = "Secret123"

may be written directly into the source code.

If the repository is compromised, the attacker can reach the credential directly.

More importantly, even if the information is later deleted from the code it can remain in the Git history.

Secret Scanning should therefore be used as a separate layer in modern code security programmes.

32. How Should Secret Management Be Done?

Sensitive information should be kept outside source code as far as possible.

Systems such as:

• Environment Variables
• Secrets Manager
• Vault
• Cloud Secret Store

can be used.

Credential rotation should also be applied.

If a secret is found to have been pushed to a repository by mistake, deleting it from the code is not enough.

The credential in question must be considered compromised and changed.

33. Insecure Use of Cryptography

Cryptography is a powerful security mechanism.

But used incorrectly it can create a false sense of security.

Problems such as:

• using an outdated algorithm,
• weak key length,
• a fixed initialization vector,
• a hard-coded encryption key,
• a weak random number generator

can arise.

Developers should not build their own encryption algorithms.

Standard, trusted cryptographic libraries should be used.

34. Should Passwords Be Encrypted?

Passwords should not be stored with reversible encryption in the classic sense.

Secure password hashing algorithms designed for password storage should be used instead.

The aim is that not even the system administrator can recover the user's password.

Password verification should be performed through the hash.

Appropriate salt and algorithm parameters should also be used.

35. What Is Weak Randomness?

Generating security-critical values with a predictable random number generator can create a serious problem.

Values such as:

• password reset tokens,
• session IDs,
• API tokens,
• verification codes

should be produced with cryptographically secure random sources.

Ordinary application random functions are not always suitable for security purposes.

If an attacker can predict the values that will be generated in future, authentication mechanisms can be bypassed.

36. Sensitive Data Exposure

Holding more sensitive data than necessary, or failing to protect it, creates a significant risk.

Information such as:

• passwords,
• credit card data,
• personal data,
• health information,
• authentication tokens,
• private keys

can be present unnecessarily in logs, databases or responses.

One of the basic principles of secure software development should be:

Do not collect or store sensitive data you do not need.

37. Logging Sensitive Data

Logs are necessary for security.

But incorrect logging can lead to a serious data breach.

If the API request body is logged in full, for example, the user's password or access token can end up in the logs.

Anyone who later reaches the log system can see that information.

A logging standard should therefore be established and sensitive fields masked.

38. Excessive Data Exposure

In API systems in particular the back end sometimes returns far more data than the front end needs.

The front end shows only the necessary fields.

But an attacker can examine the raw API response.

The front end might be showing:

first name,

surname

while the API response contains additional information such as:

national ID number,

telephone,

internal customer ID,

risk score.

Hiding a field in the front end is not a security control.

The back end should return only the data that is genuinely needed.

39. Mass Assignment

In modern frameworks the automatic binding of JSON or form data to a model object speeds up development.

But insecure use can create risk.

Where the user should only be able to change:

name

and

email

if the back end accepts every field of the model, the attacker can add an unexpected property such as:

role=admin

Explicitly determining the user-modifiable fields with an allowlist is therefore recommended.

40. Can Security Misconfiguration Occur at Code Level?

Yes.

Security Misconfiguration does not consist only of server settings.

Insecure default configuration can also exist inside source code.

Problems such as:

• debug mode being on,
• detailed error messages,
• CORS *,
• default admin credentials,
• authentication checks being disabled with a development flag

can be found inside the code repository.

Configuration scanning is therefore important alongside SAST.

41. Why Should Debug Code Not Reach the Production Environment?

Debug endpoints may be created during development.

Functions such as:

/debug/users

or:

/test/loginAsAdmin

can make life easier for the developer.

But if they are not removed for the production release, a critical vulnerability can arise.

Environment-specific controls in CI/CD processes are therefore important.

42. Improper Error Handling

Error handling is not only about user experience.

It is a security matter as well.

Detailed exception information can give an attacker valuable information about the application.

Information such as:

• database table names,
• internal paths,
• library versions,
• source code locations,
• query structure

can be revealed.

While a general error message is shown to the user, the details should be kept in secure server logs.

43. Authentication Problems

Many different code security problems can arise in authentication mechanisms.

Problems such as:

• a weak password policy,
• the absence of brute force protection,
• predictable reset tokens,
• MFA bypass,
• session fixation,
• token validation errors

can create critical security risks.

Source code analysis requires deep examination of the authentication lifecycle in particular.

44. JWT Security Errors

JWT is widely used in modern API systems.

But incorrect implementation is risky.

Problems such as:

• the token signature not being verified,
• use of the wrong algorithm,
• expiration not being checked,
• sensitive data being added to the payload,
• use of long-lived tokens

can arise.

It should not be forgotten that the payload inside a JWT is not encrypted by default.

Base64 encoding is not security.

45. Session Management Problems

Once the user has signed in, session security becomes critical.

For example:

• the session ID may be predictable,
• the session may remain active after logout,
• the session duration may be longer than necessary,
• the session may not be renewed after a privilege change.

Problems of this kind can be examined partly with SAST, but assessing them together with DAST and manual pentesting gives a stronger result.

46. Race Condition

A race condition can create a security problem as a result of several operations running on the same resource in an unexpected order or concurrently.

A balance check might work like this, for example:

• Is the balance sufficient?
• Make the payment.
• Reduce the balance.

If the attacker sends several requests at the same time, more than one payment can be approved before the balance is reduced.

Problems of this kind can be critical particularly in finance and e-commerce systems.

47. Time-of-Check to Time-of-Use (TOCTOU)

TOCTOU is one of the special types of race condition.

The system first checks a resource.

Then it uses it.

But the resource can change between the check and the use.

It can create risk particularly in file system operations and privilege checks.

Vulnerabilities of this kind can be more complex from a static analysis perspective and may require expert examination.

48. Why Are Vulnerabilities Chained?

A single vulnerability may not always be enough to take over a system completely.

But attackers usually use several flaws together.

For example, an attack chain such as:

Information Disclosure

↓

User ID Discovery

↓

Broken Access Control

↓

Sensitive Data Access

can form.

In another scenario, more advanced attacks such as:

SSRF

↓

Internal Service Discovery

↓

Credential Access

↓

Privilege Escalation

can occur.

Security findings should therefore be assessed not only independently but from an attack-chain perspective too.

49. Why Should CWE Be Used in Enterprise Security Measurement?

The real value of source code analysis work should not remain within a single project report.

Through CWE mapping an organisation can accumulate security data over time.

At the end of the year, for example, this result may be visible:

28% Authorization

19% Input Validation

17% Secret Management

14% Cryptography

22% Other

This data is highly valuable.

Because it shows in which area the organisation has a systematic problem.

If authorisation is consistently in first place, for example:

• the Secure Coding standard,
• framework design,
• the training programme,
• the code review checklist

can be updated for that area.

50. From Finding the Vulnerability to Finding the Root Cause

The fundamental difference of a mature Application Security programme emerges exactly here.

A beginner-level programme asks:

How many vulnerabilities do we have?

A more mature programme asks:

Why do we keep producing the same vulnerabilities?

If SQL Injection keeps being found, for example, closing the existing findings is not sufficient.

Why developers are using string concatenation should be investigated.

A standard database helper library can be created.

Secure Coding training can be delivered.

A SAST Quality Gate can be applied.

The root cause of the problem is then removed instead of vulnerabilities being closed one by one.

51. Why Does OWASP ASVS Matter?

The OWASP Top 10 is a strong starting point for understanding security risks.

But a more systematic structure may be needed for enterprise security verification.

At that point OWASP ASVS – Application Security Verification Standard becomes important.

ASVS provides detailed security requirements in areas such as:

• authentication,
• session management,
• access control,
• validation,
• cryptography,
• logging,
• API security.

ASVS can be used as a reference in source code analysis and manual security testing.

The assessment then moves beyond looking for vulnerabilities and becomes verification of security controls.

52. The Foundation of a Strong Code Security Programme

A single technology is not enough to reduce the critical vulnerabilities in source code.

A strong structure can consist of these components:

Secure Coding

Tries to prevent security problems from arising.

SAST

Detects weaknesses in the code automatically.

SCA

Analyses third-party components.

Secret Scanning

Detects sensitive credential information.

Manual Code Review

Examines business logic and complex security problems.

DAST

Tests the running application.

Pentest

Simulates real attacker behaviour.

These layers working together form the foundation of a modern Application Security programme.

The SecureSys CWE and OWASP-Based Source Code Security Approach

At SecureSys we do not assess security findings in source code analysis work solely by the technical names the tools give them.

A finding's:

root cause, CWE category, OWASP relationship, exploitability, reachability and business impact

must be considered together.

Depending on project scope, areas such as:

• injection risks,
• authentication problems,
• authorisation errors,
• business logic flaws,
• use of sensitive data,
• cryptography,
• file handling,
• SSRF,
• secret management,
• API security

can be assessed in source code analyses.

SAST output can be put through expert validation.

Critical code sections can be reviewed manually.

The impact of findings on the real attack surface can be assessed through penetration testing on the running application.

Source code analysis then answers not only:

"Which vulnerability is in the code?"

but also:

"Why did this vulnerability occur and how can we prevent it happening again?"

Real code security maturity begins exactly there.

Frequently Asked Questions

What is CWE?

CWE is the abbreviation of Common Weakness Enumeration. It is used to classify software and hardware security weaknesses under common categories.

What is the difference between CWE and CVE?

A CVE describes a single security vulnerability in a particular product or piece of software. CWE classifies the weakness type underlying the vulnerability.

What is the OWASP Top 10?

The OWASP Top 10 is a reference work that makes the most important security risk categories in web applications visible.

Why does SQL Injection occur?

It occurs as a result of user-controlled data being included insecurely in the structure of SQL queries.

What is Broken Access Control?

It is an authorisation problem that lets a user reach data or functions they are not authorised for.

What is IDOR?

It is access being gained to other objects because the application does not perform sufficient authorisation checks when using object identifiers.

What is SSRF?

It is a vulnerability that lets an attacker use the application server to send requests to other network resources the server can reach.

What is a hard-coded credential?

It is sensitive information such as a password, API key or token being kept directly inside source code.

Can SAST find all these vulnerabilities?

It can detect some of them quite successfully. But manual analysis and pentesting may be needed for business logic, complex authorisation, runtime and attack-chain problems.

Is checking the OWASP Top 10 sufficient for source code security?

No. The OWASP Top 10 is an important starting point, but professional code security assessments should also consider CWE, OWASP ASVS, Secure Coding standards and application-specific risks.

Conclusion: You Need to Understand the Root Cause, Not the Name of the Vulnerability

Real maturity in source code security does not consist only of finding vulnerabilities such as SQL Injection, XSS or SSRF.

When a vulnerability is seen, the real question should be:

Why did this vulnerability occur?

Did the developer use the wrong API?

Was the Secure Coding standard incomplete?

Was the framework configured incorrectly?

Was the authorisation architecture designed badly?

Was the security control missing from CI/CD?

Did the developer lack knowledge about security?

Classifications such as CWE gain their value precisely at this point.

Because they let us see the recurring weaknesses behind individual vulnerabilities.

OWASP helps us understand which risk areas are especially critical from an attacker's perspective.

When these two approaches are combined with Secure Coding, SAST and manual security analysis, an organisation can turn into a security structure that not only finds vulnerabilities but:

understands why it produces them.

In the end the aim of sustainable software security is not to find more vulnerabilities after every release.

It is to produce fewer vulnerabilities with every new release.