我不确定 Ubuntu 当前的软件包安全程序是什么。
当某些内容进入 Ubuntu 软件包存储库时，该软件包是否会受到中央、可信赖的团队的审核，如果是，审核级别是哪一级？
我感兴趣的是包裹是否经过检查：
- 定期匹配已知漏洞/CVE（例如，软件包维护人员会实时收到 CVE 发布的通知，并且删除未修补（由供应商修补）的 CVE 的软件包）。
- 明显的恶意代码（例如反向shell，随机shell代码，木马）
- 代码质量差（例如非预期的命令注入漏洞）
- 对所有代码进行全面的安全审计以查找漏洞
答案1
有几个Ubuntu 档案库中的“口袋”代表不同类型的支持： 中的软件包main由 Canonical 支持，而 中的软件包universe由社区支持。
软件包必须位于主目录中才能成为 Ubuntu 的默认安装。
在开发周期中，开发人员可以建议在主程序中包含的软件包。此过程的一部分是确定某个包是否与安全相关（例如，以特权运行但与不受信任的用户交互、解析复杂格式等），如果是，则要求 Ubuntu 安全团队执行快速安全审查. 我做了很多这样的评论。
我无法对每个提议的软件包进行全面深入的审核。我希望快速了解软件包是否以专业的方式按照现代安全编程标准开发。
我们检查二进制输出，以确保已编译的程序和库已使用标准安全缓解措施例如位置独立执行支持，以实现更好的地址空间布局随机化、Stack Canaries、Fortify Source（捕获一些常见的 C 问题）以及 Bind Now 和 RELRO（缓解滥用符号链接的漏洞）。（我们已针对 Stack Clash 漏洞启用缓解措施，并支持某些较新处理器中的 Intel 控制流完整性检查，但硬化检查还不知道如何检查这些。）我们还验证任何 sudo 规则、udev 规则、setuid 或 setgid 位、打包脚本、启动脚本等，以确保软件包没有意外的特权来源。
我们使用自动扫描程序检查源代码，例如覆盖范围，检查， 和外壳检查我们编写了简单的工具来帮助我们发现常见的编程缺陷（这些工具并非旨在检测缺陷，但提供了一种非常快速的方法来检查例如所有内存分配例程、所有网络例程、所有特权操作系统功能的使用等），使我们能够快速浏览包中可能有缺陷的代码行。
我们可能会发现缺陷，但更重要的是，我们会了解开发人员在编写代码时是否采取了适当的防御措施。我们会了解软件的工作原理、开发方式以及作者考虑的威胁模型。
我们偶尔会进行模糊测试。（模糊测试是简单（且有趣）的部分——要从中获得任何价值，还需要对崩溃进行深入调查以修复它们。这是昂贵的部分。我希望将来能做更多这样的事情，但更有价值的是让人们为项目贡献可以在 oss-fuzz 中运行的模糊测试基础设施，并将结果直接提供给作者。Coverity 也是如此——每次提交时直接运行 Coverity，并在添加新问题时收到电子邮件比单一的“这是 Coverity 发现的问题列表”更有价值。）
根据我们在审核中发现的情况，我们可能会按原样接受该软件包，或者我们可能会要求进行更改，或者我们可能不会接受该软件包进入主软件包。一些项目作者非常乐于合作，并且竭尽全力解决反馈问题。（几乎所有项目作者都很高兴有人阅读他们的代码并提供反馈。）
所有这些步骤都是一次性任务，用于确定哪些包进入主程序。
Ubuntu 安全团队每天执行 CVE 分类任务。我们有一个 CVE 数据库我们用它来跟踪哪些软件包受到哪些缺陷的影响、在 Ubuntu 的哪些版本中、哪些版本已修复、在哪里可以找到修复程序、支持文档、可能有助于降低问题重要性或影响的缓解措施，以及我们在确定下一步要修复哪些软件包时将使用的优先级。我们从 MITRE、NVD、Debian、邮件列表（公共和私人）等收集数据。
安全研究人员和用户向我们报告问题；我们会尽可能进行调查，并在适当的时候将问题转发给上游开发人员。
主程序包获得全面的安全支持：我们从上游作者反向移植补丁，编写补丁并测试程序包以降低引入回归的风险。我们无法发现所有回归问题，但我们的更广阔视角使我们能够发现上游开发人员可能错过的一些回归问题。当发现限制、回归问题或不完整的补丁时，我们会根据需要与上游开发人员和更广泛的社区合作以改进修复。
universe 中的软件包由社区支持：社区成员将准备问题修复程序、构建软件包、测试软件包，并为我们提供补丁程序以供构建和分发。我们验证更改的真实性、验证包装更改、构建新软件包并分发它们。不幸的是，这确实使我们更难知道哪些软件包得到了很好的支持，哪些软件包没有得到很好的支持。（我们正在努力解决这个问题。）我们的一些企业用户将仅使用 main 中的软件包，以确保他们获得对其环境的安全支持。
任何人都可以提交 debdiff 供我们赞助：在 Launchpad 的源包页面上打开一个 bug，将其标记为公共安全，附加 debdiff，描述您的测试，然后订阅ubuntu-security-sponsors。 准备变更一开始可能看起来很难，但有一个庞大的 Debian 软件包使用社区可以提供帮助。
我们还没有针对已在主版本中的软件包进行全面重新审核的项目。我们阅读了大量补丁，寻找软件包中的类似缺陷，并查看了周围的代码，但并不经常从头开始重新审核软件包。
我们提交 LTS 版本FIPS、CC、STIG 和 CIS认证。这些认证为审计具有不同标准的加密和安全敏感包提供了监管框架。认证对某些行业很重要。这项工作会影响并反馈到分发中。审计人员不一定在寻找缺陷，而是要遵守流程、最低安全标准和配置等。但是，对特别重要的软件包的正确性进行双重检查对某些用户来说是至关重要的保证。
除了 Ubuntu 安全团队之外，我们还享受着两个优秀社区的共同利益：Debian 和 Ubuntu 开发者社区都与上游开发者、下游用户以及 FOSS 生态系统中其他开发者建立了关系。每个人都齐心协力提供监督、反馈、合作和沟通。没有完美的软件，但我们社区的共同努力取得了巨大的成果。