Part of a series

This Blog post is part of the series Vulnerability Management Series: 3D (Definition, Deep-Dive, and Difficulties)

• Part 1 provides an overview of vulnerability management and the terms. This will be a recap for most people, but is a good starting point for all who just jump into this topic or want to sharpen their understanding.
• Part 2 dives deeper into vulnerability management, looking into the various areas of this topic. [Coming soon]
• Part 3 is about challenges we faced while supporting customers and consequently provides some tips on what to avoid and what might be worth considering.

In order to provide a common ground to talk about a topic, we need some definitions. Not only will this blog post provide a small glossary, but also some clarity about the relationship between these terms.

“I can almost hear you saying: ‘In our organization we use this term differently or we use another term’”. That might be OK, as long as all involved people have the same understanding. However, using the same language is essential to avoid misunderstandings and work towards the same goal. Once you interact with people outside of your organization, using different terms or meanings might backfire.

Therefore, let’s start with the obvious one:

What is Vulnerability Management?

In order to provide a thorough definition of vulnerability management, the following explanation of the term has been assembled from multiple sources:

Vulnerability Management is a systematic approach and a critical and ongoing IT security operation practice that is related to risk management [1] [2] [3]. Vulnerability Management encompasses identifying, assessing, categorizing, prioritizing, mitigating, remediating and reporting  (security) vulnerabilities in an organisation’s systems and the software that runs on those systems  [1] [2] [4]. Vulnerability Management contributes to preventing attacks, as well as minimizing the window of opportunity for attackers [5] and the damage of security incidents when these occur [6].

The ISO 27001:2022 standard uses the term „management of technical vulnerabilities“ and addresses the scope as “information systems in use” [7, p. 16] and consequently defines areas as organisation, site and personnel, as out of scope. [8, p. 54ff]

You might ask now, what the target of vulnerability management is. It is not to remediate all vulnerabilities as soon as possible. The objective is to keep the risk the vulnerabilities pose within the defined and accepted risk level, which aligns with your risk appetite. This represents the maximum level of risk you are willing to accept based on the estimated impact it may have.

We will go deeper into this topic in part 2 of this series. (Part 2 will be linked once it is published)

But what is a vulnerability?

ISO 27005:2022 defines a vulnerability as a “Weakness of an asset or control […] that can be exploited so that an event […] with a negative consequence […] occurs“ [8, p. 3]. Vulnerabilities are not static, as there is the “possibility of emergent vulnerabilities that can arise naturally over time as organizational missions/business functions evolve, environments of operation change, new technologies proliferate, and new threats emerge.“ [9, p. 9] Also, there is usually a time difference between the discovery of a vulnerability and the public announcement [10], which if disclosed responsible, often include recommendations to mitigate or remediate the weakness and hence the vulnerability.

This is quite generic. But we will dive deeper a little further below and also look at frequently used terms of vulnerability management. Before we look at the WHAT, we first look at the WHY.

Why should I care?

To speak in a metaphor, would you want someone else (unknown) to access your house? I assume not. You typically lock the door. In the same way, one wants to lock out others (unpermitted one) from the IT systems.

Even worse, if you take care of a house or parts of it for someone else (systems, components, data) and these would get abused. There might be inherent damage to the organisations and/or people which use the system or whose data this is, as well as to your own reputation.

Depending on the vulnerability and the importance of the system, the impact to your business can range from low to fatal.

Next to the inherent self-interest, you might be obliged to comply with laws, standards or industry regulations. The following table lists some examples and we all can be sure, more will come in the future:

Law	Scope	Vulnerability Management requirements?
Cyber Resilience Act (CRA) [11]	Products with digital elements (hardware/software) in the EU	Explicit [11, p. 2]
NIS2 Directive [12]	Operators of essential and important entities across critical sectors in the EU	Explicit [12, p. 12]
EU Cybersecurity Act	ICT products, services, and processes across the EU	Explicit [13, pp. Article 51, 51a, 54, 55]
Digital Operational Resilience Act (DORA)	Financial sector (banks, insurers, investment firms, etc.)	Explicit [14, p. Article 8 and 25]
PCI DSS (Payment Card Industry Data Security Standard)	Organizations that handle credit card transactions and store, process, or transmit cardholder data globally	Explicit [15, p. 119 ff]
General Data Protection Regulation (GDPR)	All organizations processing EU residents’ personal data	Indirect (via security of processing – article 32)

