Risk management within the context of artificial intelligence (AI) systems is a substantial and rapidly evolving space. This is in addition to familiar cybersecurity risks, for which AI systems require comprehensive security consideration. This blog post, which is adapted from a recently published paper, focuses on one aspect of cybersecurity risk management for AI systems: the CERT/Coordination Center (CERT/CC’s) lessons learned from applying the coordinated vulnerability disclosure (CVD) process to reported vulnerabilities in AI and machine learning (ML) systems. As AI systems emerge, these lessons learned can provide useful milestones for responding to vulnerability reports in AI systems.

CVD Process Steps and Their Failure Modes

The CVD process is a framework for vulnerability handling designed to assist interaction between vulnerability reporters and vendors. This post details a number of ways that the CVD process can fail in the context of AI and ML weaknesses and vulnerabilities. Some of these failure modes are specific to AI products, services, and vendors; whereas others are more general and can apply to any vendor or industry sector attempting to follow the CVD process. Over the years, we have observed similar CVD capability evolution in areas that range from operational technologies, such as network infrastructure and traditional computing, to emerging new technologies, such as mobile computing, consumer Internet of Things (IoT), and embedded/edge computing. Similarly, AI-focused organizations are relatively new and can benefit from adopting the CVD process and tailoring it to their unique complexities.

Discovery

The first step in the CVD process is made when an existing vulnerability is found and reproduced. In the case of AI and ML, there are possible failure modes even at this earliest stage, including the following:

• The SaaS model inhibits independent security testing. Security testing is difficult because the models may be opaque and behind an API, and testing may violate the terms of service (ToS). This concern is shared with any SaaS product, which includes most large language models (LLMs). Indeed, many websites and other online applications limit (by terms of service and acceptable use policies) what actions are permissible by users.
• Architectures are unfamiliar to many. In a recent vulnerability note, our coordinators uncovered distinctive characteristics in a graphics processing unit (GPU) architecture and its supporting libraries. GPU architectures and their implementations in support of neural network AI have grown rapidly in importance, yet their impact on system security is not well understood. Expertise in specialized hardware, particularly with respect to side channels, is a problem common to any specialized computing environment (e.g., embedded, field-programmable gate array [FPGA], application-specific integrated circuits [ASICs], operational technology [OT], IoT), but it is notable in the space of AI computing infrastructure simply because of its rapid growth and scale.
• Limited system instrumentation and security analysis tooling limit understanding of system behavior. Introspection and instrumentation of AI components is an area of open research. It is often quite challenging (even for developers) to understand the behavior of the system in specific instances. Software security testing and analysis tends to focus on finding specific categories of problems. In the AI space, the technology itself is changing rapidly as are the toolkits available to security analysts.
• Testing AI systems is a complex, costly, and often impractical AI software testing remains a nascent field of research with limited methods for conducting functional tests that clearly define and measure quality requirements and criteria. The financial burden is significant, particularly for large-scale systems such as LLMs, where training alone can exceed $100 million. This challenge is further compounded in the realm of cybersecurity, where testing often fails to establish clear boundaries for policies that, if violated, would constitute a vulnerability. Moreover, the high costs restrict the ability to build and thoroughly evaluate AI systems in well-funded, capital-intensive organizations. Additionally, there is a significant human capital cost involved in developing AI-specific testing capabilities and interpreting the results. This is compounded by the fact that traditional approaches to development of test coverage criteria do not readily apply to neural network models. This amplifies the need for analysts with expertise in both AI and cybersecurity, but these are currently scarce, adding to the difficulty of ensuring comprehensive and effective testing.

Reporting

Vulnerability reporting succeeds when found vulnerabilities are reported to an individual, organization, or entity that is at least one step closer than the reporter to being able to fix them. While not specific to AI, challenges in the chain of reporting are worth reviewing because they can extend into new and evolving AI systems. In most cases, reporting directly to the vendor of the affected product or service is preferable. Possible failure modes at this step of the CVD process include the following:

• AI community members may be unaware of existing coordination practices, processes, and norms. The AI community has expanded rapidly, transforming readily available components into comprehensive solutions such as AI agents, chatbots, image detectors, and virtual assistants. This rapid growth has allowed little room for many AI projects to engage AI-focused security researchers and adopt CVD processes that can continually secure these growing products.
  A custom report generated on February 24, 2025 listed approximately 44,900 “AI” projects. A follow-up search for SECURITY.MD files in those projects revealed that a majority of them did not provide support for a security workflow or the native CVD tools provided by the GitHub Security Advisory (GHSA).
