Open Source Compliance Guide

Open Source
Compliance,
Security, & Risk
Best Practices
In this e-guide In this e-guide:
• Secure open source Open source software (OSS) has emerged as a go-to application development method for
streamlining coding processes and accelerating time-to-market. But with this open and
components to bypass collaborative environment comes the pitfalls associated with re-cycling intellectual property in
breaches your own product development.
• 5 factors for using open source From hidden security vulnerabilities, to meticulous compliance requirements, to proprietary
licensing risks, it’s clear that a poor open source approach and integration can lead to
code in proprietary software damaging business repercussions. The best measure to avoid these open source mishaps
• Discern these open source starts with self-education. Continue reading to get thorough insights on the ins and outs of
open source usage to ensure compliance and security, while protecting against risks.
license terms to avoid legal
snags
▼ Next Article
• 5 common open source
software licenses you need to
know
• Recent open source flaw

highlights danger of social
engineering hacks
Page 1 of 28
In this e-guide Secure open source components to
• Secure open source
components to bypass
bypass breaches
George Lawton, Contributor
breaches
The Equifax data breach of 2017 provided a wake-up call for businesses that handle sensitive
• 5 factors for using open source data. The company attributed the breach to unpatched open source software -- and it wasn't
code in proprietary software alone. In 2018, security breaches at Aadhaar -- India's national citizen identification database
-- and Alaska Airlines were also the results of unpatched open source software.
• Discern these open source
It's hard to stay aware of problems in open source frameworks, especially less vetted open
license terms to avoid legal source packages that developers use to customize apps.
snags So, ultimately, is open source safe? A survey of more than 2,000 IT professionals conducted
• 5 common open source by Sonatype, a platform that governs open source components, found that 31% of
respondents suspected or verified a breach related to open source components in 2018 -- a
software licenses you need to 55% increase from the previous year. The threats are real, so enterprises have to know how
know to avoid them and secure open source software.
• Recent open source flaw Don't get burned

engineering hacks
Page 2 of 28
In this e-guide

breaches
• 5 factors for using open source

code in proprietary software
• Discern these open source Mik Kersten

The main concern with open source software code is that there's no single governing body
snags that vets each project's components. Open source is not one thing; it's a description of various
technological offerings available for consumption and contribution in myriad ways. Open
• 5 common open source source components can vary quite a bit in terms of reliability, security and quality, said Mik
software licenses you need to Kersten, author and CEO of Tasktop, a value stream management tool provider.
know When developers build on open source software, they can easily bring a significant number of
dependent components into an application. And they can do so without understanding the
• Recent open source flaw components' quality, which makes it easy to expose a project to dubious security setups. The
highlights danger of social concerns aren't only about the code itself, but where it runs -- in the cloud or on premises.
engineering hacks "Once you get burned by that once, you realize the concerns are legitimate," Kersten said.
Vulnerabilities aren't unique to open source
Page 3 of 28
Despite these concerns, open source code can be more secure than proprietary code. This is
In this e-guide true in the case of well-known projects, like Apache Tomcat or Kafka, which boast large
communities of developers that work constantly to improve and secure open source code.
• Secure open source Many organizations have determined how to use open source components in a reliable and
components to bypass safe way.
breaches There are no discernible differences between proprietary and open source security
vulnerabilities, according to Rami Sass, CEO of WhiteSource, an open source license
• 5 factors for using open source management and security company. When an open source security vulnerability is found and
code in proprietary software fixed, the discovery and resolution are published for the entire community to see -- not so for
proprietary software. This transparency around open source vulnerabilities kicks off a race for
• Discern these open source developers to implement a patch before attackers move in.
Enterprises must continuously monitor and take stock of which open source components they
snags use, avoid adding vulnerable components to their software and track down vulnerabilities with
diligence.
software licenses you need to What to make of open source
know Enterprises find they can't fight open source security vulnerabilities with a blanket ban on
• Recent open source flaw open source components, which would result in a lot more work for developers.

engineering hacks
Page 4 of 28
In this e-guide

breaches

