好吧，我不能说什么是行业标准，但我能想到的定期更新软件包的方法之一是这样的：
1.创建包含要更新的软件包的requirements.txt文件。
1.创建一个包含bash命令的python脚本，以更新requirements.txt中的包。
1.可以使用pip freeze更新requirements.txt
1.创建cron作业或使用python schedule库触发定期更新
你可以参考，作为一个例子

• 在Mac上执行cron作业，以：https://www.jcchouinard.com/python-automation-with-cron-on-mac/
• 在python中调度，以：https://www.geeksforgeeks.org/python-schedule-library/

上述方法可以解决更新问题，但可能无法解决兼容性问题。

重要的不是那么多的电流，而是没有漏洞，可能会伤害客户和您的公司在任何方式。
工业标准是使用Snyk、Safety、Deptrack、Sonatype Lifecycle等来监控软件包/模块的漏洞，以及支持这些漏洞的持续集成（CI）系统，如Kubernetes中的Docker容器。
部署您在prodd中运行的确切版本并运行漏洞扫描。（所有CI系统都使此操作变得简单）（在运行代码时执行此操作非常重要，因为requirements.txt很可能不会显示所有将要安装的已安装版本）
漏洞扫描器（除了owast deptrack）需要花钱，如果你喜欢最新的，但他们在其最简单的形式只是给予你一个更精确的答案：

• https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=python

您可以基于安全源代码https://github.com/pyupio/safety和上面的CVE列表创建自己的系统，如果在代码中发现任何版本，则使其失败。
当谈到requirements.txt列表时，我们总是使用>=而不是==，并且每天晚上都在测试系统中部署并运行测试，如果测试失败，我们必须手动检查错误并检查和固定发布版本。

通常您构建Docker映像或类似的映像（还有其他VM解决方案，但Docker似乎是最常见/最流行的）。将apt-get update、apt-get install和pip install -r requirements.txt作为Dockerfile的一部分，并使用GitHub or similar将其集成到您的CI/CD pipeline中
这将使用一个定义良好的过程从头开始构建映像。然后运行VM，包括all automated unit and integration tests，并为开发人员标记任何问题。然后，他们的工作是确定他们是否破坏了某些东西，他们是否需要某个依赖项的特定版本，等等。
自动测试通过后，图像二进制文件（包括它“冻结”的依赖项）被推到一个人类可以与之交互并寻找任何奇怪东西的地方。通常有几个这样的environments，名称，数字，细节因地而异--但这种三元组相当常见。它们通常被定义为一个序列，它们之间的选通是手动完成的。这可能是一个典型的规格：
1.开发-这是第一个在自动测试通过后推送代码的环境。失败和奇怪的特性是常见的。如果本地开发人员需要复制一个问题或试验一个无法在本地机器上处理的补丁，他们会把代码放在这里。当基本的手动和自动“冒烟测试”都通过，并且开发团队认为代码稳定时，映像就从开发中毕业了。
1.集成--这个环境属于QA和专门的软件测试人员。他们可能有自己的脚本集要运行，这些脚本可以是自动的、手动的或临时的。这也是负载测试或内部红队攻击安全性的好环境。或者用于由内部可信用户进行测试/探索，这些用户愿意冒偶然崩溃的风险来使用最新的即将出现的特征。QA标记任何问题或奇怪之处，并将问题发送回开发人员。当QA同意代码是生产质量时，图像从集成中毕业。
1.生产环境--这个环境运行的代码有些老，因为所有的代码都必须通过Dev & QA才能到达它，但它可能相当健壮。这里的二进制映像是外部世界唯一可以访问的，也是唯一由SOC仔细监控的。
由于虚拟机映像只编译一次，在将代码发送给开发人员之前，所有三个环境都应该有相同的问题。然后，问题变成了在安全补丁变得太过时之前，或者在客户厌倦等待新功能/错误修复之前，让代码按顺序通过环境，并在每个环境中进行所有必要的检查。
在这个过程中有很多细节，在StackOverflow的sister site for networking administration上有很多问题和答案