• Products, services, or vendors that are affected by a vulnerability cannot be identified. Identifying affected software when disclosing vulnerabilities (and weaknesses) is a well-known challenge that is exacerbated in AI due to the often-large collection of software components that are part of an AI system. This is compounded when there is an absence of software composition data, such as a software bill of materials (SBOM).
  Even when affected products (e.g., a vulnerable open-source library) can be identified, it is not always straightforward to pinpoint a specific vendor or determine the impact on downstream products, services, and vendors. As larger vendors absorb software projects due to popularity or usage, the original vendor may change or be difficult to engage as part of a CVD process. An SBOM can potentially help address this issue, but SBOM use is not widespread, and its coverage of potential vulnerabilities is unclear. The analogous concept of an AI bill of materials (AIBOM) has also been proposed, roughly analogous to an SBOM but also encompassing data and model architecture. AIBOMs have the potential to provide even further details about AI system components, such as models and potentially even training data. One potential way for AI developers to address this is to integrate configuration management into their engineering process in a way that augments familiar SBOM elements with AI-specific elements such as training data, test data, input and output filters, and other evolving components that determine its behavior.
• The vendor is unprepared to receive reports or reacts unconstructively to reports. We at CERT/CC have found that, despite much progress, many vendors continue to respond to vulnerability reports with the stance that their product flaws should not be publicly discussed. In many cases, a private report to a vendor will be received in a more constructive manner with public release of the report to follow (e.g. after a fixed period of time). This allows the vendor to repair the vulnerability should they choose to do so. But, regardless, the subsequent public release enables users/clients to develop workarounds should the vulnerability persist.

Validation

The Validation step of the CVD process succeeds when the recipient acknowledges the reported issue as a genuine problem. This step fails when the reported issue is not recognized as valid due to a number of reasons, such as an insufficient description, non-reproducibility of claims, or other factors. This presents technical challenges for both the vendors of AI software and the coordinators of AI vulnerabilities. Issues, such as testing infrastructure costs, identifying affected versions, rapid development cycles, and unfamiliar environments, can make it difficult for the reporter to provide a clear and reproducible problem description. Possible failure modes include the following:

• Vendors may claim that a vulnerability does not meet the current definition or requirements. This failure mode is somewhat related to the challenge vendors face in handling AI-related vulnerabilities (discussed in the Reporting section). While the Product Security Incident Response Team (PSIRT) may have a clear definition of traditional hardware and software vulnerabilities, it may not be able to entirely understand or validate a report of AI-related vulnerabilities using the same methods.
• Vendor documentation has a limited effect on vulnerability determination. Neural-network based AI systems also face huge challenges in documentation, as these system behaviors are often interactive and may be less deterministic. A lack of documentation regarding expected behavior and operational norms makes it difficult to agree upon and evaluate whether a security policy has been violated. As AI systems mature and behavior norms become better understood, documentation can capture these concerns to facilitate better understanding of the vulnerability between the security researcher, coordinator, and the vendor.

Prioritization

The AI community is also vulnerable to the incentives of always chasing bleeding-edge features given the intense competition underway in the emerging generative AI industrial complex. This challenge is familiar in many markets, not just AI. Even organizations that have processes to manage technical debt might not know about the new ways an AI system can accrue technical debt. AI systems are more data dependent, so they can develop feedback loops, experience model drift, and have problems that are difficult to reproduce. Possible failure modes include

• Business incentives can cause short-term quality and maintainability trade-offs. Technical debt, akin to financial debt, can accrue over time. Even organizations that have processes to manage technical debt might not understand the new ways an AI system can accrue technical debt. A recent study suggests that technical debts show up both in code quality and maintainability for a variety of smaller AI-based systems. While the problem is again not specific to AI, it may require specific consideration in AI due to its higher impact on quality as suggested in the study.
• The norms of expected behavior are not well expressed. While the tasks of reporting, prioritizing, and addressing software vulnerabilities are not new to AI vendors, the unique challenges of AI systems necessitate thoughtful adaptation of existing processes. Rather than starting from scratch, we should focus on refining and aligning proven methods to meet the distinct operational tempos and stakeholder expectations inherent to the AI domain.

