devopsy.kinsta.cloud

Tag: open source governance

Are Developers Responsible for Open Source Governance?

There are lots of factors in the open source software world converging to make it a big year for “shift left” in software development. Heightened security concerns, an increasing need for software supply chain visibility and the growth and complexity of open source ecosystems will continue to push the responsibility for ensuring code is secure earlier in the engineering process as far left as the request and design phases.

This means 2021 will be yet another year in which developers are challenged to take on more responsibility, and pushed further onto the front lines of open source governance. Developers will need access to the right training, resources and tools to do this job. But they also can’t be successful if they’re expected to do it alone. Shift left can’t mean shifting all responsibility to the developer as the sole protector of secure code and the only go-to open source expert. The reality is that the depth, breadth and complexity of open source governance in 2021 demands a cross-functional team and layered approach.

Equipping Developers With Governance Knowledge

Let’s start with how to better equip developers and other stakeholders in the governance process, including legal, security, IP compliance and product people. These teams need enough knowledge to be aware of the top compliance issues, and their corresponding remediation options, to be active contributors in this rapidly evolving space. Research from Forrester shows that of the top 40 computer science programs in the United States and the top five programs internationally, none include open source licensing and security coding practices in the curriculum.

Instead, it has fallen to the industry itself to impart this expertise on the job. Leading companies are packaging open source training programs into something that resembles standard HR-led and managed training, including check-ins and quizzes to test and solidify knowledge, and regularly updating content and scheduling trainings to make sure people stay abreast of changes and challenges. In the spirit of open source, many industries work collaboratively to share best practices on governance in this regard, with industry experts speaking on the topic at other companies. Others are leveraging existing management training courses, such as the ones offered by the Linux Foundation.

The growing importance of the Software Bill of Materials (SBoM) also points to the need for cross-functional collaboration. Software supply chain visibility will become even more crucial in 2021 so that companies can build and sell secure and safe products, as well as ensure compliance. More people across the organization will need to access and view the SBoM in ways relevant to their functional needs. As a result, its assembly is transforming from being assembly-line-esque (passed along and viewed in the context of siloed business functions) to becoming much more collaborative. The SBoM is becoming akin to a business intelligence tool, providing the ability for different functions and stakeholders to filter for relevant information.

Depending on your function, you may be interested in a top-down view of the open source and third-party components across your portfolio of products in order to understand risks in the organization. For instance, as an engineering leader, you may want to understand if you are impacted by a new security vulnerability, where in your portfolio of products you may be exposed and the current status of remediation work for that vulnerability. If you are in legal, you may be interested in a significant licensing change for a component in use at your organization. This allows you to be prepared with changes to legal policies for automated reviews and obligation fulfillment guidance for engineering when the next build occurs and a more recent version of a dependency is pulled in. If you are in the export control function, and are required to provide your application’s encryption capabilities as part of the certification process, understanding which open source components are part of the application, and which provide cryptographic capabilities is essential. Finally, don’t overlook your customers, who today are requiring open source disclosures as part of commercial software contracts to protect themselves from insecure software.

Collaboration has also been made simpler by the fact that new industry standards now enable an asset portfolio view of open source security. Open Chain obtained ISO certification in late 2020, ISO/IEC 5230:2020, providing a clear and effective process management standard for open source license compliance. It allows companies of all sizes and in all sectors to adopt the key requirements of a quality open source compliance program. Coupled with ISO/IEC 27001–the de facto standard for managing security in information security management systems (ISMS) – organizations can now take a more holistic view of all of their software assets in an effort to make the information they hold more secure.

Open Source Program Office

The best way to ensure developers aren’t left footing the bill for open source governance is to create a centralized team dedicated to it. Savvy organizations could form an Open Source Program Office (OSPO), which brings together key stakeholders in legal, engineering, product and security to develop, communicate and operationalize open source strategy for their entire organization. This team works to define a framework and process for consuming open source software as part of their development work (inbound use case) and/or contributing code to the community via open source projects (outbound use case). The mission and main charter of these teams is to help their organization create and manage an open source strategy in terms of the adoption, use, support, participation and development of open source software. However, they’ve also found their role has evolved to become the experts on open source internally and evangelists of the technology and its use.

The bottom line is that the developer’s job is to develop software – and every piece put in place for stronger open source governance means less time spent focusing on the problems that could be in the open source code and more time on the promise of using it to rapidly innovate for the benefit of their customers.

April 27, 2021
The 2016 State of Software Supply Chain Report is Here
Our State of the Software Supply Chain Report has just been released. Over the past year, we’ve amassed a great deal of data with respect to the staggering volume and variety of open source components flowing through software supply chains into development environments. This year, we assessed behaviors across 3,000 organizations and performed deep analysis on more than 25,000 applications.

The results we discovered ranged from staggering to surprising to sobering. For example, we measured organizations consuming an average of 229,000 components annually. The good news is, these components help companies accelerate their development and innovation. At the same time, we saw 6.8% of components used in applications marked with at least one known security vulnerability — adding high levels of security debt. Not all components are created equal.

