In the first post of this series, I explained that using open source is encouraged and shouldn’t be an obstacle to developing software, as long as you inbound open source responsibly and in a secure way. Next, I explained why binary artifacts are an important element of the open source inbound usage. In the third and the final part of this blog series, I’ll talk about the experience and the resulting best practices dealing with the open source inbound usage.
There are several aspects of the software release that are especially vulnerable to the incorrect open source component use.
In regards to the software quality, build reproducibility and maintainability, the software developers should be able to identify the exact source code associated with the open source components by retaining so-called “provenance information,” and be deterministic in building software by using the collected component and provenance information.
Software vulnerabilities should be tracked, announced and bound to a specific versions of the open source code used within the software release.
In regards to the correct and transparent open source licensing, the software maintainers should provide the license and copyright information for all the open source components used within the shipped software.
All this requires is an effective open source policy in any type of the software project — be it a personal project to host watched movies list, or a grand commercial orchestration project spanning dozens of teams.
At its core, an open source policy should keep in mind the following:
- Always carefully review open source components in your product and assess the license and legal implications
- When possible, mirror an external source code repository you plan to use in your product to an internal source code repository, and build from this mirrored source code
- Identify the external binary artifacts and binary artifact repositories that are required to satisfy the product dependencies, and mirror them to an internal binary artifact repository
- Link the open source binary dependencies to the local mirrors
- Always reuse the local open source code and open source binary artifact mirrors when appropriate
- Regularly perform vulnerability assessment of the used open source components
- Retain the collected component information in the form of an SBoM to reuse through all of the stages of the software development process
- Plan attestation process to validate safety and authenticity of the mirrored open source components, and have artifact storage to store the attestation data and artifacts
Avoiding a formal approach and keeping an effective open source policy is hard. See the following article on implementing a practical open source policy by Girish Managoli, appropriately named Open source policy that works in practice.
If your product requires changes to an approved open source artifact, or source code, then the following reasoning should be followed:
- When possible, contribute the changes to the upstream source code (this also reduces your technical debt), and use downstream the updated binary artifacts or source code
- If this is not possible, then:
- Mirror the source code to a local repository
- Apply the needed changes to the locally mirrored code following the source license requirements
- Use a reproducible process to build a new binary artifact for hosting in the internal binary artifact repository and use it in your software
In conclusion, please keep in mind these points regarding inbound open source component usage:
- Know what you build, and build what you know
- Have the full inventory of all the dependencies, including open source and third-party components
- Have the full vulnerabilities profile for the external dependencies and a plan for how to deal with critical vulnerabilities
- Carefully tread the fine line between keeping the software safe and getting bogged down in bureaucracy of formal approvals
That’s it – keep on writing great software and stay safe!
If you are interested other open source topics, feel free to read through these excellent articles by other Open Source team members at VMware:
- How to Get Your Code Upstream by Steven Rostedt
- How to Create Good Good-First-Issues by Nisha Kumar
- Building a Community: Company Resources by Dawn Foster
Or read through other great topics in the VMware Open Source blog: https://blogs.vmware.com/opensource
