The risk of undermanaged open source software

There are plenty of myths surrounding open supply software program, however one which continues to permeate conversations is that open supply isn’t as safe as proprietary choices. At face worth, this declare would appear to carry advantage as how do you safe a provide chain for a product that’s created in an atmosphere the place anybody can contribute to it?

However perceptions are altering, as open supply code is working most of the most subtle computational workloads recognized to mankind. In truth, in accordance with Crimson Hat’s 2022 The State of Enterprise Open Source report, 89% of respondents imagine that enterprise open supply software program is as safe or safer than proprietary software program. 

Even when misplaced safety considerations linger, it doesn’t appear to be slowing down open supply adoption. Open supply powers a few of the world’s most recognizable firms that we depend on each day – from Netflix and Airbnb to Verizon and The American Crimson Cross. This utilization continues to develop, with Forrester’s State of Application Security 2021 report indicating that 99% of audited codebases include some quantity of open supply code. This wouldn’t be the case if the organizations deploying these options didn’t belief the safety of the software program used.

Counting on open supply doesn’t imply you’re opening your group as much as vulnerabilities, so long as you assessment the code for any safety considerations. Not like proprietary software program, open supply code is absolutely viewable and, thus, auditable. So the important thing for enterprise use of open supply is to be sure you’re not undermanaging it. However whereas the chance is there, the experience will not be, and the auditability that’s typically touted as a bonus of open supply will not be for each group utilizing it. Many customers shouldn’t have the time, experience or wherewithal to conduct safety audits of the open supply they use so we have to contemplate different avenues to acquire related assurances in that code. When delicate workloads are deployed, in fact, belief isn’t sufficient. “Belief however confirm” is a key mantra to remember.

There’s at all times going to be a certain quantity of threat we tackle in terms of know-how, and software program specifically. However since software program is deeply ingrained in all the things we do, not utilizing it isn’t an possibility; as an alternative, we deal with threat mitigation. Realizing the place you get your open supply from is your first line of protection. 

Relating to open supply software program, there are two main choices for organizations – curated (or downstream) and neighborhood (or upstream). Upstream in open supply refers back to the neighborhood and challenge the place contributions occur and releases are made. One instance is the Linux kernel, which serves because the upstream challenge for all Linux distributions. Distributors can take the unmodified kernel supply after which add patches, add an opinionated configuration, and construct the kernel with the choices they need to provide their customers. This then turns into a curated, downstream open supply choices or merchandise. 

Some dangers are the identical no matter whether or not options are constructed with vendor-curated or upstream software program; nonetheless it’s the duty for upkeep and safety of the code that adjustments. Let’s make some assumptions a few typical group. That group is ready to establish the place all of its open supply comes from, and 85% of that’s from a serious vendor it really works with usually. The opposite 15% consists of choices not accessible from the seller of alternative and comes immediately from upstream tasks. For the 85% that comes from a vendor, any safety considerations, safety metadata, bulletins and, most significantly, safety patches, come from that vendor. On this state of affairs, the group has one place to get the entire wanted safety data and updates. The group doesn’t have to watch the upstream code for any newly found vulnerabilities and, basically, solely wants to watch the seller and apply any patches it gives. 

However, monitoring the safety of the remaining 15% of the open supply code obtained immediately from upstream is the person group’s duty. It must continuously monitor tasks for details about newly found vulnerabilities, patches, and updates, which may eat a major quantity of effort and time. And except the group has the sources to dedicate a group of individuals to handle this, techniques might be left weak, which may have pricey impacts. On this hypothetical state of affairs, the uncurated open supply is a a lot smaller proportion of your infrastructure, however the help burden for that 15% is most undoubtedly larger than the 85% supplied by your vendor.

Whereas at first look, it could appear that the identical effort is required to use patches to upstream open supply code and patches to vendor-supported open supply code, there might be necessary variations. Most upstream tasks present fixes by updating the code in the latest model (or department) of the challenge. Due to this fact, patching a vulnerability requires updating to the latest model, which may add threat. That the majority current model might have further adjustments which can be incompatible with the group’s use of the earlier model or might embody different points that haven’t but been found just because the code is newer. 