Isaac Schlueter
"A typical modern web application pulls over 98% of its code from the open source
• Discern these open source community," said Isaac Schlueter, chief product officer of NPM Inc., a company that maintains
the open source package manager for Node.js. That dynamic represents a massive efficiency
gain for developers compared to an application written entirely in-house, as well as a
snags tremendous amount of shared interest in boosting security within the digital commons.
• 5 common open source Developers can effectively mitigate malware and other threats when they secure open source
software licenses you need to software's chokepoints along such project's supply chains. Schlueter recommended that
teams make decisions based on rational factors so that they don't trade small problems for
know much larger ones. A team might minimize risks through an infrastructure and code audit that
correlates the use of packages with reported vulnerabilities.
highlights danger of social Put management safeguards in place
engineering hacks
One growing concern with open source vulnerabilities arises from complex dependencies in
modern apps. Negligent management practices, not the code itself, are often the biggest
inhibitors of open source usage. Tasktop, Kersten's company, implemented a process in
which its deployment pipeline will automatically stop if an open source library dependency
Page 5 of 28
check fails, even if it's 20 dependency levels deep. If a dependency is not fulfilled, Tasktop
In this e-guide won't release the problematic software.
• Secure open source And, if Tasktop engineers discover an upstream component with a problem, they aim to file a
bug or issue a patch to that project.
breaches "Like many other companies that grew out of open source, we take an active role in
participation and in how we integrate open source into our delivery pipeline," Kersten said.
• 5 factors for using open source "The better you understand the dynamics of the open source ecosystem, the safer and more
productive you will be."
JavaScript-based apps are especially complex -- and problematic -- as one component
• Discern these open source depends on others. For example, a developer might add one JavaScript framework and end
license terms to avoid legal up with over 100 dependent projects sucked into an application. The next time that the
snags framework updates, the application can end up with more dependencies added than anyone
realizes. In 2018, as an example, a hacker deliberately took stewardship of a low-level
• 5 common open source component used in a cryptocurrency wallet and then added code to target the exchange's
customers.
know

engineering hacks
Brian Fox
Page 6 of 28
"Without a system to properly understand and track all of these transitive dependencies, even
In this e-guide your developers may not realize all the extra baggage that gets included," said Brian Fox,
CTO of Sonatype. Any single component, whether it is called by custom code or not, can
• Secure open source introduce an exploitable vulnerability.
breaches Prioritize security, training
• 5 factors for using open source Organizations need better training to secure open source software and consume it with peace
of mind. Even if developers choose libraries with the best ratings by default, such collections
code in proprietary software might not be the most up-to-date libraries with patched vulnerabilities.
• Discern these open source "If we want to look at the challenge of using open source securely, then we need to think
license terms to avoid legal about how it is used and how it can end up in our products," Sass said.
snags Resources like the National Vulnerability Database keep track of known vulnerabilities. Also,
some commercial tools continuously inventory open source components and match them
• 5 common open source against newly discovered vulnerabilities. These tools can catch bugs after the fact and alert
software licenses you need to teams when a new vulnerability pops up.
know Some IT organizations push security testing left, into the development lifecycle, as part of the
developer workbench using software composition analysis tools. With this approach, they can
• Recent open source flaw set automated policies to block vulnerable components from use in the company's software in
highlights danger of social the first place. Just as static code analysis evaluates code quality at check-in, these
composition analysis tools enable developers to analyze code security at check-in.
engineering hacks
Don't forget remediation
In the beginning of an open source security upgrade, it might make sense to triage the
removal of known vulnerabilities from a large code base, said Sergiy Golub, senior
Page 7 of 28
engineering manager at Assembla, a version control and source code management
In this e-guide technology provider. Developers pull specific components of broad open source projects into
their applications to work with the custom code they write; so, a known vulnerability might not
• Secure open source affect an enterprise if it has no use for that questionable bit of code and removes it.
"An open source component may have a legitimate vulnerability, but if the vulnerable bit of
breaches code is not being used by our product, then it does not pose a direct risk," Golub said.
• 5 factors for using open source Organizations should identify the most pressing vulnerabilities so that they can prioritize
remediation activities for efficient use of developers' time and resources.

▼ Next Article
snags

know

engineering hacks
Page 8 of 28
In this e-guide 5 factors for using open source code
in proprietary software
Stephen Bigelow, Senior Technology Editor
breaches
Open source software development establishes an environment in which authors can create
• 5 factors for using open source and release source code for collaborative study, adaptation and redistribution.
code in proprietary software Any enterprise, team or individual can create and release code under an open source license.
Open source components go far beyond mundane UI and utilitarian functions. Contributions
are available in fields as diverse as desktop publishing, AI, mathematics, imaging, data
license terms to avoid legal storage and networking, gaming, education, programming and security. A community like
snags GitHub, for instance, hosts over 100 million repositories created by over 31 million
contributors.
With this embarrassment of riches at their fingertips, teams must make decisions about using
software licenses you need to open source code in proprietary software projects in ways that don't undermine their business
know goals, security or effective development practices.
• Recent open source flaw Advantages of open source software

