February Office Hours: Let's talk about OSS Best Practices

Thanks to all who joined us for our January Office Hours call!

As mentioned on the call, next month’s Office Hours will open a discussion to our customer community around OSS best practices. We ask that attendees consider the following questions for next month and be prepared to discuss them with fellow Sonatype customers:

  1. What should the management strategy be for updating open source libraries? Should we keep them up to date, don’t update unless they’re broken, or update them as you please?

  2. How should you manage vulnerabilities as a general rule or can there be a general rule?

    → Should you fix only vulnerabilities that are applicable for your application and environment?

    → Should you fix components that are used in building or testing the application but not in the
    application itself?

    → Is it simpler to update the component to fix the vulnerability instead of spending the time to
    figure out if it’s applicable?

  3. If you waive a vulnerability in a component, how do you determine if the application or dependencies haven’t changed to invalidate the waiver or open you to the risk?

Start the conversation below or mark your calendar for our February Office Hours call on February 23rd!

1 Like

I see that there are at least 2 sides of this OSS best practices. There’s the user’s side of using open source libraries and there is the developer of the open source library.

On the user’s side:

  1. As a security practitioner, I see several problems with open source libraries that are not regularly updated.
    a. Lower risk vulnerabilities almost never get fixed.
    b. Fixing a vulnerable component often means upgrading to a component with many changes from the one being used. This means more work to upgrade which also means longer fix times that may be a problem if a critical vulnerability is being fixed.
    c. There are many non-security bugs in the component that are not being fixed that impacts availability, reliability, and other quality/correctness.
  2. Often times, we see components that are no longer supported or have hit end of life, example .Net framework. I think that developers see components as a snapshot product that does not have a life. This means that we see major disruption in the development processes and flow when a framework has to be upgraded because EOL or component is not supported.
  3. The developer’s don’t see the need to update when they believe the component works for what they want to do. Updating just means wasted development resources.
  4. We also see the other side where a developer leaves version numbers blank in their package management system. The build will bring in the latest and greatest. This can lead to inconsistent testing and execution.
  5. Our developers do not usually create unit testing around the imported components to verify that the open source libraries are working as expected.

On the developer’s side:

  1. The code is provided as is. The developer doesn’t have time to add in good software quality development practices.
  2. Many levels of competency for developers.
  3. There doesn’t seem to be a development set of practices that should be followed for open source developers so that components can be used by others.
  4. How does a developer provide a quality score out to users so that their component could shine over others?
  5. Is there an expectation that “professional” open source projects and components are “owned” by some kind of organization like Apache? Will that mean that the components sourced from these organizations are of higher quality?
  6. Could an OSS developer use some quality scoring software to provide better knowledge to users about the quality and fit for use of components versus others?
  7. Can we provide a OSS developer rating on the developer themselves to know who has a reputation for quality well built components?

Hi, Ron. I think one best practice pertains to the steps taken once a vulnerability is discovered in a dependency. It often seems that, when a vulnerability is discovered in a dependency, the natural tendency is to either notify the maintainer of the code (expecting them to fix or update it) or to do nothing. Instead, in keeping with the true nature of open source software, anyone should feel free to fork the code, make the necessary updates/fixes, and then push it back for the maintainer’s consideration so that others using the dependency can benefit.

1 Like

Really appreciated the additional discussion we had during February Office Hours. Here are just a few key points customers shared with one another during the call:

  • One way to help prioritize OSS updates and/or remediation of vulnerabilities is to work with the development teams to schedule them into a sprint as part of the regular development cycle.
  • An approach like the above, of course, requires buy-in across teams and at the Executive Sponsor level to ensure that this work is deemed important enough to be scheduled in, possibly at the expense of releasing certain features or functionality.
  • The benefit of doing so (i.e., scheduling in OSS updates as part of a regular development cycle), however, is that it’s likely there will be fewer issues when an “event” necessitates updates to libraries/frameworks. For example, if a team hasn’t been able to prioritize staying relatively up-to-date on their OSS versions, more things are likely to break (if not having to be completely refactored) during the upgrade process when it is finally prioritized.

Did I miss anything? What other thoughts/best practices would you share around how your organization manages OSS?


I know it’s been a bit of time since this initial discussion, but I did want to call out a helpful new resource that was released yesterday, The Definitive Guide to Open-Source Component Best Practices.

This is a great continuation of the discussion that was had at both our February Office Hours call and in this thread, focusing on best practices on OSS components– how to choose them and protect yourself from their associated risks

This guide is a work in progress and will continue to be updated with material as time goes on.

We’d love to know what you think, if you have anything to add, and if you’d like to see more resources like this in the future.