Here are highlights of the event so far: 

AWS open sources Cedar policy language and SDK  

The Cedar language enables you to set permissions in your applications using easy-to-understand policies. By making use of Cedar, application teams can decouple access control from application logic. 

It supports role-based access control and attribute-based access control, and was developed using verification-guided development, which ensures Cedar is correct and secure. 

The language’s SDKs are also being made available, which include libraries for creating and evaluating policies. 

AWS hopes that by open sourcing the language, they can foster more innovation in the industry around fine-grained access management and make access control more accessible to all. 

AWS also announces new open-source fuzzing framework

According to AWS, current fuzzing practices require large codebases to be refactored in order to work properly. The new framework, Snapchange, allows targets to undergo fuzz testing with minimal modifications.

Built in Rust, Snapchange enables developers to build fuzzers that replay snapshots of physical memory in a KVM virtual machine.

SPDX Release Candidate 3.0 now available

Software Package Data Exchange (SPDX) is an open source standard for communicating the information in a bill of materials. It is currently hosted by the Linux Foundation. 

In RC 3.0, there are now six unique profiles that are designed for popular use cases, with the goal being that SPDX better meets the needs of the industry. The profiles were created based on community input and include specifications for security, licensing, AI, datasets, and software packaging build processes. 

According to the Linux Foundation, the United States’ executive order on cybersecurity and Europe’s Cyber Resiliency Act served as inspiration for the need to have an international standard for supply chain security, which SPDX hopes to be. 

OpenSSF gets major funding from Google and Microsoft, new members

Through its Alpha-Omega Project, OpenSSF has recently received $2.5 million from Google and $2.5 million from Microsoft. 

OpenSSF also announced that Hitachi, Lockheed Martin, Salesforce, and SAP have become general members.

The foundation also announced that Omkhar Arasaratnam will be its new general manager and Brian Behlendorf will be chief technology officer. 

Meta joins the OpenJS Foundation

The OpenJS Foundation provides support for the open source JavaScript community. With Meta joining the foundation as a Gold Member, they will be able to contribute and advocate in the community further.

Meta had already been highly involved with the open source JavaScript community, through its projects React, Jest, and Flow. Jest is an open source testing framework, which Meta contributed to the OpenJS Foundation last year. 

“The broader JavaScript ecosystem benefits from Meta becoming an OpenJS Foundation member. In fact, we’ve already been working together in multiple different ways, and this makes official what has already been a great relationship,” said Shayne Boyer, OpenJS Foundation Board Director. “

The post Open Source Summit: AWS open sources Cedar, SPDX Release Candidate 3.0, and OpenSSF updates appeared first on SD Times.

If not properly implemented or managed, open source software can introduce security vulnerabilities, compliance issues, copyright infringement and even create bad publicity for companies.

“Even though companies’ technology depends heavily on open source, most organizations aren’t properly tracking it. They’re not properly monitoring their use of the open source and the third-party components,” Michael Lelchuk, manager of professional services at Flexera, said in a webinar. “It’s almost impossible to mitigate that risk…without knowing what’s in your code.”

Because of this, Lelchuk explained open source software license compliance is more important than ever. In order to properly comply and create trust in the software supply chain, Lelchuk along with Mark Gisi, director of the open source program office at Wind River Systems, provided a number of recommendations on what to do and where to get started.

Education:
First and foremost, there needs to be an understanding about open source in general and the open source software used within a company, Lelchuk explained. Businesses need to educate employees as well as put processes and tools in place. 

Open Source Bill of Materials (BOM):
Secondly, companies need to produce an open source Bill of Materials, which is a disclosure list and assessment of what is in the code, the components it depends on, and how it is being used and distributed. “It’s really an assessment of risk,” Lelchuk said. “Producing a comprehensive Bill of Materials is perhaps one of the most important actions for development teams to take.” It allows businesses to understand exactly what is in the code and what is going on within that code and enables engineering teams to see issues, roll out patches and bug fixes in a timely manner as well as provide a good assessment of security vulnerabilities.   

However, according to Wind River’s Gisi, there is no standard format for the BOM, but he does believe there will be a standard published in the near future to make it easier to create and consume BOMs. 

Software Package Data Exchange (SPDX):
In order to create an open source BOM, there are a couple of pieces of technologies that can help. The Software Package Data Exchange was introduced in 2010 and it is a Linux Foundation open standard for properly communicating software BOM information such as components, licenses, copyrights and security references. “It is really about getting a very detailed analysis of all the licensing in a particular software package at the file level,” said Gisi. “It is an open source project where many people can come in who have a lot of experience with compliance and sharing compliance information to develop a specification for how you might structure data.”