There are standards and frameworks to address vulnerability management. The following table lists some examples:

Name	Description
ISO/IEC 27001 & 27002 [7] [16]	Internationally recognized ISMS standards with explicit vulnerability management requirements.
NIST SP 800-53 [17]	Comprehensive security controls for federal agencies, including detailed vulnerability management.
NIST Cybersecurity Framework (CSF) [18]	Widely used risk-based approach; includes vulnerability management (see Risk Assessment)
CIS Controls (Center for Internet Security) [19]	Globally adopted best practices; Control 7 focuses on vulnerability management.
SANS Vulnerability Management Maturity Model [20]	Practical maturity model for assessing and improving vulnerability management programs.
BSI IT-Grundschutz [21]	Germany’s comprehensive IT security framework, including requirements addressing vulnerability management.

Compliance [3], is an often used term in this area, to address adherence to requirements for this management topic by laws and regulations, industry related standards, and also self-specified requirements of the organization itself.

In the end, it comes down to protecting your business. As it is with all risks, it is not possible, realistic or feasible to remove all of them, independently of the source, whether it is a business risk, end-of-life software or based on the priority. Therefore, a risk driven approach is needed to translate the severity of the vulnerabilities into risks.

As with all management practices, you also need to define your processes, thresholds, SLA, roles and responsibilities, communication flows, and many more aspects, tailored to your specific environment and organization. We will look further into these areas in part 2 of this series. For now, we build the foundation by establishing an understanding of frequently used terms.

Frequently used Terms in Vulnerability Management

Everyone talks about vulnerabilities, but what about risks, threats and findings? Are they all the same?

So let’s look at commonly used terms – to get a common understanding and use right term at the right time. Additionally, we will also look at two examples, where frequently used terms are sometimes mistaken.

The diagram above shows related terms, that are connected to a vulnerability, at which definition we already looked.

We will go over the terms by walking through a mixed and simplified lifecycle, starting with a vulnerability, going over a finding and result in a risk, as they are connected:

Terms in the Vulnerability Lifecycle

Introduction of the root cause

The root cause of a vulnerability are usually software bugs (the technically correct term is defect, but who speaks like that?) or misconfigurations. A bug is an „imperfection or deficiency in a work product where it does not meet its requirements or specifications or impairs its intended use.“ [22] That include the special cases, where it’s intended use is abused to cause harm. Such a bug could be introduced to a system unknowingly and unaware. However, a vulnerability could also be introduced consciously to exploit it in the future.

A misconfiguration is a „setting within a computer program that violates a configuration policy or that permits or causes unintended behaviour that impacts the security posture of a system“ [23, p. 38]

Examples of misconfigurations are, but not limited to: [24]

• Missing appropriate security hardening across any part of the application stack or improperly configured permissions
• unnecessary featured enabled or installed
• default accounts and their passwords enabled and unchanged
• The security settings in the application servers, application frameworks, libraries, databases, etc., are not set to secure values.

In order to make it more tangible, we will use one vulnerability which had quite an impact as an example: Log4Shell (CVE-2021-44228). Log4j is a widely used logging framework [25]. Retrospective analysis identified that the vulnerability was introduced in version 2.0-beta9. The vulnerability arose from the implementation of a feature that inadvertently created a security weakness [26]. This weakness is categorized under the Common Weakness Enumeration (CWE) [27], a community-developed list of common software and hardware weaknesses that could have security implications [28]. Understanding these weaknesses can assist in developing custom mitigations, especially when vendor recommendations are unavailable.

Discovery and Disclosure

Even well-tested software might contain undetected vulnerabilities, as “exhaustive testing is impossible” [29, p. 18] which should result in a mindset, that every system might be compromised at one point in time, and appropriate measure have been prepared to ensure cyber resilience.

Not all hackers which find vulnerabilities use them for their own benefit. Ethical hackers help to make systems more secure by reporting these vulnerabilities through the principles of coordinated disclosure (also called responsible disclosure) [30] so that these can be fixed (for further information see e.g. [31] [32]). There even are programs that result in a win-win for both parties, as such discoveries might be rewarded as part of a bug bounty program [33] [34].

