Cybersecurity, Evaluate Risks of Code Libraries

A guide to help identify risks in third party software libraries

The purpose of this document is to help development teams associated with the University of Illinois fulfill their responsibility to comply with Illinois Cybersecurity standards, including IT-7, IT08, and IT13.

Use this document to guide discussions on your development and operations (DevOps) team of adopting a new code library.

Checklist

  • Frequency and cadence of updates

    • A year without updates can be a sign of an abandoned library.
    • Are vulnerabilities or serious bugs unresolved?
    • Does the repository have a security policy?

  • Resilience

    • How many people are using this library? (NPM downloads, GitHub stars, etc.)
    • How many people are actively contributing to this library? (GitHub contributors, etc.)
    • Does the code license and community size allow new maintainer(s) to take over?

  • Effort / Support Expectations

    • Is the library supported by an organization, a group or an individual?
    • Do the supporters have a history of timely responses to issues?
    • Is an End of Support Date documented and acceptable?

  • Spyware / Malware / Backdoors

    • Libraries less than 30 days old are substantially more likely to be undetected malware.
    • Is the library source code available for review?
      • Have alarming issues been raised?
    • If the library exfiltrates data, is that acceptable to your organization?

  • History

    • Longer history implies a longer future
    • Vulnerability history suggests how frequently we may need to patch this library, in the future.


Keywords:
security, developer, sdlc, cybersecurity, devops, secdevops, source, code, programming, software development, code review, vulnerability 
Doc ID:
164700
Owned by:
Security G. in University of Illinois Technology Services
Created:
2026-10-08
Updated:
2026-10-09
Sites:
University of Illinois Technology Services