Coordination

Coordination in the CVD process is the activity of engaging all parties affected by a problem to produce and deploy a fix, workaround, or other mitigation for the benefit of users. For the AI systems and its stakeholders, we have found there are often disparities in expectations concerning both the process that must be followed to coordinate vulnerability reports as well as the desired outcomes of that process. Possible failure modes include

• Vendors may fail to cooperate with others. AI software, like other integrated systems, is often built from other software elements and often bundled and redistributed in various forms. This can make AI software vulnerability handling essentially a multi-stakeholder interaction identified as multiparty CVD. The involvement of multiple parties is a direct result of the software supply chain where AI components are built from other products and services. These AI components can then be layered even further (e.g., data from one vendor leading to models trained by another, which leads to others fine-tuning models in further applications). Coordination across these parties has the potential to become discordant.
• Vendor tempo is mismatched. Addressing vulnerabilities embedded deeply within a product or service may require significant coordination to ensure all impacted systems are properly updated. In many systems, this challenge is amplified by vendors operating at vastly different paces, influenced by varying levels of systems engineering maturity and diverse business drivers. As noted in Validation, rapid development cycles and speed-to-market priorities can exacerbate this mismatch in tempo, making timely and synchronized security responses difficult.
• Vendors restrict interactions with customers and NDA-signed partners. Many vendors, including ones in the AI space, often expect that only paying customers will report issues with their products. However, coordinators like CERT/CC frequently receive reports from non-customers. Additionally, some vendors insist that all vulnerability reporters sign NDAs to discuss the issue, a requirement that can deter valuable input from external parties. In any sector, when competitive pressures and intellectual property concerns are high, restrictive practices such as these can hinder open dialogue and limit broader engagement on critical vulnerability issues, especially when unpatched vulnerabilities can create harms for other users not party to the NDA.

Fix and Mitigation Development

Fixes are always preferred, of course, but when a problem cannot be remediated, a work-around or other mitigation may have to suffice. Possible failure modes include

• The root cause of a problem cannot be isolated or localized in code or data. In addition to traditional software problems that can occur in code, infrastructure, specification, or configuration, AI systems problems can occur in additional areas, such as data and models. These additional components complicate the problem and may at times make it difficult to identify the root cause that needs to fixed. If the vulnerability relates, for example, to model behavior with specific inputs, then identifying areas within a neural-network model can be technically infeasible, and retraining or unlearning (when it can be accomplished) may be called for.
• Stochastic behavior conflicts with binary policies. While many AI systems are inherently probabilistic in their behavior, security policies are often binary, demanding strict compliance or non-compliance. Security policies may need to adapt to define compliance thresholds instead of binary assertions. This will require rethinking regarding security policies and how we define acceptable thresholds of system behavior, which we refer to as stochastic policy.
• Non-regression is not ensured. Over time, the field of software engineering has developed methodologies to ensure that software has not regressed to a previously known bad state. Methods such as unit testing, regression testing, and code coverage analysis ensure that, upon release, software does not break its existing functionality or regress to a known bad state. These methods are still applicable for the software portions of an AI-based system.
• Remediation might not be feasible, and sufficient mitigations might not be easy to agree on. It is not always possible to remove a problem entirely. In those cases, a workaround or mitigation may be necessary. Additionally, for various reasons consumers may find software updates to be not helpful or useful. In a constantly changing world, AI systems in particular are sensitive to these changes post-deployment, especially when the operational input data can drift from what was expected during model training—with the potential to introduce unwanted bias as a result. Model behavior in deployment may also change in real time, so a problem may be introduced or reintroduced completely outside the control of the vendor or user. Therefore, mitigations may sometimes be fragile.
• Solution sufficiency is not agreed to. The kinds of problems in AI systems that are likely to require coordinated response typically extend well beyond the usual confidentiality, integrity, and availability (CIA) impacts of traditional cybersecurity vulnerability response. This is not exclusively an AI problem; it is more driven by understanding the impacts of software behaviors that violate expectations can reach far beyond the control flow of a program in a CPU. The challenge is that the expectations that exist are unclear as well as a sufficient mitigation or remediation. Solutions may involve changes to a model or a set of trained components of an AI system. Lack of model transparency (even to its developers) and the extreme difficulty in unlearning a trained feature or capability can make it impossible to identify agreeable fix or solution.

