The Ultimate Guide to Open-Source Security with Python and R

Best Practices in Open-Source Security: Python, R, and Anaconda

---

For over a decade, Anaconda has been providing secure access to thousands of open-source packages for Python and R. Anaconda gives data science practitioners easy access to the tools they need to innovate and collaborate. They get control over environments—and the resolution of dependencies. Anaconda also provides security teams with the IT governance, auditing, and enhanced security capabilities they need, even in the most sensitive and critical environments.

In light of that experience, our security team has compiled these best practices to use when working with open-source packages for Python, R, and Anaconda.

Managing Packages

• Leverage a private repository: While it is possible to download packages directly from the internet, enterprise organizations benefit from private repositories as this layer of indirection facilitates additional security screening, auditing, and governance. Private repositories (for your organization’s dedicated use) also enable you to own your own uptime and can be implemented in the cloud (SaaS), on-premises, as well as behind air-gapped networks.

• Leverage channels to enable governance: The conda ecosystem, including Anaconda, organizes packages into channels for better management. Organize packages from different source channels into different channels in your private repository. Do not mix packages from different source channels into a single channel as this may introduce dependency and security complications. Channels may also be used to govern access if different teams or use cases within your organization have different policies (e.g., experimental code running on synthetic data in a sandbox may have less stringent security requirements than production code).

• Standardize on a common base and mirror only what you need: For instance, mirror from public repositories only the specific version(s) of Python you intend to use. Being selective reduces the surface area for potential vulnerabilities, the amount of security review you will need to do, and the infrastructure load. Additionally, migrating code between library versions—especially for complex enterprise applications and models—can be a time-consuming and expensive undertaking, so be intentional about version selection. 

Package Sources

Each channel has different goals and constraints. Your different teams and projects may have different requirements. In choosing OSS package sources, Anaconda’s general guidance is to use the channel that best meets your needs and constraints. Here’s a quick overview of how you can think of some of the common channels.

• Anaconda’s package repository: We aim to provide a set of packages useful to data science and machine learning practitioners. Among the many open-source projects that we review, we choose to package and bring to our users those that are both trusted and stable. Anaconda has a dedicated team of engineers to maintain and improve this repository. We also provide commercial support for these packages.

• conda-forge: Community-supported repository that focuses on having a wide range of packages. Often the open-source teams that created the code will maintain their packages here. Support is by the best effort of the community volunteers.

• Astropy, bioconda, and PyTorch: These are specialty community-maintained channels focusing on specific use cases. Sometimes using them requires Anaconda’s default packages to satisfy the missing dependencies and sometimes they are fully self-contained. These are also mostly supported by volunteers.

• Anaconda Business is an enterprise-grade package repository with features such as access control, auditing, and content trust. Anaconda Business also enables organizations to create allow lists and block lists based on various criteria. For example, you can create rules that filter out packages with Common Vulnerability Scoring System (CVSS) scores that exceed your acceptable threshold, or exclude packages with licenses that do not comply with your legal requirements.

Package Versions

Many open-source projects, such as the CPython interpreter of Python, Django, and Nginx, have a few major releases they maintain in parallel. Different versions of the same OSS package come with different capabilities, performance, security updates, and backward compatibility.

When choosing a package version or considering package updates, we recommend evaluating the following criteria which are often available in the changelog of the package:

Support Schedule

Consider the support schedule of the package, as deprecated or EOL (end-of-life) versions of packages no longer receive bug fixes or security updates—at least not from the free community. Bear in mind that the support schedules of different packages may not align neatly with each other. For key packages such as Python or NumPy, plan your sunset/migration strategy well ahead of time.

Breaking Changes

A breaking change means that code developed using an older version of a package does not work properly with updated versions of that package.

If there are breaking changes, our recommendation is to understand the impact of those changes on your existing code. Sometimes your applications won’t use the changed parts of the library, and sometimes the updates will completely break your core functionality. Generally, it is best to choose the latest version that doesn’t contain changes that will affect your code, but there are situations where you will need to upgrade anyway and plan for additional testing and rework.

Critical Updates

These typically include security or critical bug fixes. They are a great source to determine the lower boundary of the package version you need. If there are security fixes in later versions, you should consider moving that version constraint to a later version to ensure you always get those fixes as well.

Interoperability with Other Packages 

As you start to build out an environment, you’ll notice that there are many interdependent packages. It is not unusual for one package to need a specific version of a dependency and another package to require a different version. It can be nontrivial to find a set of compatible packages satisfying complex interdependencies. The best way to achieve this goal is to leverage conda to find a solution. Once conda successfully creates an environment according to your specifications, develop test cases to ensure your code works properly in this environment.  

No Need to Chase the Latest Versions

