pip 用户对安全的看法¶
问题¶
我们希望了解 pip 用户在使用 pip 安装包时对安全的看法。
研究¶
我们询问了参与者关于他们使用 pip 安装的 Python 包以及他们创建的软件的安全性和完整性方面的行为和实践。
我们要求参与者告诉我们他们多久做一次
对他们使用 pip 安装的 Python 软件进行代码审计
思考他们安装（使用 pip）的（Python）软件的安全性和完整性
思考他们创建的（Python）代码的安全性和完整性
结果¶
虽然参与者认为他们安装 (51%) 和制作 (71%) 的软件的安全性和完整性很重要，但只有不到 7% 的人会对他们使用 pip 安装的包或代码进行代码审计。
这是因为缺乏时间审计大型包、缺乏专业知识、依赖于广泛采用的 Python 包、期望 pip 自动检查哈希值以及依赖于更广泛的 Python 社区充当“煤矿中的金丝雀”。
这种行为在所有用户类型和软件开发经验基线中都很普遍。
这些结果——尤其是缺乏审计包的专业知识——与总体发现相一致，即大多数 pip 用户不是“经过传统培训”（即接受过软件开发正式教育）的软件开发人员，因此缺乏软件开发实践的专业知识和/或正式培训。
维护人员期望用户思考和担心的事情与用户实际担心和思考的事情之间存在着差距。目前，pip 在向用户提供他们安装的软件的保证方面，让用户“自力更生”。这不是批评，而是一个观察。
对问题的回答：在我使用 pip 安装任何 Python 软件之前，我会进行代码审计¶
绝大多数参与者 (82%) 不会（很少或从不）对他们使用 pip 安装的软件包进行代码审计，原因解释如下。
在我使用 pip 安装任何 Python 软件之前，我会进行代码审计 |
回复数量 |
|---|---|
总是 |
3 |
经常 |
9 |
很少 |
66 |
从不 |
68 |
我不确定这是什么意思 |
5 |
没有意见 |
13 |
参与者总数 |
164 |
对问题的回答：我考虑过我安装的软件的安全性和完整性¶
绝大多数参与者确实考虑过他们安装的软件的安全性和完整性——与关于代码审计的回复不同，在某些情况下，参与者尝试验证他们安装的软件的安全性和完整性。
大多数尝试都是由那些具有软件开发经验的人进行的，然而在某些情况下，人们放弃了。
那些没有接受过传统软件开发培训的人不知道从哪里开始。
这两个群体都确定了他们的“影响范围”，并尽力覆盖它。
用户对安全的看法¶
依赖软件包¶
参与者还解释说他们依赖于代码安全扫描和检查软件包。
“我使用 linters（Bandit），我扫描我创建的代码，如果有问题，我会发出红色警报。”
“我使用 Hypothesis 进行模糊测试。”
依赖于良好的软件开发实践¶
一小部分参与者解释说他们有良好的软件开发实践到位，这有助于编写安全的软件。
“我们有一本关于代码伦理的书——我们有强制性的认证。”
“我还依赖于安全策略到位和报告机制。我避开加密，我依赖于其他人。”
在使用过 pip 的哈希检查功能的用户中
一个人发现错误消息“过于烦人且响亮”，并且难以将文件名与哈希值匹配
另一个人发现显式固定哈希值的过程过于繁琐（尤其是对于依赖项）
一位用户提到他喜欢NPM audit，并且希望在 Python 生态系统中看到类似的东西。
时间不足¶
缺乏时间对包代码及其依赖项进行审计被认为是一个非常普遍的原因。在大多数情况下，参与者使用 Python 代码作为实现其目标的手段。
缺乏进行审计的专业知识¶
缺乏审计软件的专业知识或知识主要是由于参与者的专业知识不是软件开发。然而，在参与者是“传统”软件开发人员的情况下，缺乏专业知识也是一个普遍的理由，导致他们没有进行审计。
只使用广泛使用、久经考验的软件包¶
在所有类型的参与者中——专业 Python 软件开发人员和那些将 Python 作为工具使用的人——使用久经考验、高质量的软件包是一个常见的原因。
“久经考验、高质量的软件包”被用户定义为
存在了许多年
在他们的社区或行业中很流行或被广泛使用
拥有响应迅速的维护者
由参与者听说过的人维护
拥有数百或数千个用户
处于积极开发阶段（许多开放的问题、许多分支、GitHub 星星）
公开且透明地开发
他们的历史是已知的，或者可以在公开场合找到
依赖于 Python 社区查找问题¶
存在着对社区发现问题并将其公开的依赖——“许多眼睛浅层错误”。
“我很少进行代码审计。大多数情况下，我依靠社区的意见。我会看看有多少维护者。也许这不是好做法，但我没有时间检查代码。” - 参与者 240315091
只使用内部包¶
“我只安装内部包，因此我不需要担心这个问题。”
这个主题并不常见，主要是在大型软件开发环境或安全至关重要的环境中。
期望 pip 审计包¶
一些用户期望/假设 pip（以及 PyPI）应该“保护”他们免受恶意行为者的攻击 - 例如通过自动检查哈希值或检测恶意软件包。
“如果我亲自下载软件包，我会检查哈希值，但如果它是由 pip 安装的，则不会。我期望 pip 来做这件事。如果它没有这样做，我确实会感到惊讶。每个包管理器都会将哈希值与下载内容进行比较。哈希值在 pypi 上已经是已知的。” - 参与者 240312164（核物理学家）
其他值得注意的评论¶
“从不。我应该这样做，但我从不进行代码审计。我不会偏离，我厌恶风险。我安装的软件包都是已经经过验证的。我认为我的风险面很小。我没有时间或资源来审计它们。我对生态系统有足够的信心，认为它可以自我审计。如果在一个知名软件包中出现问题，社区会众所周知地提出抗议。无论如何，代码审计也不会发现它。” - 参与者 240326752（专业 Python 开发人员）
“在私人级别（工作）上，代码是在内部开发的。我不审计 pypi 上的代码 - 因为没有时间审计依赖项，而且我相信它。我知道他们几年前发生过安全漏洞，但这种情况并不常见。我知道他们不会审计任何东西，但我仍然不会审计代码。”
“我不知道如何进行代码审计，而且我正在为我自己编写这些代码。它会起作用，或者不会起作用。有时我最终会安装 2 或 3 个软件包，然后发现我需要安装其他东西。如果它不起作用，我会继续前进。最后的手段是我自己编写代码。”
“我非常信任 - Python 是开源的，我假设如果一个软件包在 pypi.org 上 - 它一定是好的。我会先安装软件包，然后再查看它。我通过弄清楚来找到一个软件包 - 我们需要执行某个任务，我们在互联网上搜索它，查看文档，我们安装它，然后看看它是否是我们想要的。” - 参与者 240278297
“如果我想安装一个软件包，一定有原因。我想用 PyEphem 计算月球的方位角和仰角。进行代码审计？切。我做的大部分事情都很平淡无奇。它需要满足依赖项，所以我安装了它。我不会进行代码审计。我不在乎。从来没有，但这是其中一件事 - pypi 上的软件包是否与我在 Github 上看到的源代码完全相同？你最终可能会得到以不同方式分发的文件。也许（我没有这样做）因为我太害怕查看了。有一种东西叫做 pip 验（证软件包）哈希值 - 所以这是一个防止这种情况发生的特性。哈希值是什么？我不知道。它位于本地 Python 安装中。” - 参与者 240426799（系统管理员）
“没有（我不审计代码）。[笑] 因为我不会在安装软件包之前阅读数千行代码。天哪。[..] 我找不到它。我是在权衡 - 软件包的受欢迎程度、GH 上的星数。pypi 没有任何 UI 方式来告诉我它有多少下载量。如果它有，我会使用它。” - 参与者 240386315（IT 管理员）
“好吧，我没有能力对像 Numerical Python 这样的东西进行代码审计。我使用的软件包大多数都是巨大的。除了维护者之外，大多数人都不会对这些软件包进行代码审计。我依赖于 pip 中内置的任何东西来进行软件包安全。我还假设如果存在漏洞，有人会发现它并告诉全世界。我真的很懒。” - 参与者 240312164（核物理学家）
“我希望有一些安全顾问，就像 npm 中那样 - 当你安装软件包时，它工作得很好，“这个软件包存在安全漏洞 - 1 个低危，5 个中危，8 个高危。我还没有遇到 Python 软件包的安全问题。” - CZI 召集研究参与者
建议¶
提供软件包安全指南或审计机制¶
在研究期间，一小部分参与者（3-4 人）提到了NPM 审计命令 作为评估软件包安全性的良好方法示例。它可能为如何处理这种用户需求提供了一个模型。
自动检查软件包哈希值¶
pip 应该**默认**在安装过程中检查软件包哈希值，并提供一种方法让用户关闭此行为。
如果无法获得哈希值，pip 应该警告用户并为用户提供建议 - 从最简单的到最先进的。
报告可疑软件包的机制¶
用户应该有一个机制来报告可疑的或恶意的软件包/行为。这个机制应该在哪里存在尚待商榷。最少应该有一个机制让用户标记 pypi.org 上的软件包。
改进 pip 活动输出易于理解¶
现在 pip 的输出非常繁杂，虽然它包含很多信息，但其中很少一部分对用户来说是可感知的 - 意思是丢失在“文本墙”中。
必须重新设计 pip 的输出，以便在适当的时间向用户提供正确的信息 - 包括安全警告。