A responsible disclosure for a vulnerabilities includes contacting the vendor allowing enough time to prepare a patch or at least a remediation, before distributing information about the vulnerability, often together with an official identifier, e.g. the CVE (Common Vulnerabilities and Exposure) [35] or EUVD [36].

A CVE record contains a unique ID (e,g. CVE-YYYY-NNNNN), a description, the assigning CVE Numbering Authority (CNA) and further references. The version 5.1 of the CVE schema [37] defines fields for further useful information as the affected configurations and a severity score, which are usually provided by the vulnerability databases as the NVD [38], EUVD [36], OSV.dev, or vendor specific databases.

Coming back to our example, the Log4Shell vulnerability was disclosed to Apache on November 24, 2021, by Chen Zhaojun of the Alibaba Cloud Security Team. As this logging framework is widely used, the list of known affected software configurations is long (but also not conclusive). [39] [40]

Fixes and Security Advisories

Once the creator (and or maintainer) organisation is informed about a potential security issue, the organisation can review and verify it. After a positive and hopefully timely verification, a patch can be developed. A patch is a special type of software update, that fixes vulnerabilities.

Installing the patch or updating to a newer version without the vulnerability are the only threat response actions that completely remove the vulnerability without impacting the functionality [41, p. 3]. Depending on the type of vulnerability, the vendor might also provide mitigations as (temporary) workarounds, e.g. disabling certain functionalities to reduce the attack surface.

Such a public announcement (including informing the users) of the vendor for a vulnerability, including information as the CVSS Base score, and details related to the mitigation and remediation, is called security advisory. [42, p. 8] [43, p. 4]

In the context of our example, the Apache Software Foundation announced the vulnerability on their website [44] and published a dedicated blog post to inform users about the impact on other Apache projects [45]. The vulnerability has a severity score of 10, indicating a critical vulnerability. This score reflects the potential for arbitrary code execution from a remote network location, posing a significant threat to affected systems. Given the widespread use of this logging library, many vendors have issued additional security advisories to guide users in mitigating the risks associated with Log4Shell.

Exploitation

While an asset is affected by a vulnerability, independent whether it is known or not, threat actors with malicious intent can cause harm to the system or other actors [46] during this window of opportunity.

A threat (the negative outcome of a risk) is „any circumstance or event with the potential to adversely impact organizational operations and assets, individuals, other organizations, or the Nation through an information system via unauthorized access, destruction, disclosure, or modification of information, and/or denial of service.“ [9, p. 8]

Usually the term risk is always associated with the negative outcome (threat) and the impact (potential loss or damage). But usually it has two sides, the threat and the opportunity. [47, p. 3.1] Otherwise why would someone take a risk, if you can only lose? In risk management, a threat and an opportunity are two sides of the same coin. The risk is an uncertain event, that could flip towards the negative side – the threat – or towards the positive side – the opportunity. The likelihood and the impact do not have to be symmetrical. In vulnerability management, usually one only talks of threats, not opportunities.

There are different types of threat actors (also called threat source), which can pose a threat and are “The source of risk that can result in harmful impact.” NIST SP 800-221“, reaching from Script Kiddies, Hacktivists, over Cybercriminals to Nation-State Actors, but are not limited to the internal view, as there can also be insider threats.

Such a threat actor could use an exploit, which is a software, a piece of code, or data, to take advantage of a vulnerability for malicious purposes. [48] While some exploits are published and publicly available, there are also zero-day vulnerabilities. These vulnerabilities are unknown to the vendor or the public, [49, pp. F-2] and hence, neither the threat is known nor a remediation is possible. Consequently, attackers can exploit zero-day vulnerabilities before they are discovered and mitigated. These vulnerabilities are also sold or kept secret by organizations to use them when the time is right.

Referring back to the example: A detailed walkthrough of the Log4Shell exploitation process is available online. This guide explains how attackers can leverage the vulnerability to execute malicious code, providing insights into the methods used and potential indicators of compromise. [50]

Terms in the Findings Lifecycle

Detection

Next to the information that there are vulnerabilities, you want to know if you are affected. That is where the Common Platform Enumeration (CPE) comes into play. This “is a structured naming scheme for information technology systems, software, and packages. […] CPE includes a formal name format, a method for checking names against a system, and a description format for binding text and tests to a name.“ [51] To cut a long story short, the CPE can be used to define the affected or explicitly not affected software. This can be done via a scan of your assets, or a comparison of your indexed inventory (usually within your configuration management system or a SBOM) against vulnerabilities.