OpenChain: 
OpenChain is more of a certification for open source licensing in the supply chain. “Think of it as a compliance program and you want to certify your compliance program meets some basic minimum requirements,” said Gisi. According to Gisi, there are six pillars of the OpenChain specification: 

1. Policy
2. Training to ensure everyone is aware of the policy and different processes
3. Roles & responsibilities for instance there will be developers and others assigned to do things like prepare the compliance artifacts, and legal counsel to make sure everything is correct 
4. Identity, review, clear and track: gathering up all the components, understanding the software being shipped, and maintaining the software over time for every single release
5. Preparation of compliance artifacts
6. Community engagement

“Code can come from anywhere, and it also consists of a variety of different flavors. There is the source code, the binaries, the dependencies, cut-and-paste code and so forth. Because of all this and because of the fact that code comes from various entry points, people don’t really know what code they have in the codebase,” said Flexera’s Lelchuk. “What you don’t know, can hurt you from our experience.”

Learn more:
Managing Open Source Code:  Create Trust in the Software Supply Chain
Creating and maintaining trust with open source software

Content provided by SD Times and Flexera

The post 2020 Software Supply Chain Must-Knows appeared first on SD Times.

“As Linux and open source have become the primary building blocks for creating today’s most innovative technologies, projects like FOSSology are more relevant than ever,” said Jim Zemlin, executive director at the Linux Foundation. “FOSSology’s proven track record for improving efficiency in license compliance is the perfect complement to a suite of open compliance initiatives hosted at the Linux Foundation. This work is among the most important work that we all do.”

(Related Content: Navigating through an open-source world)

FOSSology joins the Linux’s other open compliance efforts such as OpenChain and the Software Package Data Exchange (SPDX). With FOSSology, users can run license and copyright scans, and can also generate an SPDX file.

“FOSSology is a mature compliance project which has benefited from a vibrant community of users and contributor,” said Eileen Evans, vice president and deputy general counsel of software, cloud and open source at HP. “We believe that the Linux Foundation’s hosting of the project will enable it to be further utilized across the industry and help increase the adoption of Linux and other open-source software.”

FOSSology 3.0 is expected to be released later this week.

The post Linux Foundation takes on the FOSSology project appeared first on SD Times.

“There are hundreds and thousands of products and services that we all depend on every day that contain a vast amount of open-source software,” he said. “Whether it is every single Android device out there, whether it is an Apple iPhone, a Windows product, you name it, there are lots of open-source software in there.”

It is no longer a matter of whether an organization should take advantage of open-source software; it’s also a matter of understanding, handling and managing all the open-source software coming in.

“Just because open source is easy to grab off the Internet and it is so easy to integrate into your product, it is no excuse for not making sure it is secure,” said Dave McLoughlin, director of open-source auditing at Rogue Wave Software.

What to consider
Open source has become more popular over the past few years because of its ability to get organizations to market faster. According to Mahshad Koohgoli, CEO of Protecode, it is hard to survive in today’s software development world without the use of open source.

“Each software would not be possible without open source, without code reuse,” he said. “No organization can possibly create these highly functional, complex software on their own. Open source is the only way.”

But just because people use the term free and open source doesn’t necessarily mean that the software is free. “The ‘free’ in ‘free and open-source software’ refers to the free software movement, from which open source has sprung,” said the Open Source Initiative’s (OSI) board of directors. “ ‘Free’ here means ‘freedom,’ not price. Think of it as ‘the freedom to…’ or ‘liberty.’ ”

(Related: Why open-source software will eat the world)

The freedoms of free and open-source software include the ability to run the program; the ability to read, study and modify the code; the ability to make and redistribute copies; and the ability to distribute copies of modified versions, according to the OSI.

But the freedoms and benefits that open source enables, such as a lower total cost of ownership, higher quality and faster innovation, can also pose a risk to your company.

“Open source can be a veritable candy store of resources for developers, and also provide time and resource-saving shortcuts for organizations integrating and developing code. But it’s not a panacea,” said Bill Weinberg, senior director of open-source strategy at Black Duck.

For instance, if an organization doesn’t comply with the license associated with a particular chunk of open-source code, it risks being sued. If it doesn’t check the code it is using, it could potentially damage its services and systems. And if the organization doesn’t don’t know where the code came from in the first place, then it may not be aware of any incompatibility issues or any obligations that the license requires.

