DEV Community: Nargiz Naghiyeva

Inside the CVE List: How Vulnerabilities Get Their ID Cards

Nargiz Naghiyeva — Sun, 21 Jun 2026 22:27:58 +0000

Thousands of software bugs are discovered every day around the world. But turning these bugs into an official, globally recognized CVE code (such as CVE-2026-1234) is a rigorous and coordinated process.

Who Maintains the CVE List?
The Master CVE List is managed by the MITRE Corporation, a non-profit organization, a federally funded research center in the United States. The program is funded by the U.S. Cybersecurity and Infrastructure Security Agency (CISA). MITRE is responsible for the integrity of the database and maintaining the rules.

What are CVE Numbering Authorities (CNAs)?
Since MITRE cannot register all the software vulnerabilities in the world on its own, it delegates the authority to assign IDs to a global network of partners called CVE Numbering Authorities (CNAs).

Who are the CNAs?
Big Tech Companies: Giants like Microsoft, Apple, Google, Cisco assign CVE IDs to vulnerabilities found in their products.
Security Companies and Bug Bounty Platforms: For example, HackerOne or cybersecurity firms can provide code for vulnerabilities they find during research.
Open Source Projects: Groups like the Linux Kernel or Apache manage their own ecosystems.
If a vulnerability finder (for example, a cybersecurity student or pentester) finds a vulnerability in a product of a small company that is not a CNA, they can contact MITRE directly and request a CVE ID.

Conclusion
Thanks to MITRE and the global CNA network, vulnerability reporting is not done haphazardly, but in a coordinated manner. This system allows programmers to develop patches and protects users from attacks.

CVE Severity: Risk-Based Prioritization

Nargiz Naghiyeva — Sun, 21 Jun 2026 22:17:44 +0000

In large networks, security teams receive hundreds of CVE notifications every day. It is resource-intensive to patch all vulnerabilities at once and immediately. CVE Severity is based on the CVSS (Common Vulnerability Scoring System) system, which measures the risk of vulnerabilities from 0.0 to 10.0, and serves as a compass for teams to prioritize which threats to address.

Severity Levels and Response Strategies
The CVSS framework categorizes vulnerabilities into four different severity levels. Each level requires a different response time:

Critical Level (CVSS 9.0 – 10.0)
Characteristics: Can be exploited over the Internet, without user interaction, and without requiring any special privileges. Allows for full system control (Remote Code Execution).
Strategy: Urgent Incident Response. No scheduled maintenance is expected.
Response Time: Within 24 - 48 hours. If no official patch is available, immediate virtual patching is applied through the Web Application Firewall (WAF).

High (CVSS 7.0 - 8.9)
Features: Allows Privilege Escalation or bypassing of critical security filters. However, exploitation may require specific user actions, such as local network access or phishing.
Strategy: Accelerated Patching. Monthly queues are unexpectedly pushed into the next update cycle.
Response Time: Within 1 - 2 weeks.

Medium (CVSS 4.0 - 6.9)
Features: Requires complex conditions, internal user permissions, or physical access to exploit. Impact is typically limited and does not bring down the entire infrastructure.
Strategy: Scheduled Patching. Scheduled to fit into standard IT maintenance cycles and monthly routine update windows.
Response Time: Within 30 - 90 days.

Low (CVSS 0.1 - 3.9)
Characteristics: Minimal security impact. Typically small leaks such as software version number disclosure (information disclosure) and not sufficient for a single cyberattack.
Strategy: Low Priority / Monitoring Only. Performed during major system updates or when resources allow.
Response Time: When resources and time are available (no time limit).

Conclusion
Organizations are moving from a haphazard "patch everything" approach to a risk-based, systematic defense model by directly aligning their response to the severity of CVEs.

What is a CVE and Why Does It Matter?

Nargiz Naghiyeva — Sun, 21 Jun 2026 22:06:55 +0000

CVE (Common Vulnerabilities and Exposures) is a unique and international identification number assigned to each specific cybersecurity vulnerability found in software and hardware (for example, CVE-2021-44228). It is managed by the MITRE corporation.
Its main goal is to create a common security language for all cybersecurity experts, programmers and scanner tools around the world.

Contribution to Vulnerability Management

Automated Scanning: Security scanners (Nessus, Qualys, etc.) mark the vulnerabilities they find with a CVE code when scanning your system. This allows admins to immediately understand which specific vulnerability is present.

Precise Patching: When software vendors release a patch, they note which CVE codes it fixes. This allows IT teams to accurately match the patch to the vulnerability and update the system.
Tracking and Reporting: Companies can easily track their internal security posture by looking at “Which CVEs are closed and which are still open?”