Developers can easily obtain, modify and integrate countless open source code packages into
engineering hacks diverse software projects. Using open source code to enable basic features and processes in
a proprietary software project can shave time off of development cycles and free code
creators to focus on core and business-enabling functionality.
Page 9 of 28
While open source elements confer tangible benefits for software development projects, they
In this e-guide can impose challenges and limitations on a proprietary application, especially if the project is
intended for commercial use. Organizations should evaluate the management and integration
• Secure open source of software components from other creators, their project priorities, liabilities, licensing and
components to bypass security before selecting open source code for a project.
breaches
1. Open source software integration and
management
Many open source components have a bevy of alternatives and variations. For example,
• Discern these open source developers can select from dozens -- and sometimes hundreds -- of open source UI engine
license terms to avoid legal options. You must evaluate and vet each option to ensure that it will work with your project's
overarching design. Some open source code requires integration with other components, and
snags you should test each integration point to ensure software quality.
• 5 common open source In addition, open source software gets updated to fix bugs, enhance performance and add
software licenses you need to features, which means the proprietary project's components must be reevaluated and vetted
when changes occur to the open source project.
know
Open source code integration into proprietary software can create a nightmare for project
• Recent open source flaw managers. When a distributed software project relies on hundreds of open source
highlights danger of social components, the time and effort it takes to simply keep track of each component, its
compatibilities and its updates can affect the project's development cycle.
engineering hacks
2. Open source code liabilities
The evaluation and vetting process for open source code should include a review of the
component under consideration's roadmap and coding.
Page 10 of 28
A software team may want open source code that meets their pressing needs for certain
In this e-guide functionalities -- but considering only what they need today could bite them later. Read up on
the code's future outlook, including potential major modifications. If the component has not
• Secure open source been updated in a while -- some call these projects abandonware -- or won't fundamentally
components to bypass support capabilities that your project is expected to require in the future, consider using in-
house work or other open source options.
breaches
Open source code offers no guarantees for quality or performance. And unlike commercial
• 5 factors for using open source software, the code typically lacks a warranty to offer recourse for failure or poor execution.
code in proprietary software Businesses take on full liability for their projects' performance, even if the fault of poor
performance or an error lies squarely with an open source code element. When using open
• Discern these open source source code in proprietary software projects, carefully consider the warranties and limitations
license terms to avoid legal of liability delineated in its license.
snags
3. Licensing and intellectual property
While open source software is free to obtain, change and otherwise work with, it is not in the
software licenses you need to public domain. Open source software is released under a license, such as Apache License
know 2.0; BSD license; GNU General Public License (GPL), GNU Library, or Lesser GPL; MIT
License; or Mozilla Public License 2.0. Each license outlines the terms of use and distribution.
Generally, open source software licenses do not significantly restrict a business's ability to
highlights danger of social acquire and use them. So, a proprietary and commercial software product can rely on open
engineering hacks source components.
However, businesses must know if and how a license can cause problems. The GNU GPL
requires users to release any derivative works under the same GNU GPL license. If a
business obtains and modifies open source code under GNU GPL, it must copyleft the
modified code -- meaning release it to open source, as well.
Page 11 of 28
In some cases, the whole software project is considered a derivative work of the open source
In this e-guide code it uses, and all of the proprietary project's source code is subject to open source
distribution under the license terms. For this reason, business decision-makers might prevent
• Secure open source developers from using open source code for a project, even if it fits the group's requirements
components to bypass and criteria for functionality.
breaches Nearly all applications -- 96% of those examined -- contain some open source components,
according to a 2018 survey by application security testing vendor Synopsys. The report found
• 5 factors for using open source that the average application uses over 250 open source components in its build.
• Discern these open source 4. Business priorities

