# A9 - Using Components with Known Vulnerabilities > ***Components such as libraries, frameworks & other modules, almost always run with privileges. Exploitation of a vulnerable component can cause serious data loss or server takeover. Apps using components with known vulnerabilities may undermine app defenses and enable a range of attacks.*** Prevalence of this issue is very widespread. Component-heavy development patterns can lead to development teams not even understanding which components they use in their application or API, much less keeping them up to date. Some scanners such as retire.js help in detection, but determining exploitability requires additional effort. **Impact** While some known vulnerabilities lead to only minor impacts, some of the largest breaches to date have relied on exploiting known vulnerabilities in components. Depending on the assets you are protecting, perhaps this risk should be at the top of the list. How to PreventThere should be a patch management process in place to: * Remove unused dependencies, unnecessary features, components, files, and documentation. * Continuously inventory the versions of both client-side and server-side components (e.g. frameworks, libraries) and their dependencies using tools like [versions](https://www.mojohaus.org/versions-maven-plugin/), [DependencyCheck](https://owasp.org/www-project-dependency-check), [retire.js](https://github.com/retirejs/retire.js/), etc. * Continuously monitor sources like [CVE](https://cve.mitre.org/) and [NVD](https://nvd.nist.gov/) for vulnerabilities in the components. Use software composition analysis tools to automate the process. Subscribe to email alerts for security vulnerabilities related to components you use. * Only obtain components from official sources over secure links. Prefer signed packages to reduce the chance of including a modified, malicious component. * Monitor for libraries and components that are unmaintained or do not create security patches for older versions. If patching is not possible, consider deploying a [virtual patch](https://owasp.org/www-community/Virtual_Patching_Best_Practices) to monitor, detect, or protect against the discovered issue. * Every organization must ensure that there is an ongoing plan for monitoring, triaging, and applying updates or configuration changes for the lifetime of the application or portfolio. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://infosecgirls.gitbook.io/infosecgirls-training/appsec/web-application-pentesting/a9-using-components-with-known-vulnerabilities.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.