While the Vulnerability is a „weakness […] that can lead to a successful security attack“ [52] and informs about the potential threat , a finding is a concrete „single instance of a vulnerability appearing on an asset” [53], with details that provide evidence of the present vulnerability [54, p. 19] There might not be huge differentiation in practice, but there is one, as a vulnerability might be in multiple products, but the finding addresses a single instance.

While ISO 27001:2022 describes an asset quite broad as “Any resource or component within an organization that has value and requires protection” ISO 27001

In the area of vulnerability management this is typically any kind of software, e.g.

• Firmware
• Operating Systems
• Business Applications (independent of the packaging format, e.g. RPM, OCI Image, MSI, JAR, WAR, EAR, just to name a few)
• Custom-developed Applications
• Databases
• Security and administration tools

To connect this with our example: Vulnerability scanners are effective tools for detecting vulnerabilities such as Log4Shell [55] [56] [57]. Depending on the scanner’s update cycle and its ability to quickly incorporate new CVE detections, you might also consider using stand-alone detection scripts [58] for immediate identification. Both methods serve to identify systems at risk and offer guidance on remediation strategies to mitigate potential threats.

Vulnerability assessment and penetration testing

A common misunderstanding relates to vulnerability assessments and penetration testing.

Most penetration testing activities include a vulnerability assessment as the basis, to identify the initial target, and gather information of the underlying operating system, accessible ports and services. “A significant difference between vulnerability assessment and penetration testing is that the vulnerability assessment reflects a ‘look but don’t touch’ philosophy, whereas a penetration test may run the risk of changing or damaging the target environment. “ [59, pp. 9-10] 

In essence it can be said that a vulnerability assessment is used to scan for known vulnerabilities, while a penetration test, next to identify unknown vulnerabilities to the scanner, can provide further insights as multiple exploits could be chained and regarding the impact with respect to the context. Both are crucial for maintaining robust security, with vulnerability scans providing regular and automated insights, and penetration tests offering detailed evaluations.

---

Terms in the Risk Lifecycle

Prioritise

After I know that there is a vulnerability in one of my assets, I want to know the potential impact this vulnerability has. That is the point where we look at the CVSS which is ”an open framework for communicating the characteristics and severity of software vulnerabilities.” [60] The „Base metrics assessment results in a score ranging from 0.0 to 10.0“ and are mapped to a qualitative severity rating of none, low, medium, high or critical. [61] This system helps to assess the impact.

After I know that there is a vulnerability in one of my assets, I want to know the potential impact this vulnerability has. That is the point where we look at the CVSS which is ”an open framework for communicating the characteristics and severity of software vulnerabilities.” [60] The „Base metrics assessment results in a score ranging from 0.0 to 10.0“ and are mapped to a qualitative severity rating of none, low, medium, high or critical. [61] This systems helps to assess the impact.

The CVSS is only one aspect in our prioritisation on how to handle vulnerabilities. Another aspect might be threat intelligence, protection needs and the business impact. Known Exploited Vulnerabilities (KEV), which are lists of vulnerabilities, which exploitation has been observed in the wild. [62, p. 1] Based on that threat intelligence sharing, it can be assumed that, if the asset is reachable for an attacker, the threat likelihood increases. This knowledge might influence the priority of handling vulnerabilities on certain assets. We will look further into prioritisation in Part 2 of this blog post series, including other approaches.

Vulnerability assessment and risk analysis

“A common error that enterprises make is mistaking vulnerability assessment results with a comprehensive risk analysis. “ [59, p. 9]  The error is, that the provided CVSS score and the derived severity rating are interpreted as the result of the risk analysis. However, this is only the technical analysis.

According to NIST, an information security risk analysis contains not only the risk to system security and the likelihood of occurrence, but also “the resulting impact, and the additional safeguards that mitigate this impact.” [63, p. 165]

