Hi @tayl7973_1825 , Thanks for the feedback; this is all a relatively new space, so we're in the process of building best practices / advice as well as tools to help teams solve these problems. Right now, based on your suggestion, it sounds like the workflow would require us to manually identify which applications depend on a vulnerable library, notify each owning team You are correct - the SCA Builds & Projects functionality is designed to "provide that link" between specific package versions and specific builds of applications. The builds are a moving target, as they may or may not be active/deployed. The "Project" in ProGet is not intended to the "source of truth" about the project itself, but be sort of sync'd with the truth (e.g. like an Application in BuildMaster). That's why there's a "stages timeline" for builds in PRoGet. hope it fits within their priorities, and then track remediation through individual tickets. Our advice here is to think of it more like, "advise them of the identified security risk and unavailability of the impacted library they are using". Ultimately it should be up to the team (their product owner) to evaluate the risk you identified and mitigate it. For example, TeamLunchDecider1000 can probably live with a security risk, but let the team decide. Once you've removed the library from ProGet, they can't use it anymore and it's "no longer your problem" to worry about or track through tickets. Ideally, we were hoping our package management system — since it already governs distribution and security controls — could act as that “one stop shop” to track and visualize which applications still rely on a vulnerable version along side it's assigned severity rating. ProGet already provides visibility into consumers through SCA, and you can already see how OSS Vulnerabilities impact builds. HOWEVER, our core advice here is to not try to establish your own in-house "vulnerability database" for in-house libraries your organization. Even large orgs (2000+ developers) won't do that. Instead, it's a simple binary decision: PULL or KEEP the library. If you PULL, then notify consumers it's unavailable going forward and let them decide how to mitigate. That approach is superior to OSS Vulnerability workflows, but it's obviously not possible for OSS library authors to do. Cheers, Steve