Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: SUSE announces a Red Hat Enterprise Linux fork after Oracle said a similar thing, and Sarah Silverman says OpenAI and Meta have stolen her words. (more…)
Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: Red Hat Enterprise Linux (RHEL) goes closed source. Well—no, not really; but IBM’s lawyers are accused of skating so close to the edge of legality that they risk violating the GNU Public License. (more…)
Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: Alleged theft of GPL code, and Amazon will run its data centers on gas. (more…)
This is the second installment in this series on DevSecOps. Read the first installment, on Static Analysis, here.
One of the better additions to security in recent years is source composition analysis (SCA). The purpose of SCA is to sit in the gap between static analysis and dynamic analysis to help you find issues introduced by included libraries, projects, etc. While effective, source composition analysis is only available on open source libraries and packages, which are the highest growth areas of external sources in any project. If we are purchasing a product to include in our application, we take our time and compare and contrast to make certain we have the right thing. If there is an open source option, we just drop it in. Particularly if the option is popular—little thought goes into using MySQL database in Python or its equivalent in other languages. If a Python project uses MySQL or MariaDB, it is needed, so it is grabbed and used.
The growth of source composition analysis is a great boon to security. Having a tool that takes care of monitoring vulnerabilities in code that is included across the board, sometimes in very uncontrolled ways, means vulnerabilities are known before the app goes live or the new release is published. Security staff doesn’t have to try to ferret out what is included in projects across the org and then cross-reference those findings with the National Vulnerability Database (NVD) or project-specific lists. The tool takes a load off security’s shoulders and makes certain developers know the risks their open source software (OSS) usage represents. The best tools notify developers when including vulnerable open source and can be configured to require approval before a vulnerable OSS library/module can be included.
With all of that said, let’s talk about what to look for. There are some similarities with our static analysis list, but some distinct differences also. Disclaimer: As mentioned in the Static Analysis blog, this is very high-level. The research we’ve done at Accelerated Strategies Group went much deeper than we can present in a series of blogs; this is just to help you understand the top-level issues and get started down the road to a solid DevSecOps plan:
These tools help improve security posture by automating what is an increasingly complex manual process and bringing in vulnerability sources that security (be they secure developers or dedicated security staff) would have to manually look for. They enable shifting OSS vulnerability resolution left, allowing your team to become more agile and proactive. Make certain the tool chosen is the right one for the organization.
As I said in the last installment, you all are keeping the lights on in a truly difficult time, making a tough job look easy. Don’t let vulnerabilities that can be caught easily with these tools but might stay hidden without stop your great work. They are relatively easy to install and configure; once you have them, you have on-demand OSS vulnerability scanning and if you are like most organizations, OSS is a huge piece of your software infrastructure. Keep rocking it, and make sure you are covered for OSS vulnerabilities and licensing.
Open source components are used in most modern organizations, either included directly into software as code or as tools integrated into workflows. In DevOps environments, often a combination of the two occurs. These components can help speed development processes, provide functionality that isn’t otherwise available and decrease operating costs of teams.
To successfully implement open source components, in software or pipelines, teams need to carefully evaluate what projects are included. Although most open source is free and supported by developer communities, there is no oversight guaranteeing that components are well-made and licensing can vary widely. This means that teams are responsible for ensuring that code is safe, stable and implemented legally.
When you are considering including open source components in your projects and pipelines, it is important to evaluate those components first. A well-developed evaluation process can help teams verify open source components and protect from:
Open source license compliance and legal risk are especially important and complex for commercial development teams. There are more than 200 open source license variations, each with different standards for when projects can be used, by whom and in what capacity. Compliance strategies ensure that you are aware of the licensing requirements of any component you use.
In particular, the things you need to be aware of when it comes to open source compliance is whether projects can be included in commercial products or used by teams of your size and type. If projects cannot be used in commercial projects or require projects to be made open source upon inclusion, you are risking your own intellectual property.
Including open source projects against license can open you to legal action from project maintainers, contributors or third-party organizations. For example, some projects are part of a dual-licensing strategy with companies looking to protect their own financial interests. Or, cases may be brought as a means to raise awareness about open source licensing by concerned community members.
Another possibility is being actively targeted for financial gain. Some projects are contributed to by open source trolls, software developers who have made a business of suing for license non-compliance. These developers take advantage of licenses such as GNU General Public License v2.0 (GPL-2.0), which terminates usage and distribution rights when breached, enabling developers to sue to stop distribution or to demand a portion of profits.
There are several practices you can implement to ensure that your pipelines and products are in compliance when it comes to open source. These practices are especially important to integrate throughout your pipeline to help identify and correct any issues that may exist before products are pushed to production. Below are some practices to get started with.
An OSRB is a group responsible for creating and enforcing open source policies and procedures within your organization. These boards often include members from development, operations, legal and management teams.
OSRBs can serve as advocates for open source use with executives and stakeholders. They can also serve as a source of information for teams looking to incorporate or contribute to open source projects. These boards can help you ensure that you remain in compliance while deriving the greatest benefit from open source.
Compliance policies should be created and incorporated into all steps of the software development life cycle (SDLC). These policies should outline how components are vetted, by whom, how and when components can be included, and how tracking is done.
Ideally, compliance processes and policies should be built into your pipeline processes. For example, by returning builds to developers if they include blacklisted licenses. By incorporating compliance, you reduce the chance that it is overlooked and minimize interruptions to productivity. Incorporation also helps you ensure that licensing issues are found sooner rather than later, minimizing the impact if components need to be replaced or removed.
While there are many licenses that open source projects can fall under, there are several that are significantly more common than others. For example, MIT or Apache—for these licenses, you can simplify compliance procedures by creating playbooks.
Playbooks outline the details of licenses, including license grants, obligations, restrictions and patent impacts. When a developer wants to include a component, they can use these playbooks to quickly determine whether that component is eligible for use. While this won’t eliminate all legal questions when it comes to licensing, it can significantly reduce how often you need to confer with legal counsel about inclusions.
SCA tools can help you identify open source components in your own products and in any tools you adopt. These tools enable you to scan source code to determine what components are inside and create an inventory that you can then use to verify compliance. As a bonus, these tools can also help you identify components with known vulnerabilities, which you can then mitigate.
SCA is especially helpful when you are newly implementing open source compliance policies. It can provide information on the types of components you are already using and help you ensure that those existing components meet your newly applied standards. Some tools even enable you to set up alerts for license conflicts or irregular version use, making verification easier.
Open source compliance is a critical component of most DevOps implementations. To ensure compliance, teams need to carefully choose and then properly keep track of open source components. You can do that by creating an open source review board (OSRB), which can help enforce open source compliance policies. You should also incorporate compliance throughout your pipeline, create playbooks for commonly used licenses and leverage SCA tools.
Open source software has gone mainstream, propelled by the increasing maturity of many communities and tools working together with organizations seeking ways to deploy software faster and cheaper. According to Gartner Research, over 95% of them are deploying open source software, and while it brings many benefits, it also introduces a whole new set of challenges, beginning with choosing the right open source stack. There are multiple risks including disappointing software performance, tools that cannot connect well with others, surprise additional costs, lack of control and security problems.
Choosing the right open source stack is not easy. Many organizations lack the internal expertise to know what to look for or don’t have the time to research open source software sufficiently. Software engineers can’t be expected to become open source market experts overnight.
Some years ago I worked with a team that certified open source solutions to be used in production. We created a list of 42 necessary qualifications to consider, which is (at least part of) the answer: Start by knowing what questions to ask when selecting open source software.
Here are five areas to consider when choosing open source software:
Time: While the ability to download open source and get it running fast might be tempting, it is better to invest in due diligence or think about working with an external specialist who can carry out the research. Take time in building the right solution for your use case(s). It is important to note that open source is often purpose-driven and chosen to perform a specific task; you may need to combine several different projects together to arrive at a complete solution.
The Backers: While volunteers play an important role in successful open source, the fact is that the majority of the most well-known tools have sponsorship. Having a committed backer with a strong track record is a good sign for both longevity and software quality. The example I often cite is the Cloud Native Computing Foundation, which is behind Kubernetes, Linux and Prometheus.
The Community: The commitment and responsiveness of the community are essential. Essential questions to ask include:
The Different Types: Even some very knowledgeable CTOs do not properly understand the different types of open source, especially the difference between copyleft licensing and permissive licensing. Each has very different implications for an organization. The first requires contributors to share their changes with the relevant software community, while the second doesn’t make that obligation. Businesses are nervous about having to share parts of their proprietary source code and possibly their IP, though this only applies if the business modifies the code.
Unforeseen costs are implicit in all of the following categories:
Software Quality and Integrations: It’s important to look at coding practices (do they align with the organization’s own standards?), usability and support for distributed resources. Above all, scrutinize integrations, because one of the biggest risks when building an open source stack is ending up with a bunch of tools that won’t work together or are not all aligned on the use case.
Examine integrations throughout the stack: platform, database, middleware, application runtime and monitoring tools. Look for solutions that have lots of backing and that are known to interoperate well with lots of other solutions, such as Kubernetes. Concentrate on well-adopted language distributions such as OpenJDK, which can run tons of other enterprise-class open source on top.
It can be difficult, but choosing the right components for an open source stack will help make future curation easier and benefits clearer to see. Spending the time on research and asking the right questions from the beginning could save a lot of headaches in the future.