Software supply chain infographic from 2016 report. See full image here.

The 2016 State of the Software Supply Chain Report blends public and proprietary data with expert research and analysis to reveal the following:
- Developers are gorging on an ever expanding supply of open source components. Billions of open source components were downloaded in the last year.
- Vast networks of open source component suppliers are growing rapidly. Over 10,000 new versions of open source components are introduced daily.
- Massive variety and volume of software components vary widely in terms of quality. 1 in 16 parts include a known security defect.
- Top performing enterprises, federal regulators and industry associations have embraced the principles of software supply chain automation to improve the safety, quality, and security of software.
We invite you to read the report and leverage the insights to understand how your organization’s practices compare to others. Then, let us know what you think @sonatype.

If you would like to join a live discussion on this year’s report, please join us on Wednesday, July 13th. Save your seat here.
July 11, 2016
Open Source software license and security management with WhiteSource
With the growing speed and availability of open source components, it becomes easy to add features and integration of software with other components which makes software development easier. But there are a few points to be remembered while using any open source component.
- Security vulnerabilities
- Licensing risks of open source component.
- Outdated open source components.
The above are a very important part of the the software development life cycle to eliminate any discrepancies related to security or legal issues.

WhiteSource provides one fine platform to solve such issues without putting in much effort by developers, They can concentrate on core development instead of spending time on finding these issues which can be easily handled by WhiteSource.

WhiteSource is an open source management solution which does
- Open source licensing and compliance management
- Open Source security vulnerabilities alerts and management
- Executive dashboards, policy enforcement, and reporting
WhiteSource checks your software and generates open source inventory report, including detail from open source. The WhiteSource gathers information on open source components and they keep the inventory updated.

WhiteSource covers almost all commonly used languages and provide detail report, This tool can track all your open source components used knowing or unknowingly within your software.

It sends alerts for any potential issue observed in open source component used by software. It does check for outdated/expired component, It provides detail on security issues found in any opensource component.

WhiteSource does not store (keep track of) any software component which is not open source, this means it’s safe and your code will not be touched.

CI tool Integration (Jenkins)

The best part of the tool is that it has plugin available for the widely used CI tool – Jenkins.

WhiteSource Jenkins plugin is the best and easy way to integrate with WhiteSource to run the checks during build and integration phase in an automatic way.

Its very easy to use, not even just for Maven project also for free style projects.

Easy to configure and use within project. Only token needs to be added and plugin automatically takes care of everything.

Multiple options are available at job level to define the project and modules to be included.

Logs are pretty descriptive when plugin start processing in Jenkins job.

WhiteSource basic principle talks about

Managing the component vs governing the component.

Developers can leave the managing part up to WhiteSource and only concentrate on the issue of governance at the component level in software.
September 18, 2015
The Software BOM Squad
In my previous post, “When Good Code Goes Bad“, I shared new research showing the average large development organization consumes over 15,000 known vulnerable and defective components annually. While we can’t stop software from going bad, there are practices from traditional manufacturers that we can use to improve our ability to recall and fix the “bad” software components.

The Software BOM

A Bill of Materials (BOM) is used in traditional manufacturing supply chains to list the suppliers and parts used in a product, a “software bill of materials“ (BOM) is an inventory of the third party and open source components used to build an application.

A sample software bill of materials lists all open source and third party components, including their version, age, license type, and any known security vulnerabilities.

As noted in Wikipedia, “The concept of a BOM is well-established in traditional manufacturing as part of supply chain management. A manufacturer uses a BOM to track the parts it uses to create a product. If defects are later found in a specific part, the BOM makes it easy to locate affected products.

“A software BOM is useful both to the development organization (manufacturer) and the buyer (customer) of a software product. Builders often leverage available open source and third-party software components to create a product; a software BOM allows the builder to make sure those components are up to date and to respond quickly to new vulnerabilities. Buyers can use a software BOM to perform vulnerability or license analysis, both of which can be used to evaluate risk in a product. Understanding the supply chain of software, obtaining a software BOM, and using it to analyze known vulnerabilities are crucial in managing risk.”

A software bill of materials not only inventories what is used, but in some cases it also syncs with real-time component defect data to indicate which components have known vulnerabilities or license risks. Various software supply chain automation tools expand the bill of software much further, alerting stakeholders automatically when a defect alert occurs. In advanced tools, the entire software lifecycle is automated to ensure that defective components are avoided and continuous monitoring instantly identifies newly announced vulnerabilities as soon as they are discovered.

Breaking Bad

As mentioned in my previous post, When Good Code Goes Bad, there is no way to prevent software from “going bad”. No one is immune from these issues. Therefore, we need to focus on our responses to these issues.