The OSS ecosystem evolves fast with new packages and package updates available to users every day. It is not necessary, and often undesirable to have the latest version of every package in your environment. More often than not, attempting to have the latest version of everything will lead to package conflicts and environments that can’t be resolved. We recommend setting minimum acceptable versions in your environment and allowing conda to flexibly find the most compatible solution.

Aim for an environment that is capable, secure, and stable enough to conduct your work.

Working with Environments

Instead of having one giant environment for all of your projects, Anaconda advises our customers to have project- or even task-specific environments to avoid dependency issues between different projects. Smaller environments minimize your surface area for potential security attacks and are also faster to create and easier to manage. 

Conda makes environment management easy, and Anaconda recommends our users use conda as their environment manager. Conda works well with both Anaconda and community repositories. With conda, users can easily create and switch between different environments, and perform environment management tasks. To learn more about conda, check out this free conda basics course.

To make it easy for users to get conda, Anaconda provides Miniconda, which is a small bootstrap installer that only includes conda, Python, and their dependencies. The best practice here is to use Miniconda and then install additional packages only as needed.

When upgrading or modifying environments, perform regression testing to ensure environment changes do not introduce unexpected changes to your application or model. You can clone environments or create them from snapshot files to create before and after environments that you can run in parallel for comparison.

It typically takes some iterating to find just the right set of packages for each project. When you are satisfied with an environment, export it to a file, and save this snapshot in your version control system. Besides serving as backup, this mechanism also facilitates reproducibility and collaboration with colleagues.

Dependency Management

Dependencies are an essential part of software development, and it’s important to carefully consider what dependencies to include in your project. Here are some guidelines for avoiding unnecessary dependencies to reduce your chances of vulnerability exposure:

• Only include dependencies that you need. Avoid adding dependencies to your projects unnecessarily or for trivial tasks. Such dependencies can bloat your projects and introduce unnecessary risks. Weigh the benefits of having your own implementation of the functionalities you need against the development and maintenance costs, and make informed decisions.  

• Take dependencies that improve the security or quality of your code. Some security-critical areas like cryptography, input parsers, and the like benefit from specialized knowledge and higher levels of scrutiny that are hard to replicate locally. It is almost always better to choose a well-vetted and maintained library than try to roll your own cryptography or input processing. Numerical libraries are another case where sticking to a well-vetted version is superior to a roll-your-own approach.

• Leverage language features. Some programming languages, like Python, have a  “batteries included” philosophy and provide rich built-in tools and functions. Explore the language’s capabilities and libraries before opting for additional dependencies. When you do need to explore outside of the languages, look for external systems that offer the missing batteries in a coherent fashion.

• Watch out for transitive dependencies. Keep in mind that dependencies that you include in your projects can have their own dependencies, which become the transitive dependencies of your projects. Because of this, a package may have a large dependency footprint. When deciding between multiple packages offering similar functionalities, use the size of the dependency footprint as an additional decision criterion.   

By following these best practices, you can minimize the introduction of unnecessary dependencies and reduce associated risks, while still leveraging external libraries when they provide significant values or address specialized requirements, such as cryptography.

Vulnerability Management 

Package Filtering

As the proverb goes, prevention is better than cure. Defend against supply chain attacks (such as typosquatting, star jacking, and dependency confusion) by mirroring from trusted sources. Shift left and address issues as early as possible by preventing malicious packages from entering your organization in the first place. 

Blocking packages according to their security exposure, such as a vulnerability score exceeding your organization’s acceptable threshold can also be an effective vulnerability mitigation measure. Anaconda Business offers powerful filtering logic to help you screen packages. End users will not be able to access packages that you filter out.

Keep in mind that automatic filtering may potentially cause disruption when business-critical packages are filtered out. It is important to evaluate your organization’s risk based on how you actually use the software. There may be situations where the most appropriate course of action is to override your general filter rules and make a security exception. If so, it is important to properly manage exceptions (e.g., by setting a review date).

Monitoring and Matching

Securing open-source software is a dynamic and ongoing process, as newly discovered vulnerabilities may crop up at any time. It is therefore crucial to stay up to date with the evolving threat landscape and understand how it affects your organization’s particular implementation and usage of OSS.

The National Institute of Standards and Technology (NIST) maintains and publishes the National Vulnerability Database (NVD), which contains entries on security vulnerabilities including those that may affect OSS. Each vulnerability entry in NVD contains important information including Common Vulnerability and Exposure (CVE) identifier (ID), description, severity, known affected software configurations, and more.

Given security vulnerability information, the process of determining what components of the OSS you are using are affected by which vulnerabilities are called vulnerability matching. Matching can be a laborious process, unless you have automated tools, either internally developed or through a third party, to handle this critical task. Organizations with subscriptions to Anaconda’s Business tier or above have always-on vulnerability monitoring and matching performed on OSS packages built by Anaconda. Anaconda is also in the process of expanding vulnerability monitoring and matching to conda-forge packages.

