Comment éviter les risques lors de l’utilisation d’outils de Machine Learning open source ?

One of the ways you can avoid threats when using open-source tools is to check the SSL encryption and the IP address. Since open-source tools are readily available to everyone on the internet, there are chances of having a hidden threat actor that may harm your data. As a data protection specialist, I can say this confidently, the protection of your system and data is only in your hands. Checking the source of the software, knowing the author or the one who has created this software, and checking their authenticity online will help you resolve your initial queries. An authentic source will have their details in the open along with licensing support.

Checking the source of any open-source tool is a mandate, as it has been found that threat actors have injected malicious codes into the open-source tools. Result: When you download an open-source tool without checking its source, you may download the corrupted one and invite the malware into your network and system. Additionally, be extra vigilant when you download the open-source tool. Reason: There could be a similar-looking URL, but it could have been manipulated. It might look like a legit site, but it takes you to the webpage created by hackers, and when you download an open-source tool from that webpage. Well, you have downloaded a corrupted tool.

Most of the time it’s the lack of proper support when we use an open source due to its dependency on community contributions. Also, i faced scalability challenges when one use it in full production mode, might be good for POC. Last but not the least is the surprise factor that can come any time while using them w.r.t technical limitation, cost , feature wise etc..

When working with open-source tools, ensuring security and efficiency becomes paramount. Automation can serve as a powerful tool - implementing tools like Dependabot, specifically designed to track dependencies and updates, simplifies the management of open-source projects. This method reduces the time and effort required to keep everything up-to-date, enabling a more agile development process. By employing a private artifactory that provides vulnerability reports and policy enforcement, you gain deeper insight into the potential risks associated with an open-source tool. These features enable you to establish clear guidelines and safeguards to protect your projects.

I am not sure what open source machine learning tool we are talking about. Please elaborate little more so easier to contribute.

There are several tiers that are related to the risks when using open-source ML tools 1) library dependencies 2) already revealed security leaks 3) personal data and privacy 4) ethical scrutiny while using Generative AI 5) post-production risks after integrating an open source ML tool to your code base and/or infrastructure. Each topic needs to be investigated during the POC, development and post-installation, and also each topic might need different expertise that can make things more complicated.

One of the things people can check is the issue/discussion forum of the tool. Usually, the forum will show how actively people are using it and how the authors/maintainers treat issues and questions. Another aspect is checking the latest updates and news of the tools. This can make sure it is compatible with the dependencies.

Looking at how many downloads a Python or R package/module has is one place to start. While this isn’t necessarily a substitute for doing our own checks, more popular library will typically have more eyes on it, both from the development side and from those using it in their own models.

@Jana What tools have you evaluated can you please give details. I am keen to learn more then able to suggest my opinion.Thanks

Security risks are paramount when dealing with open-source tools. You need to be vigilant and be aware when downloading the tool. Quality evaluation of an open-source tool becomes a mandate because the source code is easily visible to everyone, threat actors can use it to find security loopholes and exploit them to their advantage.

When you're dealing with sensitive data, it's essential to go the extra mile to safeguard data privacy. This means either anonymizing or encrypting the data as necessary, all while staying aware of any legal or regulatory requirements that apply. Additionally, ensure that data transfers always happen over secure connections. Remember to remove or replace any identifiable information to protect privacy, and it's a good practice to regularly review and delete data that's no longer needed. If your machine learning models happen to expose APIs, make sure to secure them using authentication and authorization methods like API keys or OAuth.

Most of the common ways of securing data ( Encryption/ Tokenization/ HTTPS etc) are well established patterns. The most important thing is to know your data and be aware of PII and other confidential attributes in your data . Even when not using any Machine learning tool, these security aspects of your data should be taken into consideration. Off Course when using Open Source tool these aspects becomes even more important to be considered.

I find it’s helpful to let an IDE like Anaconda do a lot of the heavy lifting for managing package dependencies. Using one of these environments helps us focus on the code instead! Also, keep an eye on the updates when they come out for packages and environments we do use, as well as any issues that others see in the dependencies and environments.

There could be other compatibility risks: 1. Check Dependencies: Some libraries depend on specific versions of other libraries. Always check these dependencies to avoid conflicts. 2. Check for Updates: Updates to a library can sometimes break compatibility with other libraries or with your own code. Use version control to manage this. 3. Use Virtual Environments: (Super important!) This allows you to isolate dependencies for each project, reducing the risk of conflicts.

Our company places a strong emphasis on managing dependencies effectively when utilizing open-source tools; we achieve this by running them in isolated environments. By using virtual environments and containers, we create isolated environments where dependencies can be controlled, preventing conflicts, errors, and manage dependencies, ensuring tools like elastic can operate independently, rather than relying on the out of the box elastic cloud. Additionally, we regularly perform checks to identify and resolve any issues that may arise due to software upgrades and dependencies, ensuring the reliability and stability.

Some common types: MIT License: Permissive; requires attribution. GNU GPL: Derivative work must be open-source. LGPL: Like GPL; exceptions for linking. Apache 2.0: Permissive; grants patent rights. BSD: Permissive; variations in redistribution terms. MPL 2.0: Mixing allowed; MPL changes must be shared. CDDL: Allows mixing; changes must be shared. EPL: Like LGPL, more permissive in parts. AGPL: Like GPL; networked use mandates open source. Creative Commons: Range from attribution to share-alike. Custom: For example, The LLAMA 2 Community License by Meta grants a non-exclusive license for the Llama Materials with guidelines for use and distribution. Notably, entities with over 700 million monthly users must seek special permission from Meta.

License management and compliance are essential for organisations that engage with multiple open-source projects. Tools like Fossology are designed to facilitate this process. Fossology provides a comprehensive overview of licensing commitments by tracking open-source licenses across projects. It ensures adherence to legal obligations, minimises risks and promotes responsible utilisation of open-source materials.

There are several legal risks while using open-source tools and libraries, thus: 1. Review Licenses: Different open-source libraries come with different licenses. Make sure you understand the implications of each license, especially if you're using the library in a commercial application. 2. Contribution Agreements: If you contribute to an open-source project, understand the terms under which your code will be used. 3. Attribution: Some licenses require that you give appropriate credit. Make sure you follow these guidelines.

Reviewing the license is crucial when using open-source Machine Learning tools. Understand rights, obligations, usage, and compliance. Respect developers' work, acknowledge sources, and consult legal experts if needed. It's not just wise; it's a responsibility.

The following should be the strategy if the product is being commercially distributed i.e. transferred from within your environment to the client environment: Permissive Category: Friendly terms, ensure to provide attribution. Weak-Copyleft Category: Semi-friendly terms, share modification and ensure to provide attribution. Strong-Copyleft Category: Conservative terms, avoid using. However, there are exceptions.

I think another important factor to consider is ensuring continuous support for the open-source machine learning tools being used. This will help adapt to changing technologies and address emerging security concerns related to the applications being used.

I think something not considered here is the fact that open source tools are *intended* to be more trustworthy, secure, and compatible than proprietary tools. After all, you can see the source code (trustworthiness) and adapt it to your needs (compatibility). It's open for public review, so people can more easily point out vulnerabilities (security). I think this perspective should be taken into consideration here.

In a M&A scenario a dedicated open source legal and technical team should be deployed to unpack the codebase of the target organization to identify copyleft issues and licensing anomalies.