第三方代码的安全审查

信息安全 审计 遵守 代码审查 第三者
2021-08-15 10:57:45

我不熟悉对内部开发的应用程序进行全面信息安全审查所涉及的所有步骤,所以我想知道以下情况是否普遍。

创建一个 Web 应用程序,并在 Microsoft 的 .NET 框架之上运行。

根据安全审查的条款,此处定义为非内部编写的代码(无论正确或错误)的所有第三方代码都需要进行审查。

因此,即使是 .NET 堆栈本身——不仅仅是写在 .NET 堆栈之上的内部代码——也需要进行审计。因此,除了对代码进行初步审核外,还必须审核任何 Microsoft 更新。例如,假设应用使用 MVC 5.2,微软发布 MVC 5.3,应用升级到 MVC 5.3;在这种情况下,应用程序无法通过审核,直到(以及其他测试)MVC 5.3 代码库本身通过审核/审核运行。

这是正常信息安全审查的一部分吗?

在 Microsoft 堆栈上构建应用程序时,对 Microsoft 自己的代码库进行安全审查是标准做法吗?

怎么能假设内部审计和审查过程(使用任何第三方工具)会比微软自己运行的测试更复杂?

这个循环在哪里停止?谁说第三方工具和/或内部测试达到标准?我想也应该对这些流程进行审核。然后对这些审计进行审计......等等等等。在某些时候,这必须停止并且必须有一定程度的信任,对吧?

2个回答

在 Microsoft 堆栈上构建应用程序时,对 Microsoft 自己的代码库进行安全审查是标准做法吗?

不可以。一个原因是您将无法访问专有(Windows、IIS、.Net、补丁)代码,除非您对其进行逆向工程,并且这样做的努力将超过收益。

常见的方法是定义受信任的第 3 方并接受风险。如果您想覆盖 100% 的第 3 方组件,您不仅需要查看 .Net、Windows、设备驱动程序、固件、BIOS,还需要查看硬件。

不,您通常不会这样做,但如果您想准确检查特定代码段正在做什么,您可以在调试器中浏览大部分 .net 支持库。您可能能够使用可以在二进制文件上运行的静态代码分析来扫描一些库,但是对于大型知名供应商,他们已经完成了此或类似测试 - 较小的供应商可能没有。

最终,您需要查看供应商的认证、白皮书、合同、声誉和安全开发实践,以确定与使用代码相关的风险。例如,您可能会根据每个操作系统带来的风险选择某个操作系统而不是另一个,但您不会查看任何一个操作系统的所有源代码!