In the second part of this blog series, we will talk about an important element of the open source inbound usage: the binary artifacts.
While using open source components, it is a common practice to utilize external repositories to obtain pre-packaged and pre-compiled open source components, also called binary artifacts. With the benefit of having easy access to the open source components, there are several downsides and risks while using said artifacts.
Let’s reiterate these risks from the previous article:
- External repository availability is outside of software developer control
- External repositories are a potential for the supply chain attack vectors, such as: package mis-spelling attacks, repository account takeover for the purpose of malware injection, dependency confusion attack, malicious obfuscated commits, etc.
- Uncertain specific package/code version availability for the build reproducibility purpose
There is a lot more to consider, please see a recent article on the topic, called Musings on Software Supply Chain Security by Tim Pepper, as well as Software Supply Chains and Airplanes! by Norman Scroggins.
Also make sure to check A Bootiful Podcast: Software Security in the Supply Chain by Josh Long and Joshua Lock that discusses supply chain security in detail.
On to the topic, I’ve mentioned previously the trusted source as being one of the key elements of successful open source inbounding.
So, what makes an open source binary artifact repository trustworthy? Here are some criteria that were proven to support a repository trustworthiness:
- The repository should be documented as a known and approved location: either in an external official location for the binaries, easily recognized by the user, or in a commonly used location
- Hosted binaries should have clear license artifacts to ensure compliance with the license requirements
- Hosted files should be properly version controlled, ensuring old versions are available and trackable
- It should be easy to map the hosted files name, version and release to a specific well-known source code
- Artifacts should show the signs of active maintenance, meaning regular releases in the repository
Regardless of the level of trust you assign a repository, it is very important to mirror repository to a local copy, as discussed in previous parts of this blog series, in order to have higher control over availability, security and reproducibility.
Once the binary artifact repository is mirrored locally, the general guidelines for using inbound open source software source code and binary artifacts should follow these points:
- Reuse pre-approved components, coming from approved internal repository mirrors
- The new external open source artifacts need to go through attestation and approval processes
- Make sure that the artifact repository or artifact is coming from a trusted source
- Document supporting information confirming trustworthiness of the artifact
- Document the approval request for internal review
In addition, every artifact should be scanned for security problems, vulnerabilities, license and copyright information, in order to ensure supply chain security. This is best done through an automated process, utilizing one of the available open source or commercial tools.
In the nearest future, it will be paramount to implement artifact attestation and signing to guarantee binary artifact safety. However, this work is still in progress in the industry and the implementations are yet to mature.
Overall, what we talked about today will cover the major risks around binary artifact consumption. A closer look is still required to ensure a sufficient level of safety. We will talk more about practical experience in the next part of this blog series.
