扫描和审核您的开源软件（OSS）的代码是在遵守一个伟大的第一步。然而，一些机构可能不愿意执行的，因为有关进程如何破坏是其发力的担忧扫描。在这篇文章中，我将探讨几个不同的方法来扫描你的代码OSS和相关的每一个潜在的破坏。我安排从最低到最高的破坏性做法的文章。
方法1：外包
提供你的代码给第三方，如OpenLogic，执行审计可以是侵入性最小的方法。在这种方法中，从你的开发组织会有人需要扫描的代码编写。制剂的量真的取决于你的应用程序。例如，仅提供编译的代码可以显着影响的扫描结果的准确性;你将要提供尽可能多的源代码成为可能。根据你的代码是如何管理的，这可能是一个潜在的冗长的任务。如何代码组织和管理，如果不同的代码组件管理分开会影响它需要多长时间来拉在一起所需的所有代码审计。在任何情况下，准备将代码交付不应该超过几个小时，或几天最坏的情况。
如果审核进行现场，您可以减轻对安全的担忧，让周围的组织外部您的知识产权。但是，如果你需要工作，您的IT组织，以确保在审计将要执行的影响可能会比简单地编写代码，并把它传递给第三方审计更大的附加工作站。
多少准备这样做（自愿或作为审计的要求）可以破坏你的工程工作。例如，具有或准备的材料清单（BOM），并授权法案你知道你的产品的开发使用可加快审核过程开源。但是，如果你还没有在列表中，抽出时间来收集信息，组织可以采取宝贵的开发时间。
在审计过程本身，你可以预期，审计师将要访问您的开发团队为在扫描分析阶段突然出现的问题。例如，审计师可能想知道，如果开发团队知道一些开放源码软件库的由来。是他们作为一个大项目的捆绑组件获得的，还是他们从原作者获得？通常情况下，这是不是非常具有破坏性的并且可以通过设置计划会议，以解决问题，管理好。
您可以预期的下一个影响是对结果的审查和任何后续行动的需要。对结果的实际审查很可能是最少的。然而，如果你正在使用数百个OSS软件包，并且审计报告中包含一个大的BOM，你可能需要一些关键的涉众来审查结果。您将需要与审核员会面，检查报告，并确保您理解结果，以及这些结果如何影响您的组织。
方法2：在内部
然而，最具破坏性的方法将是那些选择在内部执行审计并使用非专用的工程资源进行扫描和分析的组织。
除了上面列出的步骤(为审计准备代码和工作站)之外，您还需要安排工程师的时间来运行扫描并对结果进行分析。这是从工程师的正常任务，如编码、设计、规划等中占用的时间。
分析扫描结果所需要的时间取决于许多因素:使用的OSS数量，是否修改了OSS，项目的大小，项目的年龄，使用的语言，等等。显然，如果您在开发中使用了大量的OSS，那么识别每个OSS项目的分析将花费更长的时间。较老的项目也可能需要更长的时间，因为许多使用的OSS项目可能已经不存在了;这将需要更多的时间来研究和确定有关项目的信息。修改的源代码意味着您将看到更多的“代码段”匹配结果从扫描器，您将需要检查每一个，以确保您准确地报告OSS使用。
如果你的组织有专门的资源来执行扫描和审计，影响将是非常相似的外包选择。然而，你会发现周围开发的OSS审计过程内部专家允许随着时间的推移更快和更准确的结果的好处。
与您使用的方法无关，另一个影响的关键因素是您选择在开发过程中执行扫描的时间。在过程中浏览得越早，预期的总成本和影响就越小。尽早扫描通常可以让您跟踪OSS使用的实时变化，并在需要时立即采取遵从性或补救行动。许多扫描器，如OLEX扫描器，提供了增量扫描功能，允许您定期检查对代码的更改，包括对OSS的添加或更改。
最后，你的审计结果可能会造成一些额外的破坏您的组织。这是很常见的扫描码，就会发现一对夫妇（在某些情况下，不少），你没有想到OSS组件。正如你可能知道，商业和开源软件的软件包，包括其他OSS包。当扫描揭示了意外的代码和开源软件，你就需要采取措施以符合使用在各自的许可证所列的条款。如果你发现你不准备许可，或者没有选择，遵守，你可能决定采取的重写由OSS提供的功能或者以不同的包装替换它的选项。不过，你不需要删除或重写任何开放源代码，只要你采取必要的措施以符合相关的许可证。
什么类型的破坏关心你的？我很想得到您的反馈意见。如果您有其他的想法或意见，请在下方张贴。