Publication

The optional Publication of the CVD process step brings awareness of the problem to the broader community including current and potential future customers, consumers, security product and service providers, data aggregators, governmental bodies, and other vendors.

This step succeeds when information about problems and their well-tested mitigations and fixes are known to these stakeholders. It fails when this information is not made available to stakeholders in a usable form and in a timely fashion.

Possible failures in this phase include

• A CVE ID is not assigned. The CVE assignment process relies on the CVE Numbering Authorities (CNAs) that are tied as closely as possible to the vendor or parties responsible for fixing a vulnerability when it is identified. In situations where the involved parties cannot agree on whether a problem rises to the level of vulnerability (see Validation), a CVE ID might not be assigned. Many vulnerability management processes for system owners and deployers incorrectly assume that the only vulnerabilities worth worrying about will have CVE IDs assigned.
• NDAs impede transparency. In our discussion of Coordination failure modes, we mentioned how NDAs can be used and misused. However, NDAs can affect publication as well by limiting the participation of finders, coordinators, vendors, or other participants in the CVD process. If these participants are unable to fully explain problems to their stakeholders, then the public’s ability to make informed choices about the privacy, safety, and security of AI-based products and services can be impeded.
• Components are hidden inside products and services. As we described in the Reporting step, it can be difficult to tell who the responsible parties are for a particular problem due to the opacity of the supply chain. This issue arises again in the Publication step because it is not always obvious to a stakeholder using an AI-enabled product that it is affected by a vulnerability in one of its subcomponents. This may include components, such as models and training data, that are not distinctly identified or versioned making it impossible to know if the publication can identify which version or component was fixed as part of the new release. This issue broadly applies to integrated software systems and is not specific to AI-enabled systems.
• Publishing failures in AI systems is viewed as a knowledge-building exercise. There is a case to be made for publishing AI system failures to provide information for future threats and vulnerabilities that extend beyond the immediate operational imperatives driven by current risks and threats. It has been our experience that it is valuable to write about all the different ways an emerging technology can fail and be misused by attackers if not properly mitigated or fixed. There is an abundant technical literature regarding various kinds of weaknesses and vulnerabilities for a wide range of modern AI models and systems. Vendors may nonetheless be hesitant to support such a forward-looking effort that may involve major changes to their practices. For example, a product vulnerable to code injection in the form of prompt injection (e.g., a chatbot), may identify that chat prompts presented to a user should be treated as untrusted.

Fix and Mitigation Deployment

Regardless of whether the Publication step occurs, the next step in our process model is Fix and Mitigation Deployment. This step succeeds when fixes or adequate mitigations exist and are deployed. It fails when fixes or adequate mitigations have been created and are available yet are not deployed to the affected systems. Possible failure causes include

• The deployer is unaware of the problem or does not prioritize the fix. If the deployer does not know about the problem or the availability of a fix, it cannot remediate the systems it is responsible for. Even if a deployer is aware of a fix, it might not prioritize the deployment of that fix or mitigation. Commonly used cybersecurity prioritization tools, such as the Common Vulnerability Scoring System, often prove insufficient for assessing the impact of problems in AI systems, which can be more diffuse than traditional cybersecurity vulnerabilities. Additionally, some categories of weaknesses and vulnerabilities in neural-network models remain technically difficult to mitigate.
• Affected versions and fixed versions are not identified or distinguishable. While the software in an AI system can be tracked, typically by using existing package management and versioning mechanisms, this tracking rarely transfers to the model and data the system might use. While new techniques are being proposed such as data version control (DVC) for machine learning models and data, these are not yet mature and not adopted widely by the AI community.
• The update process itself is insecure. Deployment should not expose the deployer to additional risk. In many cases, the update process for a model is to download a new version from a model aggregator (e.g., Hugging Face). This download can be done as part of a build process, the installation process, or even at runtime. While this method of providing updates is not much different from dynamic package management or mechanisms used by frameworks, such as Python’s pip or Node’s npm, we have observed that many AI systems that do not incorporate attestation mechanisms (e.g., cryptographic signature verification) prior to loading the downloaded models, data, or code.

Monitoring and Detection

