Commercial source code scanning tools have become quite the hot topic for CIO’s, software development managers, in-house counsel, and enterprise architecture teams over the last eight to ten years. The emergence of these new technologies obviously has direct correlation to the maturity of open source software, which is now just as common as commercially-licensed software in medium to large enterprise data centers. Additionally, the distribution of open source into the consumer market is undeniable making source code scanning a critical risk mitigation measure for all companies that are buying or selling modern technology. Today’s article will briefly explain “noise reduction” and the process of using multiple matching techniques in a source code scanning tool.
At a basic level, OSS scanners, such as OpenLogic's OSS Deep Discovery, analyze software development projects looking for components that come from OSS projects. They tie their results to in-depth information about the open source projects, licensing information and even project support. If you're a developer or a project manager here are some reasons you might want to run one on your project.
Using a software-as-a-service (SaaS) open source code scanning and policy management tools is not that different than maintaining sensitive corporate customer data in a SaaS CRM solution. Yet, the latter sees mass adoption while the former still raises security questions and concerns relevant to both.
In my last article, Open Source Software Compliance: How Well Are You Rating Risk?, we took a look at the key factors in determining risk associated with the use of Open Source Software (OSS). In this article I will be discussing how you can use those factors to develop a risk matrix to assist you in assessing your overall risk.
A critical consideration of a corporate open source software provisioning strategy revolves around the maturity of the community and longevity of that community continuing to develop their project.
Many organizations have begun to adopt a “risk rating” as part of their open source software compliance and usage discussion. Some of the information gathering requirements to assess risk will be relatively easy to meet, while others require much more effort. There are many factors to consider when assessing risk and as you decide which factors are important to your organization you will need to examine the size of the time investment needed to research and obtain the information associated with each factor.
The real world example for this level of diligence goes back to having and managing an actionable open source policy. Open source review boards that have monthly, bi -monthly, weekly, or even impromptu daily meetings about what can and cannot be used and under what conditions need the ability to quickly identify and document these occurrences, make decisions, implement critical policy rule changes and communicate all of this easily to the organization. One new or changed file can make a big difference in protecting millions of dollars of development and intellectual property.
If you read a post on The Enterprise OSS Blog, please leave a comment. Let us know what you think, even if it's just a few words. Comments do not require approval, but they are moderated.OpenLogic reserves the right to remove any comments it deems inappropriate.