Ranking of Libraries Requiring Special Security Checks

The fund established by the Linux Foundation Core Infrastructure Initiative, through which leading corporations united their efforts to support open projects involved in key areas of the computer industry, conducted the second study under the Census, aimed at identifying open projects in need of priority security audits.

The second study focuses on analyzing commonly used open code implicitly utilized in various corporate projects as dependencies loaded from external repositories. Vulnerabilities and compromises of third-party component developers involved in applications (supply chain) can nullify all efforts to enhance the security of the core product. As a result of the study, it was determined 10 of the most commonly used packages in JavaScript and Java, whose security and maintenance activity require special attention.

JavaScript libraries from the npm repository:

  • async (196,000 lines of code, 11 authors, 7 committers, 11 open issues);
  • inherits (3,800 lines of code, 3 authors, 1 committer, 3 open issues);
  • isarray (317 lines of code, 3 authors, 3 committers, 4 open issues);
  • kind-of (2,000 lines of code, 11 authors, 11 committers, 3 open issues);
  • lodash (42,000 lines of code, 28 authors, 2 committers, 30 open issues);
  • minimist (1,200 lines of code, 14 authors, 6 committers, 38 open issues);
  • natives (3,000 lines of code, 2 authors, 1 committer, no open issues);
  • qs (5,400 lines of code, 5 authors, 2 committers, 41 open issues);
  • readable-stream (28,000 lines of code, 10 authors, 3 committers, 21 open issues);
  • string_decoder (4,200 lines of code, 4 authors, 3 committers, 2 open issues).

Java libraries from Maven repositories:

  • jackson-core (74,000 lines of code, 7 authors, 6 committers, 40 open issues);
  • jackson-databind (74,000 lines of code, 23 authors, 2 committers, 363 open issues);
  • guava.git, Google libraries for Java (1,000,000 lines of code, 83 authors, 3 committers, 620 open issues);
  • commons-codec (51,000 lines of code, 3 authors, 3 committers, 29 open issues);
  • commons-io (73,000 lines of code, 10 authors, 6 committers, 148 open issues);
  • httpcomponents-client (121 thousand lines of code, 16 authors, 8 committers, 47 unresolved issues);
  • httpcomponents-core (131 thousand lines of code, 15 authors, 4 committers, 7 unresolved issues);
  • logback (154 thousand lines of code, 1 author, 2 committers, 799 unresolved issues);
  • commons-lang (168 thousand lines of code, 28 authors, 17 committers, 163 unresolved issues);
  • slf4j (38 thousand lines of code, 4 authors, 4 committers, 189 unresolved issues);

The report also addresses issues related to standardizing the naming scheme for external components, securing developer accounts, and maintaining legacy versions after significant new releases are made. Additionally, the Linux Foundation has published a document with practical recommendations for organizing a secure development process for open projects.

The document discusses role distribution within the project, creating teams responsible for security, defining security policies, monitoring the privileges of project participants, proper use of Git for fixing vulnerabilities to prevent leaks before patch publication, defining response processes for security issue reports, implementing security testing systems, applying code review procedures, and considering security-related criteria during release formation.

Source: opennet.ru

Buy reliable website hosting with DDoS protection, VPS VDS servers 🔥 Buy reliable website hosting with DDoS protection, VPS VDS servers | ProHoster