Widespread open source usage is simply a fact in organizations of every size, across all verticals. This is not a passing trend – open source usage will continue to grow. Developers are going to keep incorporating open source components into their code: it’s cost-effective, it helps companies accelerate the software development lifecycle (SLDC) and it frees up developers’ time to give their organization’s proprietary codes the extra magic they need to stand out in today’s marketplace.
A recent survey of Github found that virtually all (94%) of those who are employed use open source at least sometimes in their professional work (81% use it frequently), and 65% of those who contribute back do so as part of their work duties. According to the GitHub survey, most developers report that their employers accept or encourage use of open source applications (82%) and dependencies in their code base (84%), but some said their employers’ policies on use of open source are unclear (applications: 13%, dependencies: 11%). 72% say that they always seek out open source options when evaluating new tools.
Reading this survey’s findings, one cannot ignore the fact that open source software usage is growing day-after-day. But unfortunately, many of these open source components come with liabilities in their license agreements, and one out of every 16 open source download requests is for a component with a known vulnerability.
Furthermore, looking at the heterogeneous sources of applications code, one can categorize today’s applications into three main types. Each with its own associated risk level.
The advantages of using open source components are obvious, and organizations are using more and more of them – either in the development of their products or in the internal and devsecops tools that they use. As this practice continues to grow, it’s important to pause for one moment and take a closer look at the processes and tools that we use when we work with open source software.
Old method: No coordinated effort, oftentimes too little too late in the life cycle
New method: Continuous Application Security Testing Security visibility across development life cycle to decrease discovery and remediation time
Agility and modern service delivery are indeed a goal and a reality already at many organizations. However, a recent MSDN blog post about open source management raises the following questions:
A DevOps approach applies agile and lean thinking principles to all stakeholders in an organization who develop, operate, or benefit from the business’s software systems, including customers, suppliers and partners.
DevOps Cycle
By extending lean principles across the entire software supply chain, DevOps capabilities will improve productivity through accelerated customer feedback cycles, unified measurements and collaboration across an enterprise, and reduce overhead, duplication, and rework. DevOps offers a competitive advantage to a business through three dynamic capabilities:
The DevOps approach applies agile and lean thinking principles to all stakeholders in an organization who develop, operate, or benefit from the business’s software systems; including customers, suppliers and partners.
By extending lean principles across the entire software supply chain, DevOps capabilities will improve productivity through accelerated customer feedback cycles, unified measurements and collaboration across an enterprise, and reduced overhead, duplication, and rework. Devops also offers competitive advantages to a business through three dynamic capabilities:
DevOps is a rather new term emerging from the collision of two major related trends. The first was also called “agile system administration” or “agile operations”; it sprang from applying newer Agile and Lean approaches to operations work. The second is a much-expanded understanding of the value of collaboration between development and operations staff throughout all stages of the development lifecycle when creating and operating a service, and how important operations has become in our increasingly service-oriented world.
Going back to open source: if open source is everywhere, it must be managed like any other type of code. So many Application Life-Cycle Management (ALM) systems are handling proprietary and commercial code. So many discussions on methodologies of how to manage code and development processes. But not enough recognition, acceptance and methodology around open source management.
Applying the DevOps cycle to open source management requires the adaption of each of the steps specifically to open source characteristics. This requires a certain expertise – but it’s certainly doable, as many teams who have integrated the DevOps cycle and DevOps tools can tell us.
Agile development requires the product manager and the R&D manager sync, sprint after sprint, on the user stories that will increase application security, regardless of the type of code that is being used, proprietary or open source.
Here is a list of example security focused stories that DevOps teams should push to see as part of the Agile sprints.
Developers want to code. They don’t care much about costs, processes or policies. They want to use good, innovative and easy-to-deploy code. As a development manager or CISO, you are most likely worried about the code components that your developers are deploying.
Not only do you want to know what they are using, ideally, you would like to control the open source components that developers are downloading, limiting them to secure, up-to-date and approved ones.
Such early detection of development issues, shifted left to the component-selection phase, will optimize your DevOps cycle, decrease cost and last but not least, ensure that the released product is the best possible one, security, quality and organizational-policy wise.
As a development manager, you want to make sure that your software goes through build cycles smoothly as possible. You are also most concerned about the percentage of propitiatory code bugs and open source vulnerabilities that can jeopardize the product’s quality or in worst cases- invite cyber-attacks.
As a development manager, you want that every time a new component is added to the build, your pre-integrated open source management tool will automatically calculate and assign a digital signature to that component, cross-reference it against an up-to-date database of known vulnerabilities to determine if it’s an open source component, and alert you on any known issues that are associated with that component.
As a DevOps expert and as a development manager, you want to know how healthy your build is and you want to address issues as soon as possible. Preferably the day after the build and certainly not in a periodic manner, when the product is already being used by thousands of users out there…
Mend Platform: Vulnerabilities Dashboard
Remediating security open source risks should be an easy to handle task when the development manager can easily see the list of vulnerabilities, by priority, and then direct the responsible developer to handle these vulnerabilities, one after the other, leveraging an easy-to-reach ‘Fix’ link to the recommended remediation.
Mend Platform: Security Vulnerabilities
When it comes to open source management, the responsible program manager would want to be on top of all known assets and all known vulnerabilities. That person needs an easy way to download a full and accurate open source Bill of Materials (BoM) report based on the last build.
The responsible development manager may also be asked by the CISO or by the legal parties at the company to address any license and compliance risks. An easy to produce ‘License Distribution’ type of report is therefore a critical type of requirement.
Mend Platform: License and Compliance Risks
Agile development is a continuous process. Sprint after sprint all people involved, from senior to junior, from CISO to product managers, from dev managers to test managers, From IT Ops to program managers; are all devoted to getting the best product out there, functionality, security and quality wise.
An optimized DevOps cycle is a key success factor in detecting issues and handling them as soon as possible, and as part of the development cycle and not after release or deployment.
When open source code is widely spread, an open source management product – continuous and pre-integrated into your DevOps cycle, is a critical enabler that DevOps teams should insist on implementing.