license terms to avoid legal Don't just gauge an open source component's suitability for a project in terms of the time and
snags money that it saves. Evaluate if the component does or does not help fulfill your business
goals.
To gain a competitive advantage, businesses rely on software feature innovation and efficient
software licenses you need to performance. Developers should always look for opportunities to innovate -- whether that
know means they cut project time by slotting in open source code or that they custom-build
components that meet the exact needs of an application.
For example, developers of a visualization and rendering tool project could adopt Blender
highlights danger of social open source 3D modeling software for core functionality, but there's nothing stopping their
engineering hacks primary competitors from doing the same thing. Hence, the resulting tools would lack
differentiation to win over prospective customers.
5. Open source software security

Page 12 of 28
A deep, active open source ecosystem is a breeding ground for both vulnerable and malicious
In this e-guide code. The open source marketplace is the ultimate example of caveat emptor, which in Latin
means "let the buyer beware."
Open source software security relies on community feedback -- which is more effective the
more popular a project is -- as well as routine vulnerability scanning. When using open source
breaches code in proprietary software, businesses must bear the risks and enact security vetting
beyond community input to ensure the software meets their corporate standards. For
• 5 factors for using open source example, developers and testers should examine open source code for embedded spyware
code in proprietary software and other malware, as well as for vulnerabilities that can leave the proprietary software project
open to being exploited by malicious parties.
Organizations that rely on open source code in software projects should use vulnerability
testing tools to ferret out susceptibility to problems like buffer overflows, address protocol
snags spoofing, distributed denial-of-service attacks and cache poisoning. Vulnerability testing can
be incorporated into a software delivery pipeline.
You should evaluate these five key areas for each project and for every piece of open source
code. Open source code components are all governed by specific license terms, are built with
know varying degrees of performance and are subject to myriad potential quality issues.
• Recent open source flaw The common factor across all the cases of using open source code in proprietary software
projects is that the responsibility falls on the business, not the code creator. Devise policies
for how to intelligently use open source software and how to validate, manage and optimize
engineering hacks the code.
▼ Next Article
Page 13 of 28
In this e-guide Discern these open source license
terms to avoid legal snags
breaches
Open source code packages are essential elements of many software projects, as they
• 5 factors for using open source enable fast, creative and collaborative development.
code in proprietary software But open source software isn't public domain. Developers and business leaders must
understand and adhere to open source license terms and conditions that govern distribution
and use.
When license violations occur, the involved parties typically undergo mediation, arbitration or
snags litigation over the matter. If a license holder seeks injunctive relief, it could prevent the
• 5 common open source infringer from distributing the noncompliant software, effectively taking it off the market. There
can even be findings for actual and statutory damages.
know Learn key open source license terminology
• Recent open source flaw Legal standards, processes and outcomes vary among jurisdictions around the world, which
often complicates open source software license entanglements. There are many possible
implications, but many licenses cover the same familiar open source concepts and
engineering hacks terminology. To safely work within an open source software license, developers and software
project teams as a whole must understand this common legalese -- and consult legal counsel
to evaluate any prevailing guidance.
Page 14 of 28
Linking. A software development project can use numerous source code elements. These
In this e-guide elements are linked, or combined, together to create an object, or executable result.
• Secure open source An open source license might specifically address the linking of code organizations release
under that license, possibly limiting the rights to only link that code component with other code
that shares the same -- or a similar -- license. This effectively limits the ways to use that code
breaches package.
• 5 factors for using open source As an example, most licenses, including Apache License 2.0, openly permit linking, while the
GNU General Public License permits linking only with other GPL version 3.0-compatible
licensed code. Other licenses, such as the Creative Commons CC BY-SA, impose copyleft
• Discern these open source restrictions which bind anything derived from original open source code by the same license
conditions.
snags Distribution. Developers almost always redistribute open source software in some form,
regardless of how much they modify it. An open source software license often specifically
• 5 common open source addresses how and where developers are allowed to distribute the code, possibly limiting how
they deploy or share the resulting software project.
know Most licenses, including MIT and BSD, permit distribution on a global basis. They might also
outline the mechanisms of distribution, such as through flash drives or online downloads.
• Recent open source flaw However, the GNU Lesser General Public License, GNU General Public License and Mozilla
Public License impose copyleft limitations to distribution. This effectively means that any
project that results from use of that open source code requires the product to carry a
engineering hacks corresponding GNU license, which might be undesirable for your project scenario.
Modification. An open source principle is freedom to use and modify the code. Developers
rework code for many purposes, such as to improve performance or enhance compatibility.
Page 15 of 28
While an open source license might not restrict the use of a component, it can limit the rights
In this e-guide to modify the code.
• Secure open source BSD and Apache 2.0 permit modification, while licenses like CC BY-SA, GNU and Mozilla
impose copyleft restrictions that require any resulting modified code to carry the same license
type and terms. Some other agreements, such as the Eclipse Public License, impose specific
breaches limitations on modification; for example, if developers modify a program and distribute the
object code but don't charge for it, they still need to make the source code accessible.
• 5 factors for using open source However, no open source license outright prohibits code modification.
Usage. Any organization can redistribute or publish modified, or forked, source code to the
• Discern these open source open source community under a suitable license. However, consider whether an obligation to
release the resulting source code will affect the project. Some development projects generate
valuable intellectual property. Developers should avoid integrating open source components
snags into a code base if they intend to only create a proprietary product, as some licenses obligate
the user to share modified code with the community.
Many open source licenses allow for private use. GNU GPL or Mozilla might obligate the user
to retain the same license as the original code, but these open source license terms do not
know obligate the developer to release their forked source code to the community. Still,
organizations with a sizable investment in intellectual property should pay close attention to
• Recent open source flaw the details of open source license terms and conditions. When in doubt, discuss the protection
highlights danger of social of intellectual property with legal counsel.
engineering hacks Relicensing. When an organization redistributes open source code in its unmodified form, the
code typically retains the same license it initially came with. But when developers modify open
source code and then redistribute it, the business might want to utilize a different license for
the source code or binary code -- a practice called relicensing, or sublicensing.
Page 16 of 28
Open source licenses, such as BSD, Apache 2.0, MIT and others, provide permissive terms
In this e-guide to relicense code. However, Mozilla, GNU and other licenses that impose copyleft restrictions
force open source code developers to use the same license for modified code. And some
• Secure open source agreements, such as CC BY-SA, prohibit relicensing entirely.
When sublicensing code, it's not typically an issue to switch from one with more permissive
breaches legal terms to one with less permissive rules. For example, developers that obtain Apache 2.0
for open source code can modify and relicense it as GNU GPL 3.0 without issue. But it's
• 5 factors for using open source impossible to go in the opposite direction, which presents conflicts in license use as open
code in proprietary software source code evolves.