Distributors that curate and help open supply software program typically backport vulnerability fixes to older variations (basically isolating the upstream change from a later model that fixes a selected concern and making use of it to an earlier model), offering a extra steady resolution for functions consuming that software program, whereas additionally addressing the newly found vulnerability. It has been demonstrably confirmed that backporting reduces the chance of undiscovered vulnerabilities being launched and that older software program that’s actively patched for safety points turns into safer over time. Conversely, as a result of new code is being launched in new variations of software program, the chance of latest safety points being launched is larger.

That’s to not say you shouldn’t use upstream open supply. Organizations can, and do, eat software program immediately from upstream tasks. There are numerous causes for utilizing upstream open supply in manufacturing environments, together with value financial savings and entry to the newest options. And no enterprise vendor can present the entire open supply that buyers might use. GitHub alone hosts hundreds of thousands of tasks, making it not possible for any vendor to help all of them. 

There’ll doubtless be some upstream open supply that will probably be consumed immediately, and this, together with any code written by the group, is the place the vast majority of a company’s safety group’s effort and time will probably be centered. If that quantity is sufficiently small, the price and related threat will probably be smaller as effectively. Each group will doubtless eat some open supply immediately from upstream they usually want to pay attention to that code, how and the place it’s used, and learn how to appropriately monitor upstream developments for potential safety points. Ideally, organizations will find yourself with the majority of their open supply coming from an enterprise vendor, which can decrease the general value of consumption and reduce the related threat of utilizing it. 

Securing the software program provide chain

Realizing the place your open supply originates from is step one to reducing publicity, however provide chain assaults are nonetheless rising exponentially. In line with Sonatype’s 2021 State of the Software Supply Chain report, in 2021 there was a 650% improve in software program provide chain assaults aimed toward exploiting weaknesses in upstream open supply ecosystems. Some of the publicized assaults had nothing to do with open supply code itself, however as an alternative was an assault on the integrity of an organization’s patch supply course of. And with the variety of high-profile and dear safety assaults to organizations which have been prevalent within the information over the previous few years, elevated consideration and scrutiny is (rightly) being positioned on provide chain safety.  

Totally different actions are required to forestall or mitigate several types of assaults. In all instances, the precept of “belief however confirm” is related.

Organizations can handle this partly by shifting safety left in new methods. Traditionally, shifting safety left has centered on including vulnerability evaluation to the CI/CD pipeline. This can be a good “belief however confirm” follow when utilizing each vendor-provided and upstream code. Nevertheless, vulnerability evaluation is basically not sufficient. Along with the binaries produced by the pipeline, utility deployments require further configuration information. For workloads deployed to Kubernetes platforms, configuration information could also be supplied by way of Kubernetes PodSecurityContexts, ConfigMaps, deployments, operators and/or Helm charts. Configuration information also needs to be scanned for potential threat corresponding to extra privileges, together with requests to entry host volumes and host networks.  

Moreover, organizations want to guard their provide chain from intrusion. To higher help this effort, organizations are adopting new applied sciences in software program pipelines corresponding to Tekton CD chains, which attests to the steps within the CI/CD pipeline, in addition to applied sciences like Sigstore, which makes it simpler have artifacts signed within the pipeline itself moderately than after the very fact.

Sigstore is an open supply challenge that enhances safety for software program provide chains in an open, clear, and accessible method by making cryptographic signing simpler. Digital signatures successfully freeze an object in time, indicating that in its present state it’s verified to be what it says it’s and that it hasn’t been altered in any approach. By digitally signing the artifacts that make up functions, together with the software program invoice of supplies, part manifests, configuration information, and the like, customers have insights into the chain of custody. 

Moreover, proposed requirements round delivering software program payments of fabric (SBOMs) have been round for fairly a while, however we’ve reached the purpose the place all organizations are going to wish to determine learn how to ship a software program invoice of supplies. Requirements should be set not solely round static data in SBOMs but additionally round corresponding, but separate, dynamic data corresponding to vulnerability information, the place the software program package deal hasn’t modified however the vulnerabilities related to that package deal have. 

Whereas it could appear as if safety is a continuously shifting goal, due to the extreme scrutiny round software program safety up to now a number of years, extra methods and instruments to scale back threat are being developed and carried out day by day. That mentioned, it’s necessary to keep in mind that addressing safety successfully requires that organizations usually assessment and iterate on their safety insurance policies in addition to their instrument selections, and that every one members of the group are successfully engaged and educated in these processes. 

Kirsten Newcomer is director of cloud and DevSecOps technique at Red Hat.

Vincent Danen is VP of Product Safety at Crimson Hat.