Close Agile open source tools vulnerabilities

The State of the Software Supply Chain report highlights some developer team best practices to help increase productivity with Agile software development.

Agile software development practices make extensive use of various open source components to help increase productivity, but vulnerabilities are continuously discovered in their various components.

Security weaknesses in open source tools can expose your data to the outside world. Left unchecked, these vulnerabilities can severely hamper software development.

Categorize dev behaviors

Gene Kim, author and DevOps advocate, took a fresh look at the way enterprises use Agile open source components. Kim collaborated with Sonatype on the "State of the Software Supply Chain" report, which examined and documented release patterns of Agile open source tools, along with cybersecurity practices, across 36,000 Java projects and 12,000 enterprise dev teams. It uncovered different software development and cybersecurity hygiene behaviors that they categorized as the following:

  • exemplars
  • laggards
  • features first
  • cautious

Importance of volume of components

Both Java and JavaScript components figured heavily in the adoption of Agile open source tools. In 2018, the number of Java component releases from the Central Repository grew 68% from the previous year to 146 billion. JavaScript components grew even faster -- from 3.5 billion to 10 billion packages per week, representing an annual increase of 185%. One major reason for this growth has been the increased use of automated software development tools and DevOps pipelines.

Open source projects release reusable software components, or packages. A component release is simply a version of that package. "Many people are still not aware of how much developers now rely on open source components to build applications," said Derek Weeks, vice president at Sonatype, which makes governance tools for open source users.

The number of packages downloaded per developer helps illustrate the scale of open source consumption. For example, a company that employs 100 JavaScript developers who each used 53,000 npm packages in a year will have consumed 5.3 million packages.

When organizations realize the volume at which they consume these packages from external suppliers in their software supply chains, they're more likely to want to manage or monitor that consumption, Weeks said. Doing so ensures that the highest quality components are being used.

More secure Agile open source tools

The report hypothesized a number of strategies that might help make software more secure, but when put to the test, no improvements were observed. The only factor that clearly made a difference in the ability to update security vulnerabilities in Agile open source tools was a faster release frequency.

Practices of secure teams

The security performance of enterprise developer teams was quantified based on median time to update as the primary health metric. The security performance metric hinges on the ability to quickly patch vulnerable components without the introduction of new problems. Exemplary teams reported less pain when updating dependencies, and they were more likely to schedule dependency updates as part of their work, to use the latest version of dependencies and to use processes to add new dependencies. Some of these processes included automation, characterizing vulnerable components, generating an SBOM, implementing controls on open source code used in development, and using automated testing tools to enforce compliance and inform developers.

Exemplary development teams exhibited the following:

  • two to three times less likely to consider vulnerable component updates to be painful;
  • 11 times more likely to use some process to add a new dependency;
  • over nine times more likely to have a process to proactively remove problematic or unused dependencies;
  • 12 times more likely to have automated tools to track, manage and/or ensure policy compliance of dependencies; and
  • six times more likely to use the latest version (or latest-N) of all their dependencies.

Central versus local repositories

The Central Repository manager is not a local repository manager, Weeks said. It is a vetted global warehouse that stores all open source components, has millions of users throughout the world and is fed by hundreds of thousands of open source projects.

"It is the modern-day Library of Alexandria for open source components, and it greatly reduces the work required to distribute software components to millions of developers," Weeks said.

A repository manager can help automate various aspects of secure coding practices. It enables you to download, store and manage access to your dependencies all in one place. Increasingly, these repositories store containers and other build artifacts that are used throughout the DevOps pipeline. Commercial repository managers include Sonatype Nexus and JFrog Artifactory.

Internally, developers configure their build to publish artifacts to the repository, and they then become available to other developers. Teams get the benefits of their own private and secure place to house open source and proprietary components. For instance, a complex system might require hundreds of external libraries in an application.

In Java, these libraries are stored in binary files called JARs, and if you work on a complex system, you might require hundreds of external libraries in an application. The primary use of a repository manager is to proxy and cache artifacts from external repositories. When a build needs an artifact, it will automatically query a local repository manager. If that local repository manager doesn't have that particular artifact, it will retrieve it from an external repository server and cache it for later use.

How automation can improve security

Automation can be applied to enforce quality standards right from the start, such as using components considered least vulnerable and with the lowest legal risk, Weeks said. For example, one can apply policies to enforce only the latest versions, which are shown to have statistically fewer vulnerabilities. It can also be used to host other policies, such as licensing or Common Vulnerability Scoring System level.

Automation is also an invaluable way to track and trace what components have been used over time. This is the only practical avenue to understand what's in your software and to track where things are, Weeks said. It helps you stay up to date with components already in your applications and, most importantly, identify vulnerabilities when they arise in components, letting developers instantly track and begin remediation.

Dig Deeper on Software development best practices and processes