Global Data Sharing and Collaboration

Breaking Down Vendor Barriers: Prevents different antivirus or firewall companies from giving different names to the same vulnerability. When a vulnerability discovered by an expert on one side of the world is registered with a CVE code, an engineer on the other side immediately understands what it is.
Risk Scoring (CVSS): The CVE number is also integrated with a score that measures the severity of the vulnerability (CVSS — Common Vulnerability Scoring System). This helps teams determine which vulnerabilities need to be closed first.

Conclusion

The CVE system prevents chaos in cybersecurity. It gives each vulnerability a unique “identity card” and ensures that global defense teams act together and quickly against the same threat.

Why Patch Management is the Backbone of Cybersecurity?

Nargiz Naghiyeva — Sun, 21 Jun 2026 13:26:23 +0000

Patch Management: The Unsung Hero of Cybersecurity

A patch is an update code released by a vendor to fix security holes (vulnerabilities) and bugs found in software, operating systems or libraries. Patch Management is the process of applying these updates to systems in a timely and secure manner.

Why is Patching Critical? (A Race Against Time)

The moment a software vendor finds a vulnerability and releases a patch, the vulnerability is officially announced to everyone. From that moment on, a race begins between hackers and security teams:

Hackers: Analyze the patch and try to find an exploit and develop automated attacks.
Defenders: Install the patch on systems before an attack occurs.

Leaving systems unpatched is like watching a burglary on the local news, knowing your door lock is broken, and then going on vacation without fixing the door. The 2017 Equifax breach (data of 140+ million people), one of the largest cyber incidents in history, was not caused by a newly discovered vulnerability, but by the company’s failure to install an Apache Struts patch that had been around for months.

How it Relates to Holistic Security

Patch management is the foundation that keeps other security foundations alive:

Layered Defense: You can install the most expensive firewalls in the world. But if there is an unpatched Privilege Escalation vulnerability in the kernel of your internal server operating system, a hacker can log in as a regular user and immediately make himself root.

The Patch Strategy of the Future (AI and DevSecOps)**

As systems grow, it is no longer possible for administrators to manually apply updates every Friday. Modern patch management is moving towards full automation:

AI-Powered Prioritizing: Artificial intelligence mathematically calculates and prioritizes which patches are most critical for your infrastructure.

Automated Canary Testing: Updates are first tested on a small isolated group of servers (canary), and if there are no crashes or performance degradations, they are automatically rolled out to the entire network.

Conclusion
A strong cybersecurity posture is not measured by buying new tools, but by how quickly you can fix vulnerabilities in existing systems. Scan your infrastructure regularly, automate the patch cycle, and always be one step ahead of hackers!

The Puppet Master of the Web: Unmasking Cross-Site Request Forgery

Nargiz Naghiyeva — Sun, 21 Jun 2026 13:16:57 +0000

What is CSRF (Cross-Site Request Forgery) and How to Prevent It?

CSRF is the execution of unwanted operations on a secure site that the user is logged in to (authenticated) without his knowledge. This attack does not target the login fields, but the trust between the browser and the site.

How Does the Attack Happen?
You log into your online banking portal (your active session cookies are now stored in your browser).
While keeping that tab open, you visit a malicious website in another tab.
The malicious site triggers a hidden background request directed at your bank, such as: transfer?amount=1000&to=attacker.
Because browsers automatically attach valid session cookies to requests destined for that origin, the bank processes the request, thinking you authorized it.

Potential Impact

For users: Changing the password, transferring money from the profile or making unauthorized purchases.
For administrators: The attacker adds a new admin to the site via the admin browser and takes over the entire system.

Proven Mitigation Strategies

Anti-CSRF Tokens (Gold Standard) The server generates a unique secret token for each session or form that is impossible to guess. When a form is submitted, the server checks this token. Since a malicious external site cannot read this secret token, any fake requests it sends are immediately rejected by the server.
SameSite Kuti Attribute This is browser-level protection. By setting SameSite=Lax or Strict to the boxes, you are telling the browser: "Send this box only when the user is directly on our site, do not include this box in requests from external sites."
Re-Authentication for Critical Operations Require the user to re-enter their current password or perform 2FA (MFA) confirmation at critical moments such as changing a password, transferring money, or updating an email. A hacker cannot fill out these forms in the background.

Conclusion

Relying on valid boxes alone is not enough for a secure web application; It is imperative to verify that each state-changing request is made by a real user with Anti-CSRF tokens.