{"id":36103,"date":"2026-04-04T03:24:45","date_gmt":"2026-04-03T16:24:45","guid":{"rendered":"https:\/\/www.kaspersky.com.au\/blog\/managing-open-source-vulnerabilities\/36103\/"},"modified":"2026-04-04T03:24:45","modified_gmt":"2026-04-03T16:24:45","slug":"managing-open-source-vulnerabilities","status":"publish","type":"post","link":"https:\/\/www.kaspersky.com.au\/blog\/managing-open-source-vulnerabilities\/36103\/","title":{"rendered":"Open-source vulnerability management architecture"},"content":{"rendered":"<p>As we already talked <a href=\"https:\/\/www.kaspersky.com\/blog\/open-source-vulnerabilities-in-ai-era\/55543\/\" target=\"_blank\" rel=\"noopener nofollow\">in a previous post<\/a>, modern software development is practically unthinkable without the use of open-source components. But in recent years the associated risks have become increasingly diverse, complex, and numerous. When, first, vulnerabilities affect a company\u2019s infrastructure and code faster than they\u2019re remediated; second, data is unreliable and incomplete; and third, malware may be lurking within popular components, it\u2019s not enough to simply scan version numbers and toss fix-it tickets at the IT team. Vulnerability management must be expanded to cover software download policies, guardrails for AI assistants, and the entire software build pipeline.<\/p>\n<h2>A trusted pool of open-source components<\/h2>\n<p>The main part of the solution is to prevent the use of vulnerable and malicious code. The following measures should be implemented:<\/p>\n<ul>\n<li>Having an internal repository of artifacts. The sole source of components for internal development needs to be a unified repository to which components are admitted only after a series of checks.<\/li>\n<li>Performing rigorous component screening. These include checks of: known versions of the component, known vulnerable and malicious versions, publication date, activity history, and the reputation of the package and its authors. Scanning the entire contents of the package, including build instructions, test cases, and other auxiliary data, is mandatory. To filter the registry during ingestion, use specialized open-source scanners or a <a href=\"https:\/\/www.kaspersky.com.au\/enterprise-security\/cloud-workload-security?icid=au_kdailyplacehold_acq_ona_smm__onl_b2b_kdaily_wpplaceholder_sm-team_______953bcbdd08bafe0b\" target=\"_blank\" rel=\"noopener\">comprehensive cloud workload security solution<\/a>.<\/li>\n<li>Running dependency pinning. Build processes, AI tools, and developers mustn\u2019t use templates (such as \u201clatest\u201d) when specifying versions. Project builds need to be based on verified versions. At the same time, pinned dependencies must be regularly updated to the latest verified versions that maintain compatibility and are free of known vulnerabilities. This significantly reduces the risk of <a href=\"https:\/\/www.kaspersky.com\/blog\/npm-packages-trojanized\/54280\/\" target=\"_blank\" rel=\"noopener nofollow\">supply chain attacks through the compromise of a known package<\/a>.<\/li>\n<\/ul>\n<h2>Improving vulnerability data<\/h2>\n<p>To identify vulnerabilities more effectively and <a href=\"https:\/\/www.kaspersky.com\/blog\/cvss-rbvm-vulnerability-management\/53912\/\" target=\"_blank\" rel=\"noopener nofollow\">prioritize<\/a> them properly, an organization needs to establish several IT and security processes:<\/p>\n<ul>\n<li>Vulnerability data enrichment. Depending on the organization\u2019s needs, this is needed either to enrich information by combining data from NVD, EUVD, BDU, GitHub Advisory Database, and osv.dev, or to purchase a commercial vulnerability intelligence feed where the data is already aggregated and enriched. In either case, it\u2019s worth additionally monitoring threat intelligence feeds to track real-world exploitation trends and gain an insight into the profile of attackers targeting specific vulnerabilities. Kaspersky provides a <a href=\"https:\/\/www.kaspersky.com.au\/open-source-feed?icid=au_kdailyplacehold_acq_ona_smm__onl_b2b_kasperskydaily_wpplaceholder_______\" target=\"_blank\" rel=\"noopener\">specialized data feed specifically focused on open-source components<\/a>.<\/li>\n<li>In-depth software composition analysis. Specialized software composition analysis (SCA) tools allow for the correct navigation of the dependency chain in open-source code to fully inventory the libraries being used, and discover outdated or unsupported components. Data on healthy components also comes in handy to enrich the artifact registry.<\/li>\n<li>Identifying abandonware. Even if a component isn\u2019t formally vulnerable and hasn\u2019t been officially declared unsupported, the scanning process should flag components that haven\u2019t received updates for more than a year. These warrant separate analysis and potential replacement, much like EOL components.<\/li>\n<\/ul>\n<h2>Securing AI code and AI agents<\/h2>\n<p>The activities of AI systems used in coding must be wrapped in a comprehensive set of security measures \u2014 from input data filtering to user training:<\/p>\n<ul>\n<li>Restrictions on dependency recommendations. Configure the development environment to make sure that AI agents and assistants can only reference components and libraries from the trusted artifact registry. If these don\u2019t contain the right tools, the model should trigger a request to include the dependency in the registry, rather than pulling something from PyPI that simply matches the description.<\/li>\n<li>Filter model outputs. Despite these restrictions, anything generated by the model must also be verified to ensure the AI code doesn\u2019t contain outdated, unsupported, vulnerable, or made-up dependencies. This check should be integrated directly into the code acceptance process or the build preparation stage. It doesn\u2019t replace the traditional static analysis process: SAST tools must still be embedded in the CI\/CD pipeline.<\/li>\n<li>Developer training. IT and security teams must be intimately familiar with the characteristics of AI systems, their operating principles, and common errors. To achieve this, employees should complete a <a href=\"https:\/\/xtraining.kaspersky.com\/courses\/large-language-models-security\/?icid=au_kdailyplacehold_acq_ona_smm__onl_b2b_kdaily_wpplaceholder_sm-team___xtraining____dde4fe462714dc47\" target=\"_blank\" rel=\"noopener\">specialized training course<\/a> tailored to their specific roles.<\/li>\n<\/ul>\n<h2>Systematic removal of EOL components<\/h2>\n<p>If a company\u2019s systems utilize outdated open-source components, a systematic, consistent approach to addressing their vulnerabilities should be taken. There are three primary methods for doing this:<\/p>\n<ul>\n<li>Migration. This is the most organizationally complex and expensive method, involving the total replacement of a component followed by the adaptation, rewriting, or replacement of the applications built upon it. Deciding on a migration is especially daunting when it demands a massive overhaul of all internal code. This frequently affects core components \u2014 it\u2019s impossible to migrate away from Node.js\u00a014 or Python\u00a02 easily.<\/li>\n<li>Long-term support (LTS). A dedicated support-services market exists for large-scale legacy projects. Sometimes this involves a fork of the legacy system maintained by third-party developers; in other cases, specialized teams backport patches that fix specific vulnerabilities into older, unsupported versions. Transitioning to LTS generally requires ongoing support costs, but this can still be more cost-effective than a full migration in many cases.<\/li>\n<li>Compensatory controls. Based on the results of detailed analysis, a <a href=\"https:\/\/www.kaspersky.com\/blog\/legacy-it-update-troubles-and-mitigations\/48692\/\" target=\"_blank\" rel=\"noopener nofollow\">set of wraparound security measures to mitigate the exploitation risk for the vulnerabilities within the legacy product<\/a> can be made. Both the effectiveness and economic viability of this approach depend on the role of the software within the organization.<\/li>\n<\/ul>\n<p>Security, IT, and business must work together to choose one of these three paths for every documented EOL or abandoned component, and reflect the made choice in the company\u2019s asset registries and SBOMs.<\/p>\n<h2>Risk-based open-source vulnerability management<\/h2>\n<p>All of the measures listed above reduce the volume of vulnerable software and components entering the organization, and simplify the detection and remediation of flaws. Despite this, it\u2019s impossible to eliminate every single defect: the number of applications and components is simply growing too fast.<\/p>\n<p>Therefore, <a href=\"https:\/\/www.kaspersky.com\/blog\/cvss-rbvm-vulnerability-management\/53912\/\" target=\"_blank\" rel=\"noopener nofollow\">prioritizing vulnerabilities based on real-world risk<\/a> remains essential. The risk assessment model must be expanded to account for the characteristics of open source, answering the following questions:<\/p>\n<ul>\n<li>Is the vulnerable code branch actually executed in the organization\u2019s environment? A reachability analysis for discovered vulnerabilities should be performed. Many defective code snippets are never actually run within the organization\u2019s specific implementation, making the vulnerability impossible to exploit. Certain SCA solutions can perform this analysis. This same process permits evaluating an alternative scenario: what happens if the vulnerable procedures or components are removed from the project entirely? Sometimes, this method of remediation proves to be surprisingly painless.<\/li>\n<li>Is the defect being exploited in real-world attacks? Is a PoC available? The answers to these questions are part of standard prioritization frameworks like EPSS, but tracking must be conducted across a much broader set of intelligence sources.<\/li>\n<li>Has cybercriminal activity been reported in this dependency registry, or in related and similar components? These are additional factors for prioritization.<\/li>\n<\/ul>\n<p>Considering these factors allows the team to allocate resources effectively and remediate the most dangerous defects first.<\/p>\n<h2>Transparency is the new black<\/h2>\n<p>The security bar for open-source software is only going to keep on rising. Companies developing applications \u2014 even for internal use \u2014 will face regulatory pressures demanding documented and verifiable cybersecurity within their systems. According to the <a href=\"https:\/\/www.sonatype.com\/state-of-the-software-supply-chain\/introduction\" target=\"_blank\" rel=\"noopener nofollow\">estimates of Sonatype experts<\/a>, 90% of companies globally already fall under one or more requirements to provide evidence of the reliability of the software they use; therefore, the experts deem transparency \u201cthe currency of software supply chain security\u201d.<\/p>\n<p>By controlling the use of open-source components and applications, enriching threat intelligence, and strictly monitoring AI-driven development systems, organizations can introduce the innovations the business craves \u2014 all while clearing the high bar set by regulators and customers alike.<\/p>\n<input type=\"hidden\" class=\"category_for_banner\" value=\"mdr\"><input type=\"hidden\" class=\"placeholder_for_banner\" data-cat_id=\"mdr\" value=\"20672\">\n","protected":false},"excerpt":{"rendered":"<p>How to manage vulnerabilities when developing or using open-source software.<\/p>\n","protected":false},"author":2722,"featured_media":36104,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1999,2993,2994],"tags":[1140,3793,3765,3030,398,3469,268],"class_list":{"0":"post-36103","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"category-smb","10":"tag-ai","11":"tag-ai-agents","12":"tag-cvss","13":"tag-open-source","14":"tag-patches","15":"tag-strategy","16":"tag-vulnerabilities"},"hreflang":[{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/managing-open-source-vulnerabilities\/36103\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/managing-open-source-vulnerabilities\/30368\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/managing-open-source-vulnerabilities\/25418\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/managing-open-source-vulnerabilities\/30215\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/managing-open-source-vulnerabilities\/41643\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/managing-open-source-vulnerabilities\/55554\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/managing-open-source-vulnerabilities\/30484\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/managing-open-source-vulnerabilities\/35755\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.com.au\/blog\/tag\/open-source\/","name":"open-source"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.com.au\/blog\/wp-json\/wp\/v2\/posts\/36103","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.com.au\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.com.au\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com.au\/blog\/wp-json\/wp\/v2\/users\/2722"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com.au\/blog\/wp-json\/wp\/v2\/comments?post=36103"}],"version-history":[{"count":0,"href":"https:\/\/www.kaspersky.com.au\/blog\/wp-json\/wp\/v2\/posts\/36103\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com.au\/blog\/wp-json\/wp\/v2\/media\/36104"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.com.au\/blog\/wp-json\/wp\/v2\/media?parent=36103"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.com.au\/blog\/wp-json\/wp\/v2\/categories?post=36103"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.com.au\/blog\/wp-json\/wp\/v2\/tags?post=36103"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}