Open source components allow companies to save time and money, improve quality, deliver business agility, and mitigate some business risk. Free and open access to pre-existing software components eliminates the reinvention of wheels and exposes software to a global community of “co-developers,” helping with ideation and expansion.
With so many benefits, it’s no wonder that 85% of a modern application is composed of open source components. In fact, when building applications, enterprise development teams are consuming an average of 500,000 open source libraries annually to help accelerate the pace of software innovation. Unfortunately, not all of these third-party components are trustworthy; when unmanaged, they can lead to devastating consequences. Analysis from Sonatype’s 2019 State of the Software Supply Report shows a 71% increase in confirmed or suspected open source related breaches in the last 5 years.
These truths are not unknown in the market. Using components with known vulnerabilities is A9 on the OWASP top ten list, highlighting its severity. Yet, many developers continue to use known vulnerabilities in production without knowing it. How does that happen? Because most enterprises still don’t have an open source software governance program in place.
Open source governance models
Most IT leaders are familiar with corporate governance and IT governance models; however, the need for a separate governance model for the free-flowing environment of open source is often overlooked. Rather than view this structure as “overkill,” IT executives need to see it as a requirement – especially in digital transformation’s lightning-fast app development.
Three common open source governance models have proliferated in the digital age:
- BDFL (Benevolent Dictator for Life): A single person, usually the project’s initial author, maintains final say on all major decisions. Note that smaller open source projects routinely follow the BDFL model by default.
- Meritocracy: Individuals who have actively led the project take on a decision-making role. In most cases, the meritocracy’s leaders come to consensus via a vote.
- Liberal contribution: This model rewards the people who did the most work with the most influence. Driving to consensus replaces the voting method for decision making.
While each open source organization needs a clearly spelled out governance model to facilitate orderly decision-making, the choice of model is up to the organization. Refer to this trio of templates to determine which approach fits your organization’s goals best:
Digital transformation of business demands that technical infrastructures be able to shift direction rapidly in response to changes in the customer preferences. That’s why taking a componentized approach to software development and especially the heavy use of open source components is so critical in today’s development organizations. In fact, traditional siloed development has given way to team-driven efforts of the newly emerged combined DevOps approach. In this environment, teams come together to build specific functionality which is used again and again by an organization. While this approach fast-tracks development and enables the nirvana of “multiple rollouts a day,” it can create huge problems as well.
Not knowing what’s in your software creates unmanaged risk from security and legal perspectives. But, with the average application containing 106 open source components, how do developers begin to tackle this issue? In this environment, open source supply chain tracking resembles the detailed monitoring associated with agricultural supply chains. For example, if produce is contaminated, it is imperative that the supply chain be able to precisely pinpoint the source of contamination and trace all shipments related to that point of origin.
In open source software development, the scenario is the same but multiplied on a grand scale. When open source components form the basis for many applications through reuse, it is important to be able to track down and rectify the vulnerability of that component in each application where it has been used.
One example of this type of solution comes from Saltworks Security – a joint venture with Orasi Software – partnering with Sonatype. Developers can implement Sonatype’s Nexus platform to scan applications for open source components, develop a Software Bill of Materials, create license and architectural policies, and help continuously identify risk across every phase of the software development lifecycle (SDLC).
Step one is to build a Software Bill of Materials (SBOM) for every application in your portfolio. This exercise will reveal which open source software components your development teams are using where. The SBOM can also describe which of these components have known security vulnerabilities or license risks.
With detailed, accurate intelligence about open source software in the hands of developers, defects and vulnerabilities won’t be passed downstream in the software development lifecycle. As a result, developers will be able to build with confidence and innovate faster.
Next, use Advanced Binary Fingerprints (ABF) technology to scan all application components thoroughly, verifying embedded dependencies and precisely identifying risk.
Conclusions
IT organizations look to open source components to help them recycle and reuse vulnerability-free functionality as building blocks for the digital age. However, this simple-on-its-face approach requires some well thought out standard operating procedures and processes to achieve the rapid-fire innovation IT leaders seek. By following a few baseline recommendations, IT leaders can increase their chances of development success and better align their efforts with the requirements of the business.
First, build a SBOM for every application in your portfolio. The SBOM allows you to quickly pinpoint where suspect open source components are used, offering you a quick way to take a “change once/deploy many” approach to problem resolution. Next, use a well-defined open source governance model to make it clear to the entire organization how decisions are made and who makes them, which enables staff to know where to go for guidance. Finally, employ the same set of open source security tools across the DevOps organization to help teams standardize their approach to security with consistency. Executing these foundational recommendations across a DevOps organization will help build an integrated, high performance group that is prepared and ready to respond quickly to the changing dynamics of digital business.