This underlines, that the “key difference between a vulnerability assessment and a risk analysis is context.” [59, p. 9]  Solely considering and relying on the vulnerability assessment’s results of findings might create unnecessary emergency changes, as the vulnerability scanner might not have the (full) context, for example if the affected server is internet facing, and how important is the system for the business in terms of processes and the type of data processed. The vulnerability assessment can be used as the base for the risk analysis and add context to it and to analyse it further in terms of the likelihood based on the threat scenarios and landscape, and the consequence and the impact of an exploited vulnerability. [59, p. 9] 

Response Actions

After prioritisation, we are utterly interested in the mitigation and/or remediation of a vulnerability. Remediation refers to reducing “the level of risk associated with one or more threat events, threat scenarios or vulnerabilities” [64, p. 12], while mitigation is the “neutralization or elimination of a vulnerability or the likelihood of its exploitation“ [65, p. 27].

Example for threat response action include, but are not limited to [41, p. 3]:

• Avoiding the risk
  • Installing and testing the patch that fixes the bug
  • Disable certain component/functions
  • Shut down the server
• Mitigate the risk
  • Restrict the access path to the abusable function
  • An application layer firewall could be used, to block potential attacks through „indicator of attack“ (also called virtual patching [66]) [67] [68] after analysing potential exploits or information in the CVE record
• Transfer the risk
  • Purchase a cybersecurity insurance
  • Replace traditional software with SaaS, where the vendor takes care of patching
• Accept the risk
  • Take the informed decision to accept the risk for a certain time

To illustrate this concept further we will take a concrete Log4j vulnerability (CVE-2021-44228) in a Red Hat product as an example to address a specific risk response action. In a system running Red Hat AMQ Streams [69], updating the system in accordance with security advisories is a straightforward process. By using the command dnf upgrade-minimal –advisory=RHSA-2021:5138 [70], you can efficiently apply the necessary updates, ensuring the system is safeguarded against this critical vulnerability.

Interfaces of Vulnerability Management 

Vulnerability Management has many interfaces to other disciplines. It is based on certain elements of other disciplines and can also provide information to other disciplines to support them.

For these interfaces, we will use the simplified (operational) vulnerability management process [2] [71] (details will be provided in part 2):

• Identify Assets
• Detect vulnerabilities
• Assess findings and prioritise risks
• Plan and execute response actions
• Reporting

This cycle or parts of this cycle can run in parallel, e.g. as part of the regular scanning cycle, but also as an ad-hoc cycle based on security alerts, e.g. KEV Threat Intelligence Feeds.

The following subchapters provide examples for some discipline and are not an exhaustive listing. Each subchapter shows a table with both perspectives:

• how vulnerability management might benefit from other management practices
• how other management practices can take advantage of vulnerability management

Identify assets

Discipline	How Vulnerability Management uses it	How Vulnerability Management supports it
Asset Management	The base for many IT-Disciplines. Provides information for the defined scanning scope.	Can identify incorrect information (retired systems) or even identify shadow assets.

Detect vulnerabilities

Discipline	How Vulnerability Management uses it	How Vulnerability Management supports it
Test Management[SA1]	Test Management can contribute through Security Testing e.g. Static and Dynamic Application Testing, providing further findings.	–
Patch Management	Information about regular patching cycles and scope.	Identify missing security patches and also validate fix via rescans.
Change Management Release Management	Information about changes to Assets	Validate fixes via rescans. Provide a gate for releasing software. Stop release when there are critical vulnerabilities (without remediation to accepted level)
responsible disclosure program & Bug Bounty Programme	Can be part of the vulnerability management program. The first one should be used. Incentive can range from appreciation, over free use to financial incentives.	–
Threat Intelligence	Identify assets with findings which are known to be exploited (e.g. KEV), to take further actions to protect these.	–
Penetration Testing	A more detailed analysis of the risk can be initiated.	Can take the vulnerability scan as the base for the test.
Application Security / Software development	–	Test early, scan early, and help to fix it early.   Scan used dependencies (artefacts as libraries, software packages, images)
Incidence Response	–	Incident Analyst rely on system information. For a validation on incidents or a first assessment, information on potential vulnerabilities of an IT Asset or Configuration Item (host, software, service, …) are an important source.

Assess findings and prioritise risks

Discipline	How Vulnerability Management uses it	How Vulnerability Management supports it
GRC	Provides criticalities via labels usually via the asset management (normal, high, critical, sensitive, vital)	–
IT Risk Management and Access Management	Provides risk levels, risk thresholds and SLA.	Assess the technical risk of IT assets and could trigger an escalation if the risk threshold is reached.