Monitoring and detection succeed when the coordinating parties are keeping watch and can notice when problems arise after fix availability, publication, and deployment. Problem examples might include incomplete or inadequate mitigations, exploit publication, attack observations, and the like. This step succeeds when there are sufficient processes in place to identify similar events when they occur. This step fails when those events pass unnoticed. Possible failure modes—for all kinds of systems—include

• No monitoring is performed or enabled. The absence of monitoring in any system represents a process failure because it prevents stakeholders from identifying and diagnosing issues they are not actively observing. Effective monitoring for AI may require significant modifications to the software to enable insights into the model's behavior and data flow. However, runtime introspection and interpretation of AI components remain challenging areas of research. Given this complexity, implementing monitoring for AI in the near term may be impractical without refactoring, leaving many AI systems operating with limited visibility into their behavior and vulnerabilities.
• Scanning tools do not address the weaknesses and vulnerabilities. The 2023 White House Executive Order EO 14110 on AI underscored the need for systematic documentation and mitigation of vulnerabilities in AI systems, acknowledging the limitations of existing identification frameworks like CVE IDs. This highlights a gap: traditional CVE identifiers, widely used in vulnerability scanning tools do not sufficiently cover AI-specific vulnerabilities, limiting visibility and detection. As a result, while vulnerabilities with CVE IDs can be flagged by scanners, this is a practice not yet developed for AI systems, and it poses technical challenges.
• Vulnerability management does not handle mitigation well. CSET’s recent study on AI vulnerabilities highlighted some of the critical challenges in AI vulnerability management. Many AI repairs have been shown to be limited mitigations rather than remediations. In some cases, the limitation of remediation is due to the stochastic nature of AI systems, making it difficult to comprehensively address the vulnerability. Vulnerability management (VM) programs are not readily able to validate or provide crucial metrics to understand the current state of the AI software when being used in some production capacity.
• Reports of inadequate fixes or mitigations are not resolved. Sometimes there are stakeholders who consider a vulnerability to be resolved, but it turns out that the fix is incomplete or otherwise inadequate. When this occurs, it is important that the Coordination step continues until the new issues are resolved. If the Coordination step does not continue, the Monitoring step will fail to achieve the goal of ensuring that fixes are adequate and sufficient.
• An exploit is publicly released or an attack goes unnoticed. During the Coordination phase of CVD, it’s possible that other researchers or attackers have independently discovered the same AI vulnerability. If an exploit is released outside of the ongoing CVD process, the urgency of addressing the vulnerability intensifies. When vulnerabilities in software systems go unnoticed, exploits may proliferate undetected, which can complicate the coordination efforts. Additionally, attacks targeting these vulnerabilities may occur during or after coordination if the vendor has not developed or distributed detection methods, such as signatures, to stakeholders.

Process Improvement

This step of CVD is successful when insights from the execution of the process are used to enhance future development and coordination practices. These insights can prevent future vulnerabilities or help manage existing ones. Feedback can take the form of root cause analysis that leads to enhanced development and testing protocols, additional procedural checkpoints, or improved threat models. This step fails if the feedback loop is not established. Possible failure modes—for all kinds of software systems—include

• Root cause analysis is not conducted. Understanding the origin of a problem is crucial to rectify it. Identifying the specific system feature where the problem occurred is a key part of root cause analysis. However, identifying the flaw is just the beginning of adapting the process to prevent similar future issues. Indeed, for modern neural-network AI, many of the root causes for certain AI-specific weaknesses and vulnerabilities are well understood, but techniques for remediation are not yet developed.
• Root cause analysis does not lead to adequate (or any) process changes. A root cause analysis can pinpoint the specifics that led to a vulnerability and suggest process improvements to mitigate similar future issues. However, if these insights are not integrated into the process, there is no chance of improvement. Similarly, knowing the root cause and making changes is also not enough. It is essential to verify that the improvements had the desired effect.
• Modern neural-network AI software has special characteristics, and many processes are yet to be developed. Software engineering practices have adapted over time through adoption of new practices and lessons from past failures. AI software development has brought some of its own new challenges that are not readily addressed by traditional software lifecycle processes. Key aspects of AI software development, such as data-centric development, model-based training, and the adaptable software by time, have yet to be clearly framed in the traditional sw lifecycle models. Similarly the cybersecurity counterparts that provide a secure SDLC, such as the NIST Secure Software Development Framework (SSDF) OWASP Software Assurance Maturity Model (SAMM), also do not identify elements of the AI development. NIST, however, has an active process to advance an AI Risk Management Framework (RMF). AI’s reliance on data and models introduces risks not addressed in conventional software processes, expanding into data integrity, continuous monitoring for model drift, and transparency in model decision-making.