These risks can cause organizations to shy away from using open-source software, but if they know what they are dealing with, open-source doesn’t have to be an intimidating space. According Rogue Wave’s McLoughlin, there are three areas that organizations sometime forget to consider: compliance, security and support.

Open-source software comes with licenses that users are expected to comply with. If an organization doesn’t comply, then it can open itself up to legal liability, according to McLoughlin. Also, there are certain types of licenses that may back users into a corner, such as the GNU license that in some instances requires users to release their modified work under it and provide the source code.

But the point of a license isn’t necessarily to threaten an organization into compliance, according to Black Duck’s Weinberg. Open-source licenses are meant to protect someone’s unique property rights, and also guarantee the free and unencumbered distribution of the source code. “The originators of free and open-source software were trying to ensure that their works would be available to other users and communities and downstream inheritors without the code being sucked up by a proprietary interest and never being made available,” he said.

Proprietary licenses, for example, can limit a user’s permission to use the software, and they can sometimes contractually take away the rights users would have under copyright law, according to the OSI’s board of directors.

As the open-source community saw with major events like Heartbleed, open-source code can open your software to security vulnerabilities. Being aware of the security aspects are essential, and organizations need to be aware of any known security issues, according to McLoughlin. “Hopefully you are doing some type of static code analysis, some type of analysis of your code so that you understand if it opens you up to any security vulnerabilities, and then you have to track that code on an ongoing basis as new vulnerabilities are found in the future,” he said.

And then there is the question of support. Normally when you purchase a commercial product, the organization you buy it from provides some level of support, or you can purchase a support contract, according to McLoughlin. With open source, the question is where that support will come from. Organizations need to look at open-source code and understand whether or not they are going to be responsible for managing, fixing and supporting it internally; if they should outsource support to a third-party; or if the author of the code will be updating the code.

Open-source policies
Developers who scour the Internet looking for open-source software shouldn’t have to consider things like security, support and compliance every time they want to look for a piece of code. Organizations should have open-source policies in place that answer those questions.

“An open-source policy captures the considerations around adoption of open-source software (OSS) in an organization. The policy ensures that the benefits of OSS are maximized, while OSS adoption risks at legal, operational and business levels are managed,” said Protecode’s Koohgoli.

Each open-source policy should be tailored to an organization’s culture and objectives, but there are some key factors they should consider incorporating.

“The key is not to approach compliance with the aim of ‘What can I get away with,’ but rather ‘How can I meet the expectations of the developers who gave me this software,’ ” said the OSI board of directors.

According to Black Duck’s Weinberg, open-source policies should include what licenses are permitted or blacklisted, the context of how a license is used (for instance GPL is okay for Linux kernel code, but not applications), who is going to take ownership of particular OSS components, and under which licenses will the company publish its own open-source code.

In addition, Rogue Wave’s McLoughlin said that policies should talk about how the organization is going to acquire open-source software, how the code is going to be tracked, how the organization is going to support open-source software and the community, and how the open-source software is going to be checked for compliance.

After building a policy, organizations also need to figure out how they are going to enforce it. According to Koohgoli, an open-source review board is often put in place who is responsible for getting input from the software life-cycle teams, making sure software satisfies the license requirements before it is released, and educating their developers on the policies.

Linux’s self-assessment open-source compliance checklist
Linux’s Zemlin recommended organizations take a self-assessment checklist to understand whether or not they are in compliance. “We recommend that there be a set of processes for reviewing the code you’re using, making sure you understand what all of it is and what requirements for each of the different components are, and then being able to make the process of complying very simple,” he said.

According to Linux, the checklist should include:

• Discover and disclosure: identifying open-source licenses
• Review and approval: evaluating how the open-source software will be used and distributed
• Obligation satisfaction: complying to the open-source license requirements
• Community contributions: how the organization is going to review and approval contributions internally and externally
• Policy: encouraging the use of open-source software and protecting business needs
• Adequate compliance staffing: having the appropriate skills and resources necessary to comply
• Adaption of business processes: how open-source compliance is going to fit into other business practices
• Training: the company has been trained and understands how to comply
• Compliance-process management: establishing, maintaining and enhancing an open-source compliance policy
• OSS inventory/recordkeeping: tracking open-source content and compliance
• Automation/tool support: how tools are going to help the organization comply
• Verification: assuring that the company and employees are able to adequately meet OSS requirements
• Process adherence audits: determining if the organization is on the right track with its compliance program.

According to Zemlin, it really isn’t any harder to comply with open-source licenses than it is to comply with a proprietary license. “We think with just a little bit of training, organizations will be confident to use open-source software and will get the benefit of billions of dollars worth of software and innovation that comes with it,” he said.