Plan and conduct response actions

Discipline	How Vulnerability Management uses it	How Vulnerability Management supports it
Asset Management	Provides information about the asset owner, which are essential.	–
Patch Management	Information about (regular) maintenance windows, patching cycles and scope	–

Reporting

Discipline	How Vulnerability Management uses it	How Vulnerability Management supports it
Obsolescent Management	–	Identify End-Of-Life SW. Also supports it indirectly, as it can provide information about SW that will run out of support soon.
Asset Management	Provides information of the asset owner, so that they can be informed regularly and when a new critical risk has been detected.	–

Conclusion

Vulnerability Management can be considered a special form of risk management. It is not only relevant out of self-interest, but can also be prescribed through laws, regulations or certifications.

Vulnerability management it is not an isolated topic, as it has many touchpoints. Even though, one can start small and scale it up to the desired and required state.

As with all specialised topics, a common language is needed to work together. I hope this article helped you understand the key terms and their relationships better and can avoid misusing related terms as vulnerability and finding.

Outlook towards part 2

In the next article we will dive deeper into vulnerability management, taking a closer look at the different aspects of it, especially the processes and certain topics within it as metrics and reporting and prioritisation.

Share your knowledge and experience

Feel free to share your knowledge, experience and opinion with us in the comments below.

Need help? We are here for you

Do not hesitate to contact us if you need support for your vulnerability management. Our experts are here to help!

About the author

References

