Using Open Source

Modern software projects are increasingly dependent on open source software, from operating systems through to user interface widgets, from back-end data analysis to front-end graphics. Open source software has led to some amazing benefits, but they are sometimes accompanied by security risks that must be understood and managed. For the most part, these risks can apply when using any third-party software component, whether open source or commercial.

Learn about Microsoft’s approach for mitigating security risk when using Open Source Software:

Who Wants a Thousand Free Puppies? Managing Open Source Security in the Enterprise. (Presented at LocoMocoSec 2019)

  • Picture_Benefits_of_Open_Source
  • A person is watching his mobile phone.
  • People are having a meeting.

  • Benefits of Open Source

    There are many benefits to using open source software as part of your development process, a few of which include:  
    • Increased time to market. Create software faster by connecting existing components together, rather than implementing them all from the ground up.  
    • Higher quality. All software components may contain defects, but focused effort on specialized software components often results in higher quality than having many engineers solving the same problems many times in isolation. 
    • Community. By contributing new features, reporting bugs, or in general interacting with the open source projects used, you're sharing in both the costs and benefits of the code base.  
    At Microsoft, we recognize the benefits of using open source responsibly when developing products and services and encourage our customers and the larger technology community to do the same. 

  • Security Risks of Open Source

    Open source, like any software, can contain security defects, which can become manifest as vulnerabilities in the software systems that use them. Since source code is generally available for open source components, it can often be easier for security researchers to identify new vulnerabilities, and while most researchers will follow responsible disclosure methods when reporting issues to the maintainer, there is a risk that some vulnerabilities will become weaponized and used to attack systems that use them.


    Exacerbating this, open source components are generally released as needed, often with little to no advance notice to the user community, so when a vulnerability is fixed and a new release is published, there is often a lag until users can upgrade to the new version; this lag can give adversaries time to create and launch an exploit. As a result, it's very important to update open source components in a timely manner, especially when they contain security fixes. 

  • Thinking about Open Source

    Software organizations typically interact with the open source community in a few different ways:  

    • Use—integrating open source components within an application.  
    • Distribute—Releasing an application or component under an open source license.  
    • Collaborate—accepting external contributions (for example via pull requests) to distributed open source components.  
    • Contribute—Submitting patches or pull requests to external open source components. 
    The first item, “use”, presents the clearest security risk to most organizations due to how vulnerabilities in those components can affect the security of the systems that use them. 

Here are the minimum steps you must take to properly manage this risk. 
 
Practice #1—Inventory Open Source
The first step of properly managing the use of open source software components is to understand which components are in use. Even in small organizations, this usually requires automation. Fortunately, modern agile development practices already rely heavily on automated tooling, and so are easily adapted to include capabilities in this area.

There are many tools available in this space, including open source tools like NPM Audit and OWASP Dependency Check, and commercial services like GreenKeeper, Snyk, and WhiteSource Bolt, among many others. We aren't specifically endorsing any specific tool or service here, as they each have different strengths and weaknesses; perform a thorough evaluation before deciding on an inventory solution.

Inventory generation should take place at a natural point in your development lifecycle, such as during pull-request validation or branch merging, with the inventory results being stored centrally and accessible to appropriate personnel (including your security response team). Be sure to include enough metadata in the inventory to identify the application, source repository, version/commit, and other details from which the inventory was derived.
Practice #2—Perform Security Analysis
All identified components should be validated to ensure they are free of security vulnerabilities, to the level of fidelity required by your organization. For example, in increasing order of both cost and fidelity, consider the following activities:

  • Check for public vulnerabilities—ensure the open source components do not contain publicly-known vulnerabilities, such as those with reported CVEs or with vulnerabilities described in other public resources.  
  • Use commercial security intelligence—use additional vulnerability data sources (such as from data vendors) to augment the public vulnerability data.  
  • Perform static analysis—use static analysis tools to validate that the open source components do not contain unreported security vulnerabilities. Report any newly-identified vulnerabilities to the open source project's author so it can be remediated.  
  • Perform comprehensive security reviews—in addition to the prior points, perform a comprehensive security review of the open source component. 

Most of the open source inventory tools described above provide alerting capabilities for public vulnerabilities, with the commercial solutions potentially offering additional security information.
Public Vulnerabilities Commercial Security Intelligence In-House SAST Analysis Comprehensive Security Audits
All organizations that use open source should have a strategy for responding when new vulnerabilities are disclosed. This often takes the form of monitoring the National Vulnerability Database for new information, or using tools built into a package manager (such as NPM Audit). While these certainly provide value, there are a few reasons why organizations shouldn't stop here: 

  1. There is no requirement for an open source project to report vulnerabilities up centrally. Details may exist in a GitHub issue, change log, or commit message, but would not be easily discoverable.  
  2. The vulnerability may have been found by an attacker, or a security researcher that is unwilling to publicly disclose the issue.  
  3. The project author fixing a bug may be unaware that it's actually a vulnerability, and so has no reason to report it. 
Practice #3—Keep Open Source Up to Date
One of the most effective ways to manage security risk related to the use of open source is to keep components up to date, even in the absence of known vulnerabilities. This can be a security benefit because security vulnerabilities are often fixed without explicit public disclosure, and while the engineering cost of doing this isn’t free, benefits extend beyond security (such as engineering agility, taking advantage of new features and bug fixes).
Practice #4—Align Security Response Processes
When a vulnerability is found or reported in an open source component, you should have a strategy for managing the process, which should align directly with your organization’s overall security response plan. At Microsoft, we use the Microsoft Security Response Center to coordinate response activities related to vulnerabilities in open source components.

Review SDL practice #12 Establish a Standard Incident Response Process