Five open source licenses you should know
Open source agreements set the terms for how organizations must treat open source code.
snags
While various licenses cover a lot of the same aspects of software development and use the
• 5 common open source same open source terminology, the specific details can vary greatly.
software licenses you need to Review the unique restraints imposed and freedoms granted by the likes of the Apache
know License 2.0, BSD licenses, GNU licenses, MIT License and the Mozilla Public License. Once
you determine which policies fit your organizational needs, you can safely and smartly work
• Recent open source flaw with open source projects.
highlights danger of social Patents and trademarks. Copyright laws typically cover software. Copyright is a type of
engineering hacks intellectual property that gives the creator exclusive legal control over how, if at all, others can
use and copy that work. But businesses are also concerned with patents and trademarks. A
patent gives the owner the legal rights to decide who can make, use or sell an invention --
such as a process, in the case of software. A trademark is a unique identifier, such as a sign,
design or phrase, that relates to a specific product or service.
Page 17 of 28
An open source software license typically covers copyright, and it might also address patent
In this e-guide and trademark terms -- important considerations for a business when intellectual property is
part of its competitive advantage. Say a project involves the use of open source software with
• Secure open source a patented algorithm to accomplish a specific task. Apache 2.0 and GNU GPL allow patent
components to bypass grants, including clauses that protect licensees from code contributors' patent claims, as well
as protect contributors from licensees' claims. However, many open source licenses, such as
breaches
CC BY-SA, do not cover patents. When the software involves patents, the license should also
• 5 factors for using open source accommodate patents.
code in proprietary software When the license includes a trademark grant, adopters can use trademarks related to the
licensed code and its contributors. Trademark grants are relatively rare, and most open
• Discern these open source source licenses do not grant trademark rights -- at least, without specific requests. The GNU
license terms to avoid legal licenses are some that do.
snags
• 5 common open source ▼ Next Article

know

