Hello open source security! Managing risk with software composition analysis

When first learning to code many people start with a rudimentary “Hello World” program. Building the program teaches developers the basics of a language as they write the code required to display “Hello World” on a screen. As developers get more skilled, the complexity of the programs they build increases.

But building a complex app entirely from scratch these days is not the norm because there are so many fantastic services and functions available to developers via libraries, plug-ins, and APIs that developers can consume as part of their solution. If you were building a website to show off your amazing nail art or community farm you wouldn’t build your own mapping tool for directions, you’d plug in a map tool service like Bing Maps. And if another developer has already built out a robust, well-vetted open-source cryptographic library, you’re better off using that rather than trying to roll your own.

Today’s apps are rich composites of components and services—many of which are open source. Just how many? Well, the Synopsis 2020 Open Source Security and Risk Analysis Report found that “open source components and libraries are the foundation of literally every application in every industry.” But just like any other software, open-source components must be assessed and managed to ensure that the final product is secure. So how can you take advantage of the benefits of open source without increasing risk? Software Composition Analysis (SCA)!

SCA Explained

SCA is a lifecycle management approach to tracking and governing the open source components in use in an organization. SCA provides insight into which components are being used, where they are being used, and if there are any security concerns or updates required. This approach provides the following benefits:

  • Quickly respond to vulnerabilities: Understanding which components you are using will allow you to take action when you learn of a security vulnerability. This is critical when components are re-used in a number of places. For example, the infamous “heartbleed” vulnerability in the popular OpenSSL library affected hundreds of thousands of web servers. When the ASN1 parsing issue was announced, attackers immediately began trying to exploit it. Organizations with an SCA program were better able to rapidly and completely replace or patch their systems, reducing their risk.
  • Provide guidance to your developers: Developers usually work under a deadline and need ways to build great apps quickly. If they don’t have a process for finding the right open source component, they may select one that’s risky. An approved repository of open source components and a process for getting new components into the repository can go a long way to support the development teams’ need for speed, in a secure way.

Define your strategy

A strong SCA program starts with a vision. If you document your strategy, developers and managers alike will understand your organization’s approach to open source. This will guide decision-making during open-source selection and contribution. Consider the following:

  • Licensing: Not all open source projects document their licensing, but if there isn’t a license, it’s technically not open source and is subject to copyright laws. Some licenses are very permissive and will let you do whatever you want with the code as long as you acknowledge the author. Other licenses, often referred to as copyleft licenses require that any derivative code be released with the same open source license. You also need to be aware of licenses that restrict patenting. Your strategy should outline the licensing that is appropriate for your business.
  • Supportability: What is your philosophy on support? If you have the right skills, you can choose to support the software yourself. Some open-source companies include support subscriptions that you can purchase. You can also hire third-party organizations to provide support. Make sure your team understands your support policy.
  • Security: There are several approaches that you can use to vet third-party code. Developers can evaluate public resources to uncover vulnerabilities. You can also require that they perform static analysis to uncover unreported security issues. If you want to be more comprehensive add dynamic analysis, code review, and security configuration review.

Establish governance

Your strategy will help you align on objectives and guidelines, but to put it in action, you’ll need to define processes and responsibilities.

  • Approved open source projects: Are there open source projects that are well-aligned with your organization that you’d like developers to consider first? How about open source software that is banned?
  • Approval process: Determine how you will engage legal experts to review licenses, how developers should request approvals, and who makes the final decision.
  • Security response: Document how you will respond and who is responsible if a security vulnerability is reported.
  • Support: Determine how you will engage support when non-security bugs are identified.

Create a toolkit

To manage your open source software, you need to track the components and open-source licenses that are currently in use. It’s also important to scan software for vulnerabilities. Open source and commercial tools are available and can be integrated into your continuous integration/continuous deployment process.

Microsoft Application Inspector is a static analysis tool that you can use to detect poor programming practices and other interesting characteristics in the code. It can help you identify unexpected features that require additional scrutiny.

Build engagement

Building consensus for the open-source security program is just as important as the program components. Make sure all your resources, approved open source licenses, and processes are easily accessible. When you roll out the program, clearly communicate why it’s important. Train your developers in the process and the tools they will use and provide regular updates as things change.

Open Source is a vibrant and valuable part of the development process. With the right program and tools in place, it can also be a well-governed and risk-managed process that helps developers deliver more secure software faster.

Read Microsoft’s guidance for managing third part components.

Find advice for selecting and gaining approval for open source in your organization.

Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity. Or reach out to me on LinkedIn or Twitter.