But according to Black Duck’s Weinberg, compliance would be easy if it was just one piece of code and one license. “We know organizations that are using thousands upon thousands of open-source software components, and in that case compliance and governance can be quite complex,” he said.

Weinberg added that the terms found in licenses can be confusing, and even if an organization thinks it understands the terms, its lawyers might have a different opinion or disposition, so compliance shouldn’t be left to any one part of the company. He recommended organizations adopt a cross-disciplinary purview and an open-source licensing board made up of engineering management, legal management and upper management.

Types of open-source licenses
There are thousands and thousands of open-source licenses. The Open Source Initiative recognizes approximately 60 of them, but that leaves about 2,000 self-styled and completely original open-source licenses, according to Black Duck’s Weinberg.

These licenses can fall into two basic categories: permissive and restrictive.

Permissive licenses are ones that require minimal obligations from a company, such as attribution requirements, according to Protecode’s Koohgoli. “For instance, all you have to do is make sure your product that uses the open-source code is shipped with a notice that says [the] product uses this open-source software,” he said. “The attribution comes in different forms, and they have to maintain the code or include the original lines of attribution on the top their software.”

Then there are restrictive licenses, typically called “copyleft” licenses, which generally allow you to use software for any purpose (but with various types of restrictiveness). The idea of restrictive licenses is to put a set of terms that restrict how the open-source code is distributed so that users can’t put it under any set of terms they want, according to Rogue Wave’s McLoughlin. “Some licenses very specifically say you can use this code, it is free, you can modify it, you can use it any way you want, you can put it in a commercial product, etc. But you can’t change the license, and any work that you create with this product, diverted work, any modifications that you made to it, have to be under this original license,” he said. The idea is to keep open-source software open source so that it isn’t closed-sourced by a commercial vendor in the future, he explained.

The most common licenses include the GNU General Public License, MIT License, and Apache License.

Some of the less common (but more interesting) licenses include Beerware—which allows a user to use the software how they like, but if they ever come across the author they are recommended to buy them a beer; Do What the F*** you want Public License (WTFPL)—which means basically what it says; and the VoidSpace license—which states the author is not responsible for damages that may occur.

The Software Package Data Exchange
The Linux Foundation created the Software Package Data Exchange (SPDX) specification to provide a bill of materials about license information and components included in open-source code.

“Our philosophy here is we want to make the sharing of software not only in the development process, but in the consumption and redistribution of that software as simple and plain as possible,” said Linux’s Zemlin.

The SPDX was designed to provide organizations a way to see how open-source software relates to other open-source code, what versions of software were used in open-source code, the license and version of that license the software belongs to, and if there are any vulnerabilities that need to be addressed. Zemlin said the specification is still in a mid-adoption phase, but as more open-source software is used throughout almost every aspect of IT, it will become the standard way for sharing open-source data.

“SPDX has great potential to act as a common interchange format for licensing information on open-source software,” said the OSI board of directors. “It is still a work in progress, with the latest version of the specification just released [in May].”

The SPDX specification process operates similar to an open-source community. Developers, distributors and providers can contribute SPDX files for their open-source projects.

Tools to help you comply
When given a choice to code or worry about compliance, developers will choose to code, according to Black Duck’s Weinberg. Having to manually ensure compliance can be a daunting task and potentially take several hours every week. Tools can help automate the process of compliance, but it’s important to keep in mind that they can’t guarantee compliance.

“Tools themselves cannot ensure compliance, but they can aid organizations in understanding how they are using open source (and other software), and what the organizations need to do to remain in compliance with open-source licenses,” said the OSI board of directors.

A good set of scanning tools is important to help organizations understand exactly how much open-source code they are using in their product and if the code contains any licenses that are incompatible with one another. “If you have an organization that 100% tracks everything that comes into their organization, they still miss open source and open-source licenses because fundamentally open source uses open source,” said Rogue Wave’s McLoughlin.

Scanning tools can also help users understand what version the code is at and what license is enforced for that code so that they can tie it into their policies and products for compliance, according to Weinberg.

Then, you need some way to track the open-source code, according to McLoughlin. Tools can provide inventory tracking of open source to manage the approval process. “If you are letting your developers just bring open source into your products, and you are not tracking them, then you are not putting a process in place that lets you know if there are known vulnerabilities that could affect you from the beginning,” he said.

In addition, static code analysis tools can help find bugs and ensure code quality.

Lastly, the Linux Foundation recommends a linguistic review tool that can look for any comments about the source code or future products.