engineering hacks
Page 18 of 28
In this e-guide 5 common open source software
licenses you need to know
breaches
Reuse is not a matter for debate with proprietary software. When developers produce
• 5 factors for using open source software in-house, they create a piece of intellectual property that is guarded through the
code in proprietary software restrictions of a commercial license. But as the industry evolves and adopts open source
software, including as small components within a larger development product, open source
• Discern these open source software licenses take on great importance.
license terms to avoid legal Enterprises and individuals have released a burgeoning volume of open source code subject
snags to far less restrictive licensing, which often grants users rights to examine, alter, use,
redistribute and even resell the code to anyone for any purpose. Open source software has
• 5 common open source had a remarkable effect on software development, as it enables contributions from a global
developer community, sometimes accelerating the creation of powerful new products without
a prohibitive cost or time burden.
know
But licenses sometimes pose challenges with open source software. There are myriad open
• Recent open source flaw source software licenses, and each one imposes some level of binding terms and conditions.
Thus, the challenge with open source software is not only how to access or modify such code,
but rather how to do so while observing the terms of these licenses, and how licenses interact
engineering hacks with each other.
It's easy to forget that there is a difference between open source and free or public domain
software. Licenses govern open source software. There are dozens of established open
source software licenses, each with its own unique, sometimes dramatically different, terms
Page 19 of 28
and conditions. It's crucial that developers understand some of the most vital terms that
In this e-guide accompany various open source licenses to avoid potential legal ramifications.
• Secure open source Here's what developers need to know about five common open source software licenses.
Apache License 2.0
breaches
The Apache License 2.0 provides a broad set of guidelines that apply to both copyrights and
• 5 factors for using open source patents. It's unusual for open source licenses to cover both.
Apache License 2.0 conveys a perpetual, worldwide, non-exclusive, no-charge, royalty-free
• Discern these open source and irrevocable license. Users can reproduce the licensed work, prepare derivative works,
publicly display or perform work, sub-license and distribute the work or changes as either
license terms to avoid legal source code or object code.
snags
When open source software is released under the Apache License 2.0, developers can use
• 5 common open source the licensed software forever, anywhere, without purchase costs or royalties; and they can
redistribute variations on the code under different licenses. These rights cannot be withdrawn,
though there are exceptions in patent infringement cases -- see section three of the license.
know Also, there are some requirements when redistributing the code under Apache with or without
modifications, but those requirements generally relate to how the license information is
• Recent open source flaw displayed and how credit is provided.
engineering hacks
BSD licenses
There are two permutations of the BSD license, which typically applies to software with
virtually no restrictions on distribution and use. BSD licenses, named after the Berkeley
Software Distribution OS, are fairly prevalent, particularly for free software.
Page 20 of 28
The 3-Clause BSD License, also known as the New BSD License or Modified BSD License,
In this e-guide follows a straightforward copyright arrangement. Developers can use and redistribute
software under this open source license in either source or binary forms, with or without
• Secure open source modifications. There are only three points, or clauses, to which developers must adhere:
• users must include the copyright notice, along with the list of conditions and a standard
breaches disclaimer;
• redistributions in binary form must reproduce the copyright notice, conditions and
• 5 factors for using open source standard disclaimer; and
code in proprietary software • neither the copyright holder nor contributors may be used to endorse or promote
products created from the code without separate consent. Therefore, a developer
• Discern these open source cannot fork the code then claim the code creator sanctioned this new version.
license terms to avoid legal The 2-Clause BSD License, also called the Simplified BSD License or the FreeBSD License,
simply removes the third clause regarding author/contributor promotion.
snags
GNU licenses
software licenses you need to There are two versions of the GNU General Public License (GPL). The terms of the latest
iteration, GPL version 3, are clear and readable overall; it allows open copy, redistribution and
know modification. Developers who use open source code covered by GPL version 3 can choose to
• Recent open source flaw charge a fee for their open source software.
highlights danger of social However, the GPL imposes several important restrictions on developers and users. The GPL
emphasizes copyleft behaviors for activities such as including linking, distribution, modification
engineering hacks and re- or sub-licensing. Generally, copyleft clauses require that uses of the work observe the
same terms and conditions to which the original code adheres. Thus, open source software
obtained under GPL version 3 retains those rights indefinitely. In addition, developers must
include a copy of the GNU GPL with the software as it's redistributed and within the software
itself. Other restrictions exist for source and binary software distributions under the GPL.
Page 21 of 28
The GNU Lesser General Public License (LGPL) provides a slightly more permissive option
In this e-guide than version 3. The agreement, for instance, allows linking the LGPL code with code under
non-GPL licenses -- a practice prohibited under GPL version 3. Consequently, developers
• Secure open source often use LGPL when they want to allow for the use of non-GPL open source libraries, but
components to bypass preserve other copyleft restrictions.
breaches
MIT License
The MIT License is one of the most brief and straightforward of any open source software
code in proprietary software license. This license grants broad permission for anyone to use the software without
restriction; the developer can use, copy, modify, distribute, re-license and even sell the
software.
The only restriction with the MIT License is that the copyright notice, permission notice and
snags disclaimer must accompany all copies or partial copies of the software.
Mozilla Public License 2.0
know The Mozilla Public License (MPL), version 2.0, is generally deemed a weak copyleft license.
This open source license is somewhat more permissive than GPL in terms of linking MPL
• Recent open source flaw code with code under other licenses, yet it still enforces some key copyleft terms. For
example, developers must release any source code that results from the project under MPL,
but they can combine MPL and proprietary code, as long as the former is kept distinct. The
engineering hacks development team can release binary files under a different license, but source code must
adhere to MPL. MPL is generally regarded as compatible with GNU LPGL and GPL.
Page 22 of 28
Developers can use, modify and distribute the software and protect it with a warranty, and
In this e-guide they can even use the software in a patent. However, they must include a copyright notice,
license copy and source disclosure -- where the source code came from.
▼
breaches
Next Article