[1] Red Hat, “What is vulnerability management?,” 5 May 2023. [Online]. Available: https://www.redhat.com/en/topics/security/what-is-vulnerability-management.
[2] Elastic, “What is vulnerability management?,” [Online]. Available: https://www.elastic.co/what-is/vulnerability-management. [Accessed 22 03 2025].
[3] Gardner, “Market Guide for Vulnerability Assessment,” 07 August 2023. [Online]. Available: https://www.gartner.com/en/documents/4610400.
[4] Rapid7, “The Ultimate Guide to Vulnerability Management,” [Online]. Available: https://www.rapid7.com/fundamentals/vulnerability-management-and-scanning/. [Accessed 20 03 2025].
[5] Center for Internet Security, “CIS Critical Security Control 7: Continuous Vulnerability Management”.
[6] Microsoft, “What is vulnerability management?,” [Online]. Available: https://www.microsoft.com/en-us/security/business/security-101/what-is-vulnerability-management?msockid=1defdc1492af60633313c967936d6115. [Accessed 03 07 2025].
[7] International Organization for Standardization, “ISO/IEC 27001:2022,” 2022.
[8] International Organization for Standardization, “ISO/IEC 27005:2022,” 2022.
[9] National Institute of Standards and Technology, “NIST SP 800-30 Rev. 1 – Guide for Conducting Risk Assessments,” 2012.
[10] MITRE, “Obtain Capabilities: Vulnerabilities,” 22 04 2025. [Online]. Available: https://attack.mitre.org/versions/v17/techniques/T1588/006/.
[11] European Union, “REGULATION (EU) 2024/2847,” 2024.
[12] European Union, “DIRECTIVE (EU) 2022/2555,” 2022.
[13] European Union, “Cybersecurity Act – REGULATION (EU) 2019/88,” 2019.
[14] European Union, “Digital Operational Resilience Act – REGULATION (EU) 2022/2554,” 2022.
[15] PCI Security Standards Council, “Payment Card Industry Data Security Standard – Requirements and Testing Procedures Version 4.0.1,” 2024.
[16] ISO, “ISO 27002:2022 Information security, cybersecurity and privacy protection — Information security controls,” 2022.
[17] National Institute of Standards and Technology, “Security and Privacy Controls for Information Systems and Organizations (SP 800-53 Revision 5),” 2020.
[18] National Institute of Standards and Technology, “The NIST Cybersecurity Framework (CSF) 2.0,” 2024.
[19] Center for Internet Security, “CIS Critical Security Controls Version 8,” 2021.
[20] SANS, “Vulnerability Management Maturity Model,” 2025.
[21] BSI, “IT-Grundschutz-Kompendium,” 2023.
[22] ISTQB, “defect,” [Online]. Available: https://glossary.istqb.org/en_US/term/defect. [Accessed 09 07 2025].
[23] National Institute of Standards and Technology, “Security Content Automation Protocol (SCAP) Version 1.3 Validation Program Test Requirements – NISTIR 7511 Revesion 5”.
[24] OWASP, “A05:2021 – Security Misconfiguration,” 2021. [Online]. Available: https://owasp.org/Top10/A05_2021-Security_Misconfiguration/. [Accessed 09 07 2025].
[25] BSI, “Kritische Schwachstelle in Java-Bibliothek Log4j,” 2021.
[26] NIST, [Online]. Available: https://www.cisa.gov/news-events/news/apache-log4j-vulnerability-guidance. [Accessed 27 08 2025].
[27] Mitre, “CWE – Common Weakness Enumeration,” [Online]. Available: https://cwe.mitre.org/. [Accessed 27 08 2025].
[28] MITRE, “New to CWE,” [Online]. Available: https://cwe.mitre.org/about/new_to_cwe.html. [Accessed 07 10 2025].
[29] ISTQB, “Certified Tester Foundation Level Syllabus,” 2024.
[30] BSI, “Handhabung von Schwachstellen,” 2018.
[31] Enisa, “Coordinated Vulnerability Disclosure Policies in the EU,” 2022.
[32] BSI, “Leitlinie des BSI zum Coordinated Vulnerability Disclosure (CVD)-Prozess,” 2022.
[33] Apple, “Apple Security Bounty Guidelines,” [Online]. Available: https://security.apple.com/bounty/guidelines/. [Accessed 27 08 2025].
[34] Google, “Google Bug Hunters,” [Online]. Available: https://bughunters.google.com/. [Accessed 27 08 2025].
[35] Mitre, “CVE – Common Vulnerability and Exposure,” [Online]. Available: https://www.cve.org/ResourcesSupport/Glossary#glossaryCVE. [Accessed 27 08 2025].
[36] Enisa, “European Union Vulnerability Database,” [Online]. Available: https://euvd.enisa.europa.eu/homepage. [Accessed 27 08 2025].
[37] CVEProject, “CVE-Schema Version 5.1,” [Online]. Available: https://github.com/CVEProject/cve-schema/blob/main/schema/docs/full-record-advanced-example.json. [Accessed 10 07 2025].
[38] NIST, “National Vulnerability Database,” [Online]. Available: https://nvd.nist.gov/. [Accessed 27 08 2025].
[39] S. P. a. D. McKee, “Log4Shell Vulnerability is the Coal in our Stocking for 2021,” [Online]. Available: https://www.trellix.com/blogs/research/log4shell-vulnerability-is-the-coal-in-our-stocking-for-2021/. [Accessed 27 08 2025].
[40] BSI, “Kritische Schwachstelle in Log4j – Arbeitspapier Detektion und Reaktion,” 2021.
[41] National Institute of Standards and Technology, “Guide to Enterprise Patch Management Planning,” 2022.
[42] BSI, “Technical Guideline TR-03183: Cyber Resilience Requirements for Manufacturers and Products: Part 3: Vulnerability Reports and Notifications,” 2024.
[43] First.org, “Guidelines and Practices for Multi-Party Vulnerability Coordination and Disclosure,” 2020.
[44] ISTQB, “abuse case,” [Online]. Available: https://glossary.istqb.org/en_US/term/abuse-case. [Accessed 09 07 2025].
[45] ISO, “ISO 31000:2018(en) Risk management — Guidelines,” 2018.
[46] CISCO, “What is an exploit?,” [Online]. Available: https://www.cisco.com/site/us/en/learn/topics/security/what-is-an-exploit.html. [Accessed 10 07 2025].
[47] National Institute of Security and Technology, “Autonation Support for Security Control Assessments,” 2018.
[48] Sysdig, “Exploiting, Mitigating, and Detecting CVE-2021-44228: Log4j Remote Code Execution (RCE),” [Online]. Available: https://www.sysdig.com/blog/exploit-detect-mitigate-log4j-cve#exploiting-cve-2021-44228-step-by-step. [Accessed 27 08 2025].
[49] NIST, “Official Common Platform Enumeration (CPE) Dictionary,” [Online]. Available: https://nvd.nist.gov/products/cpe. [Accessed 27 08 2025].
[50] ISTQB, “vulnerability,” [Online]. Available: https://glossary.istqb.org/en_US/term/vulnerability. [Accessed 09 07 2025].
[51] tenable, “Findings,” [Online]. Available: https://docs.tenable.com/vulnerability-management/Content/Explore/Findings/Findings.htm. [Accessed 09 07 2025].
[52] OWASP, “Application Security Verification Standard,” 2025.
[53] tenable, “CVE-2021-44228,” [Online]. Available: https://www.tenable.com/cve/CVE-2021-44228/plugins. [Accessed 27 08 2025].
[54] Codenotary, “Apache Log4j vulnerability shows the importance of SBOMs,” [Online]. Available: https://codenotary.com/blog/apache-log4j-vulnerability-shows-the-importance-of-sboms. [Accessed 27 08 2025].
[55] Tanium, “How Tanium Can Help with CVE-2021-44228: Log4Shell,” [Online]. Available: https://help.tanium.com/bundle/z-kb-articles-salesforce/page/kA07V000000TcVFSA0.html. [Accessed 27 08 2025].
[56] Artic Wolf, “Arctic Wolf Releases Open Source Log4Shell Detection Script,” [Online]. Available: https://arcticwolf.com/resources/blog/arctic-wolf-releases-open-source-log4shell-detection-script/. [Accessed 27 08 2025].
[57] ISACA, “Vulnerability Assessment,” 2017.
[58] FIRST, “Common Vulnerability Scoring System v4.0: Frequently Asked Questions (FAQ),” [Online]. Available: https://www.first.org/cvss/v4-0/faq. [Accessed 10 07 2025].
[59] First.org, “CVSS v4.0 Specification Document,” [Online]. Available: https://www.first.org/cvss/v4-0/specification-document. [Accessed 27 08 2025].
[60] National Institute of Standards and Technology, “Likely Exploited Vulnerabilities,” 2025.
[61] National Institute of Standards and Technology, “Mobile Device Security,” 2020.
[62] National Institute of Standards and Technology, “Developing Cyber-Resilient Systems,” 2021.
[63] National Institute of Standards and Technology, “Recommendations for Federal Vulnerability Disclosure Guidelines,” 2023.
[64] OWASP, “Virtual Patching Cheat Sheet¶,” [Online]. Available: https://cheatsheetseries.owasp.org/cheatsheets/Virtual_Patching_Cheat_Sheet.html. [Accessed 27 08 2025].
[65] Crowdstrike, “IOA VS IOC,” [Online]. Available: https://www.crowdstrike.com/en-us/cybersecurity-101/threat-intelligence/ioa-vs-ioc/. [Accessed 10 07 2025].
[66] Crowdstrike, “Indicators of Compromise (IOC) Security Explained,” [Online]. Available: https://www.crowdstrike.com/en-us/cybersecurity-101/threat-intelligence/indicators-of-compromise-ioc/. [Accessed 10 07 2025].
[67] Red Hat, “RHSA-2021:5138 – Security Advisory,” [Online]. Available: https://access.redhat.com/errata/RHSA-2021:5138 . [Accessed 27 08 2025].
[68] Red Hat, “Chapter 2. Installing security updates,” [Online]. Available: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/managing_and_monitoring_security_updates/installing-security-updates_managing-and-monitoring-security-updates. [Accessed 27 08 2025].
[69] IBM, “What is the vulnerability management lifecycle?,” 28 07 2023. [Online]. Available: https://www.ibm.com/think/topics/vulnerability-management-lifecycle.
[70] National Institute of Standards and Technology, “Incident Response Recommendations and Considerations for Cybersecurity Risk Management,” 2025.
[71] National Institute of Standards and Technology, “Technical Guide to Information Security Testing and Assessment,” 2008.
[72] BSI, “Technical Guideline TR-03185: Secure Software Lifecycle,” 2024.
[73] FIRST, “Guidelines and Practices for Multi-Party Vulnerability Coordination and Disclosure,” 2020.
[74] Apache Software Foundation, “Apache Logging Services,” [Online]. Available: https://logging.apache.org/security.html. [Accessed 27 08 2025].
[75] Aapche Software Foundation, “Apache projects affected by log4j CVE-2021-44228,” [Online]. Available: https://security.apache.org/blog/cve-2021-44228/. [Accessed 27 08 2025].