“Even if you are not that concerned about your own code, you should be concerned about any code that you acquire,” said McLoughlin. “There is practically no software company that’s acquired technology that doesn’t want to know and have a comprehensive list of open source and licenses in the technology that they are acquiring.”

A breakdown of the typical software portfolio
Protecode recently released an infographic highlighting the importance of understanding the open-source content in a code portfolio. According to Koohgoli, many organizations worry about accidentally including copyleft licenses in their code—for instance the GNU Public License (GPL).

“Inclusion of GPL code in a company portfolio can force the company to open their entire codebase to the public, which could be commercially undesirable,” he said.

According to the infographic, which was made up of consolidated findings from an audit of more than a million software files belonging to more than a hundred technology companies, GPL code exists in almost all the portfolios.

The infographic also stressed the importance of providing header information in proprietary files, which a majority of small portfolios don’t include.

“Many organizations do not include their own copyright information on their software, making the task of determining [their] own IP against third-party and OSS content more difficult,” Koohgoli said.

In addition, Protecode found that open-source software containing security vulnerabilities were found in most portfolios.

The post Navigating through an open-source world appeared first on SD Times.

“When creating products from open-source code, it is important to respect the terms of the license in the code, if you’re going to use the code,” said Jack Manbeck, co-chair of the SPDX business team.

“Determining the licensing of something can be a complex process, and determining the complete set of licenses for an application is often done multiple times, by different people for the same item. This leads to a lot of wasted time and effort. By having a specification and the SPDX license list, you now have a way to communicate that information in a common format, versus everyone wanting it differently, thus avoiding redundancy.”

(Related: Skills you can use for Linux)

SPDX was first announced in 2011, and since then the workgroup has been working on improving the specification to simplify compliance. Version 2.0 was a major milestone for open-source license compliance, according to the workgroup. It features the ability to relate SPDX documents to each other in order to understand what open-source software was used to build components, what versions of the software are being used, and if there are any vulnerabilities that need to be addressed.

“SPDX is about reducing the cost of and facilitating license compliance,” said Manbeck. “When you have complete licensing information, you can make sure everyone’s license choices are taken into consideration.”

Other features of SPDX 2.0 include:

• Descriptions of multiple packages in a single SPDX document
• An expansion of annotations to increase flexibility
• A new license expression syntax to make it easier and more reliable to capture licensing in a file
• Support for additional file types and checksum algorithms
• The ability to now reference software pulled from version-control systems.

“License compliance is a priority for the Linux and open-source community, and benefits the technology industry overall, especially as the adoption of open technologies continues to increase,” said Jim Zemlin, executive director of the Linux Foundation. “With the release of SPDX 2.0, compliance is easier than ever before.”

More information is available here.

The post SPDX version 2.0 is released appeared first on SD Times.

SPDX is an industry standard for communicating the open source components, licenses and copyrights associated with a software package. SPDX provides a uniform approach to documenting and sharing metadata about software packages, making it more efficient for supply chain partners to communicate. The standard’s top objective is to help companies more easily comply with software licensing obligations.

Black Duck, which has the largest customer base in the open source code and license management industry, will generate SPDX output as part of the reporting capability of the Black Duck Suite. There will be no additional cost for Black Duck’s rapidly expanding base of 1,000 customers located in 24 countries.

“As a Black Duck customer and an active supporter of the SPDX standard, Texas Instruments is pleased that Protex now supports SPDX,” said Jack Manbeck, manager, Open Source Review Board, TI Texas Instruments. “Having such tools will help the community propagate the use of SPDX and enhance supply chain efficiency.”

Black Duck co-chairs the Linux Foundation’s SPDX Working Group that brings together representatives from open source projects, vendors, and corporate users across the industry and around the globe; the Black Duck technology team actively contributes to the standard.

“Black Duck is proud to be instrumental in developing the SPDX standard, which we are confident will benefit the entire open source community,” said Phil Odence, vice president, business development, Black Duck Software, and co-chair of the SPDX Working Group. “Making it easier to communicate open source obligations will not only enable greater compliance, but will also increase the efficiency of supply chains. We’re happy to encourage this by offering SPDX output to our users at no additional cost.”

To learn more about Black Duck’s involvement and to review a whitepaper and short presentation explaining the SPDX standard, visit: http://www.blackducksoftware.com/spdx.

For more information on the SPDX Working Group and the SPDX standard, visit: http://spdx.org.

The post Black Duck Software Announces Support for SPDX Version 1.0 appeared first on SD Times.