To paraphrase Vince Lombardi, “It’s not how you get knocked down, it’s how you get up”. Following the OpenSSL vulnerability announcement in 2014 (or pick any other new security vulnerability with or without an assigned logo), every development and IT operations team on the planet was asking two questions:
1. Did we ever use that open source component?
2. if yes, where is it?
For those organizations tracking their use of components with a software bill of materials, the answer was easy to find. For other organizations, weeks and often months of research were required. To get a sense of the lack of maturity around traceability practices, take a look at this image from Sonatype research showing announcements of OpenSSL vulnerabilities in products following the initial vulnerability disclosure in April 2014.

Automating Traceability Across the Software Supply Chain

Software supply chain complexities, coupled with the volume and velocity of open source and third-party components flowing through them, are forcing us to think differently about our current practices across development and operations. We are not the first to face these challenges and we can learn a great deal from the mature practices of other high-velocity manufacturing organizations and industries.

One thing is certainly clear. Manual practices of monitoring or occasional checkpoints cannot keep pace with volume and velocity of components being consumed. And if you extend these considerations beyond just open source components and into containers, microservices, or other images used in development and operations, the problem is further out of reach for manual processes to keep pace. The volume and velocity within our software supply chains will not diminish—and without a new approach, the volume of unchecked quality and integrity of parts being consumed will continue to build up as technical debt.

But the answer is here today: automation. Automation can unleash the potential of an organization’s development capacity. Rarely is there such an opportunity to simultaneously increase speed, efficiency, and quality. Solutions that facilitate comprehensive software supply chain automation are poised to usher in the next wave in development productivity—with gains on par or even greater than possible with agile, Lean, and DevOps.

More information on the current state of software supply chain practices as well as examples of best practices being employed by software development teams, can be found in the 2015 State of the Software Supply Chain Report.
July 22, 2015
When Good Code Goes Bad

Milk spoils. Iron rusts. And in software, good code goes bad. Yet the difference is, with the first two, you know the change has occurred. With software, those changes are not always obvious.

Your 5,100 Binaries Went Bad

There is no way to prevent software from “going bad”. As with all products, bugs and defects,are bound to happen at some point. No one and no code is immune from these issues. But who’s looking for the 5,100 software components in your organization that went bad last year (meaning new security vulnerabilities were discovered in them)? It’s all too likely, no one.

Earlier this year, I took a deep dive into the analysis of software supply chains that fuel high velocity development practices and IT operations. The analysis revealed that some of the largest development organizations were consuming an average of 240,000 open source components to expedite development, accelerate innovation, and meet time to release deadlines. While reaping huge benefits from this consumption, these same organizations were unintentionally growing their technical and security debt. How you ask?

Here is a summary of the their average debt:

Source: 2015 State of the Software Supply Chain Report

The analysis showed that over 15,000 (7.5%) of the open source components being consumed by these organizations in 2014 had known security vulnerabilities. Of those 15,000 components, an average of 66% (9,900) had known vulnerabilities dated 2013 or older. That means, they were known vulnerable components (“bad”) before they were downloaded.

The remaining 34% (approx. 5,100) might have actually been “good” components at the time they were downloaded by development teams from public open source repositories, but at some time during 2014 a new security vulnerability was discovered and a CVE identifier was assigned.

Even with the best controls in place to protect developers from downloading open source components with known vulnerabilities, the fact that new vulnerabilities are continuously discovered — about 50 new CVEs are announced daily — means that continuous integration and delivery practices also need to be complemented by continuous governance and visibility practices.

We’re Not Alone

Software development is not the only industry facing such issues of things good things going bad. I bet all of us have received notification from our car’s manufacturer that a certain part is being recalled. While the part was known to be safe when the manufacturer sourced it from suppliers, placed it on the car during assembly and shipped it, discoveries of defects are often found years after the vehicle has been on the road. The same scenario has been played over and over in the food, pharmaceutical, defense, toy, electronics, and other industries.

The difference is those other industries are known to have more mature supply chain practices where they can track and trace every part or ingredient ever used in every product they have shipped. And when a part goes bad, they can recall and repair that defective component.

In software, track and trace practices are still in the earliest stages of maturity. In a 2014 survey of 3,300 development professionals, 63% stated that their organizations have incomplete or no records of the components used in their applications. This lack of traceability means that even when good components go bad, development and IT operations teams have no way to quickly find the defective component and replace it with a better, safer version — dramatically extending mean times to repair, or in the case of no action, growing their technical and security debt. And when applications with those defective components are in the hands of customers, the ability to “recall” the impacted software or distribute newer versions of the application are hindered.

Did he recommend a “Bomb”?

A Bill of Materials (BOM; pronounced “bomb”) is used in traditional manufacturing supply chains to list the suppliers and parts used in a product. According to Wikipedia, “The concept of a BOM is well-established in traditional manufacturing as part of supply chain management. A manufacturer uses a BOM to track the parts it uses to create a product. If defects are later found in a specific part, the BOM makes it easy to locate affected products.”

In Part 2 of this blog, “The Software BOM Squad“, I will introduce the importance of automating the creation of a “software bill of materials“ (Software BOM) to take inventory of the third party and open source components used to build an application. When software components age more like milk than wine, a software bill of materials can help you quickly identify where your 5,100 “bad” component were used.

July 22, 2015