Creation (of the Next Vulnerability)

We maintain that there is always another vulnerability, so the best process improvement we can hope for is to reduce how often new vulnerabilities are introduced by avoiding past mistakes.

Possible failure modes include

• Threat models may be naïve to AI challenges. Threat models are an important part of understanding the threats that a system should be secured against. However, threat models for some AI systems may be limited, often overlooking the complexity and dynamism of real-world threats. Unlike conventional software, which has relatively well-defined boundaries and patterns of risk, AI systems face distinct challenges, such as adversarial attacks, data poisoning, and model-specific vulnerabilities. These threats can be overlooked in standard threat models, which may inadequately address the intricacies of AI, such as input manipulation, model evasion, or prompt injection in language models
• The security policy is either non-existent or at best unclear. Implicit policies (for all kinds of software systems) are based on individual expectations and societal norms. However, with new and rapidly developing technology, we do not know what is possible, impossible, or reasonable to expect.
• Naïve Use of libraries and dependencies Dependency security is a critical part of understanding software. This includes AI software, where the behaviors are determined by training data and prompts, and where complexity exists in both developing the AI software and its operation in an environment.
• Data and models obscure software behavior. The separation of data and code is a principle of secure design. The principle is quite simple: Computational instructions should be kept distinct from data that is the subject of computation. This is a means to prevent untrusted code from being executed when masked as data. AI software depends on the learning process that digests data and produces neural-network models. There are further challenges such as model drift and model/Data Versioning.
• Computing architectures and their interfaces lack security features. GPUs were initially designed to support high performance graphics operations with highly parallel implementations. This general-purpose parallel processing capability, with the invention of the LLM transformer architecture, has made them integral to modern AI software. Almost all GPU programming is done via programmable interfaces and vendor-provided libraries. These libraries were initially designed without the data protection or data segregation features that are inherent in modern CPUs, but there is recent progress in this regard.
• The supply chain is complex. All earlier failure modes relate to huge supply-chain issues due to the deep software stack as systems continue to be assembled from both traditional and AI-enabled software components. The supply chain starts with the hardware vendors that provide hardware capabilities and application programming interface (API) libraries and is followed by multiple levels of software solutions that embed components like a Matryoshka doll with embedded layers of possibly-unaccounted software.

Four Key Takeaways and a Call for Action

We conclude with four key takeaways:

• AI is built from software. Yes, neural networks are a different style of software. Collecting and cleaning data and training models are new elements of software development process. AI systems introduce new challenges while retaining the persistent cybersecurity issues of traditional software. This foundation makes CVD processes, generally effective for conventional software, useful for addressing vulnerabilities in AI, recognizing the need to address the particular characteristics and challenges of neural-network models. The AI software community could gain benefit from collaboration with the CVD community to tailor these processes for AI's unique challenges.
• Software engineering matters, including in AI systems. A great deal of prior work in software engineering has been invested into ensuring that certain quality attributes are present in both the products of the development effort as well as the process that produces those products. These quality attributes—reliability, robustness, scalability, performance, maintainability, adaptability, testability, debuggability, security, privacy, safety, fairness, ethics, and transparency—are no less important in the context of AI-based systems. As the reach and influence of software grows, so does the responsibility to ensure that it does not expose those who depend on it to unnecessary risk. AI software developers should commit to embedding these quality attributes actively in AI development process and gain the software community’s trust with dependable metrics.
• Coordination and disclosure are important parts of CVD. Coordination is the most important part of CVD. When one individual, organization, or entity knows about a problem and another individual, organization, or entity can fix that problem, there is a need to coordinate. Disclosure is a close second. Informed consumers make better choices.

One can even see vulnerability as essentially the least important part of C-V-D in this case. Asking, Is this an AI vulnerability? is less important than, Do we need to do something (Coordinate and Disclose) about this undesired behavior in this AI system? This highlights the importance of transparency as it relates to the coordination of disclosure in modern AI system vulnerabilities.