Curating and Interpreting

When security vulnerability monitoring and matching reports that a package is affected by one or more known vulnerabilities, there are two critical steps that follow:

• Ensure that the vulnerability information is accurate 

A false positive match can lead to unnecessary subsequent mitigation measures, causing wasted efforts and disruption to your work, such as the removal of an essential package from your package repository.    

Keep in mind that inaccurate security vulnerability entries in NVD are not uncommon, and it is out of the control of OSS security scanners. To address this issue, Anaconda provides CVE curation to subscriptions of the Anaconda Business tier and above. In CVE curation, Anaconda’s experts research each security vulnerability matched against Anaconda packages, and correct any inaccuracies identified. Equipped with accurate and trustworthy vulnerability information, customers can now interpret the security implications of vulnerabilities with confidence.

• Interpret security vulnerabilities

Based on curated and accurate security vulnerability information, an organization can then holistically assess how the matched vulnerabilities may affect them, by coupling the vulnerability information with how they use the packages affected. Each vulnerability is situational, and interpretation of its security implications is essential in helping organizations in determining the right mitigation measures.

Mitigation 

There are various ways to mitigate a security vulnerability. An organization might need different mitigation measures in different situations.

Updating Versions

OSS projects may publish newer versions of the packages with security updates that fix known security vulnerabilities that they were exposed to. Updating your environment with the newer versions of these packages is one way to mitigate vulnerability exposure.

Package update, as a way to mitigate vulnerabilities, has its own complexities:

• Possible breaking changes

When a newer version of a package contains changes more than security fixes, such as new features, it may have the risk of bringing breaking changes.  

Breaking changes can make originally functional code using an older version of the package dysfunctional. When this happens, the original code needs to be refactored and tested, before they are redeployed to the updated environment with newer versions of the packages.

• Potential ripple impact on the environment

In the event that a package needing a security update has dependencies, also known as transitive dependencies, chances are some of these transitive dependencies might need to upgrade to newer versions for the security updates to work. Updating some of these transitive dependencies could lead to further package updates. 

Conda, as a package and environment management tool, is capable of managing the rippling effect described above. However, it is worth pointing out that a seemingly simple “one-package update” can bring significant changes to the entire environment. It is thus essential to test the updated environment thoroughly before redeploying it.

Package Backporting

Package backporting means porting a security fix released by OSS project maintainers to earlier versions of the packages, which the security fix does not cover. A package receiving security backport still provides the exact same functionality while having the security vulnerabilities addressed. Backporting is typically performed by a third party other than the project maintainers, and it is performed on older versions of packages. 

Package backporting does not bring breaking changes and ripple effect to the environment through transitive dependencies. It gives users enhanced stability of their environment, so they do not need to resort to other more disruptive mitigation measures or they can buy themselves more time to evaluate and prepare for those disruptive changes. 

Despite these benefits, package backporting does have one major limitation—package backporting relies on the availability of security fixes from OSS project maintainers.

• Although typically not performed by OSS maintainers, backporting needs the security fixes to be available in the newer versions of the OSS packages, so that these security fixes can be backported to older versions.

• OSS project maintainers’ promptness in response to security vulnerabilities vary, and hence how quickly a backporting is available will also vary.

The private preview program of Anaconda’s security backporting service will be available to existing Anaconda customers in the latter half of 2023. Interested customers can contact their Anaconda representative to inquire how to enroll. 

User Code Modification 

Modifying user code could be another effective way to mitigate OSS security vulnerabilities. Depending on how complex the security exploits in an OSS package can be blocked, users can:

• Implement constraints on how your code uses the package, as this may effectively block the security exploits. Sometimes it is also possible to disable insecure portions, for example by restricting the algorithms OpenSSL uses to a known safe subset.

• Replace the package with security vulnerabilities with an alternative OSS package or custom code delivering the same or similar functionalities, and update user code accordingly. When replacing a vulnerable package with alternatives or custom code, pay close attention not to introduce other security vulnerabilities or bugs.

As with package updates, user code modification needs to be extensively tested before it is deployed.

Train Your Developers and Adopt Secure Coding Practices

No security tools can fully replace the roles of people and processes in the security picture. Security should be part of the coding process and not an afterthought. Make sure your developers are aware of the potential risks associated with third-party packages, well-versed in secure coding practice, and making security best practices part of their coding. Be proactive in software security rather than reactive. Check out the secure software development guidelines and training materials below, and adopt or adapt them to your organization. 

• OpenSSF Guide for Developing more secure software
• NIST Security Best Practices
• NIST Free and Low Cost Cyber Security Online Content