snags

know

engineering hacks
Page 23 of 28
In this e-guide Recent open source flaw highlights
danger of social engineering hacks
George Lawton, Contributor
breaches
When a compromised NPM package with malicious code targeted a popular bitcoin wallet,
• 5 factors for using open source hackers managed to corrupt one of the JavaScript modules, called event-stream, used as part
code in proprietary software of the Copay bitcoin wallet application. The hackers would have been able to drain bitcoin
wallets, although there is no evidence it was activated before it was discovered.
This is a novel new approach to take advantage of software developer burnout. These social
license terms to avoid legal engineering hacks target the software packages developers use to craft JavaScript
snags applications. The now-common way to build modern apps -- hundreds of individual software
libraries, packages or modules -- is a security vulnerability.
This is particularly significant for enterprises that develop client and server apps on top of
software licenses you need to JavaScript that use the NPM package manager to automatically pull in updates.
know Organizations should also consider the kinds of practices that vet the security of Java and C#
libraries.
We often build modern applications by extending and configuring software modules from code
highlights danger of social repositories, package managers or GitHub. This saves developers time, but it also expands
engineering hacks the software attack surface and particularly opens the door to social engineering hacks.
Social engineering is a new software attack surface
Page 24 of 28
In the Copay case, the hacker was able to take over maintainership of a popular module in
In this e-guide the NPM ecosystem. Doing so established a bit of a history, giving the hacker the look of a
real maintainer. Then, the module's actual maintainer handed over maintenance of this
• Secure open source package and later explained he did so because he wasn't compensated for maintaining the
components to bypass module and hadn't used it in years.
breaches This illustrates one of the weaknesses of building applications on top of code written and
maintained down the open source ecosystem.
"It's basically software developer burnout as a software attack surface," said Adam Baldwin,
head of security at NPM. "If someone doesn't have the time to maintain a module, how do you
• Discern these open source expect them to invest time to vet a particular person who wants to take over its
maintainership?"
snags Security experts first saw efforts to inject malicious components into the software supply chain
in 2017. This was the first time hackers used social engineering as an attack to take over a
• 5 common open source project. Previous injections came from either typosquats or (allegedly) stolen credentials,
according to Brian Fox, CTO at Sonatype, a secure software supply chain tool vendor.
know Interestingly, the malicious payload was removed just three days after the initial publication.
This may have been to cover the hacker's tracks after the payload had been successfully
• Recent open source flaw adopted into the Copay application.
highlights danger of social "All of these facts just continue to reinforce that we aren't dealing with people seeking to
engineering hacks exploit latent vulnerabilities," Fox said. "Hackers are now moving beyond introducing new
[vulnerability] and then opportunistically exploiting victims. [They're] selecting a specific victim
and backtracking how to exploit them via the supply chain."
Open source code is vulnerable

Page 25 of 28
NPM tooling has helped repurpose JavaScript for server applications. It's made it easy to mix
In this e-guide and match the best components for a particular task. While this greatly speeds app
development, it also makes JavaScript a popular target for hackers.
There are other factors, aside from its popularity, that make the JavaScript ecosystem more
vulnerable to targeted attacks. For starters, NPM will pull down the latest libraries from the
breaches repository by default, Fox said. This means successful injection to the repository has
immediate propagation to the consumers of those libraries. In contrast, Apache Maven
• 5 factors for using open source emphasizes basic configuration management principles of build reproducibility and won't pull
code in proprietary software the latest versions unless you explicitly request them.
• Discern these open source Secondly, hackers often can't tell what dependencies are used behind a service written in
Java and C#. Many JavaScript application modules, however, are delivered to the browsers,
and this visibility lets hackers identify vulnerable packages. Hackers can directly observe how
snags this code is constructed and what dependencies it uses.
• 5 common open source A third aspect, Fox asserted, is that less-tenured developers publish components in newer
ecosystems, such as NPM. This especially stands out compared with BSD or Apache
HTTPD. These developers are less likely to adopt secure coding practices, such as vetting
know libraries and choosing a strong password.
• Recent open source flaw NPM does have built-in protections

The NPM ecosystem does have some mechanisms that help limit the impact of attacks. Once
engineering hacks
a vulnerability has been identified, NPM places the suspect code in its vulnerability database.
Once code has been flagged as insecure, NPM will alert developers who try to install it. NPM
will then prompt them to install a safer version.
Page 26 of 28
In addition, NPM has automated detection tools.
In this e-guide Although NPM continues to invest in more You are responsible for
automated detection and analysis, it missed the the libraries you require,
• Secure open source Copay attack.
so you want to have
"Without manual auditing, I don't believe anyone processes in place to vet
breaches would have found it," Baldwin said. A September
your code.
2018 NPM audit identified known vulnerabilities in
• 5 factors for using open source about 51% of the packages that developers were Head of security, NPM
code in proprietary software attempting to pull down.

Adam Baldwin
Best practices to secure
open source code
snags
Unfortunately, there is no magic bullet to ward off social engineering hacks. Even when
• 5 common open source enterprises cover all the security holes in their systems, hackers are always discovering new
software licenses you need to vulnerabilities on even some of the most highly vetted software packages. But enterprises can
take steps to minimize the use and impact of malicious packages.
know
One thing developers can do is use code more judiciously. "You are responsible for the
• Recent open source flaw libraries you require, so you want to have processes in place to vet your code," Baldwin said.
For example, NPM's enterprise product helps control the packages that developers install and
engineering hacks audits the software supply chain for unsafe dependencies. A command called NPM-audit
was introduced in 2018 to automate vulnerability warnings.
Enterprises need to assume attacks will happen and prepare for a response. They need a
definitive list of components they use and in which applications.
Page 27 of 28
"If you can't immediately answer two simple questions: 'Are we affected by this?' and, if yes,
In this e-guide 'Where?' then you have little chance to be able to quickly protect your applications," Fox said.
"Unfortunately, many organizations are still unable to achieve this basic level of supply chain
• Secure open source hygiene."
breaches
▼ Next Article
Secure open source components to bypass breaches
5 factors for using open source code in proprietary software
Discern these open source license terms to avoid legal snags
5 common open source software licenses you need to know
snags
Recent open source flaw highlights danger of social engineering hacks
know

engineering hacks
Page 28 of 28

Open Source Compliance Guide

Uploaded by

Copyright:

Available Formats

Open Source Compliance Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Open Source Compliance Guide

Uploaded by

Copyright:

Available Formats

Open Source

• Recent open source flaw

• Recent open source flaw Don't get burned

• Secure open source

• 5 factors for using open source

• Discern these open source Mik Kersten

Vulnerabilities aren't unique to open source

highlights danger of social

• Secure open source

• 5 factors for using open source

• Recent open source flaw

• Discern these open source

• 5 common open source

• Recent open source flaw

• Recent open source flaw Advantages of open source software

• Discern these open source 4. Business priorities

5. Open source software security

• Discern these open source

• 5 common open source ▼ Next Article

• Recent open source flaw

• Discern these open source

• 5 common open source

• Recent open source flaw

Social engineering is a new software attack surface

Open source code is vulnerable

• Recent open source flaw NPM does have built-in protections

• Discern these open source

• Recent open source flaw

You might also like