[META] Increase Security of Project Ownership Transfer Process

I am one of the people who oversees the Project Ownership Process (including the adoption of abandoned projects).

In the linked Slack conversation, there are a few references to various unfortunate incidents that is not very well documented and that I personally am not familiar with. My initial response is that this is hearsay and if the intent is to raise the concern about the security of the existing process and its flaws, alleged transgressions need to be better documented.

I am not saying that the current process is perfect and cannot be improved, I am just saying that the problems need to be more clearly documented in order for real progress to improve it be made.

In the issue summary, it is stated that:

the Drupal.org Project Adoption process poses a supply chain risk to the Drupal Ecosystem

That is a serious allegation. However, it is also stated up front in the Slack conversation:

None of these (to my knowledge) have yet resulted in a successfully targeted attack against site owners,

but adding that:

however I worry it could just be a matter of time till this does occur.

However, I think it need to be recognized that in a Free Software ecosystem, there is always a potential for a supply chain attack, and this potential exists whether there is in place some process for transfer of ownership of abandoned projects or not.

A threat agent wanting to perpetrate a supply chain attack against a Free Software ecosystem does not need to adopt and existing component (abandoned or not). Creating a brand new one and getting it hosted as part of the ecosystem will do equally well. I recall this issue about an actor that were suspected of doing this: #3112796: Mark Elfsight modules unsupported → (the malicious part was that PID was collected without diclosure or concent). (We ended up tagging the affected projects as "Unsupported" and pulling the releases.)

If we simply discontinue the Project Ownership Process, the problem is not going to go away. Without the process, these projects will just become adandoned projects, and their users will be looking for a replacement. However, since this is free software, a threat agent could just fork any abandoned code base, inject whatever malware they saw fit, and advertise the fork as a plug-in-replacement for the abandoned component, and perpetrate a supply chain attack against the part of community in need of said component.

The principal safeguard against supply-chain attacks is peer-review, and that goes for abandoned projects resurrected under new ownership, and for new and forked projects that is not subject to any process before being introduced to our ecosystem. However, as demonstrated by Ken Thompson in his famous Turing Award lecture: Reflections on Trusting Trust, this may not always be enough.

In the issue summary "Proposed solution" is left blank (so far). I shall review anything proposed in a timely manner, but IMHO, the problem of "supply chain attacks" is not in any way tied to our existing formal process for allowing abandoned projects to be adopted, but intrinsic to the nature of free software ecosystems, and to focus narrowly on the Project Ownership Process in order to solve this is just going to miss the mark.

In the issue summary "Proposed solution" is left blank (so far). I shall review anything proposed in a timely manner,

This is a META, proposed solutions are linked as child issues and are still (slowly) being added to from the suggestions in Slack. Not all are expected to be accepted however they have been posted for formal evaluation in attempt to incrementally increase the security of the ecosystem.

I am just saying that the problems need to be more clearly documented in order for real progress to improve it be made.

My goal was to talk more about vectors rather than name specific incidents, however I can dig through my notes to pull out the incidents that cause me wish to see improvements if that is what is desired. I will counter that if we focus only on the known incidents we can miss the equally obvious avenues that have not yet been taken advantage of.

As you said, there will always be risk, we can’t completely eliminate it, we can however attempt to mitigate what we can foresee.

does not need to adopt and existing component (abandoned or not). Creating a brand new one and getting it hosted as part of the ecosystem will do equally well

That probably is best discussed in ✨ Prohibit the ability to adopt a project Active however as a short response, there is a significant difference between being able to publish to an established user base and forcing an attacker to create a new namespace with the effort of cultivating a new following. We do still have the typo risk style attacks though that would probably fall outside the intended scope of this meta.

The principal safeguard against supply-chain attacks is peer-review, and that goes for abandoned projects resurrected under new ownership, and for new and forked projects…

Currently there is little to no tooling for site owners to know that the Project Ownership team other than following every thread in a support forum. Drupal Auto Updates will likely make this worse as it is being promoted as a “set it up and your site is always up to date” encouraging site owners to update without review (there was one thread in Slack about possible mitigations for this that I will create the follow-up issue for later today). I would contend AutoUpdates puts more onus on the backend adoption side to have tighter gates.

and to focus narrowly on the Project Ownership Process in order to solve this is just going to miss the mark.

It has been my experience D.O. historically wants targeted incremental improvements, this issue is in line with that mindset, it’s goal is not to fix every problem instead attempting to mitigate possible exploit paths to reduce the overall risks.

To understand the nature of supply chain attacks it may be relevant to look at this white paper about a recent successful supply chain attack that took place in the WordPress ecosystem: Supply Chain Attacks: A WordPress Case Study. For the record: No project ownership transfer was involved in the attack.

TL;DR: What happened was that AccessPress, a trusted supplier of WordPress plugins had their website compromised by the threat agent, and an obfuscated trojan was injected in the code distributed by this trusted supplier.

Other well-known supply chain attacks, such the SolarWinds and Colonial Pipeline, also did not involve any project ownership transfer, but involved the same MO as the attack on AccessPress: An already trusted supplier of software components to the targeted ecosystem is hacked and is then abused as vector to inject malware into the ecosystem.

My take on this is that the problem highlighted in this meta issue is of a theoretical nature, and does not reflect how actual supply chain attacks are conducted in the real world. To protect the community against supply chain attacks we need instead to focus on the MOs that matches how this type of attacks is typically orchestrated.

@gisle: please do not take this meta or any of the child issues as a personal attack or condemnation of the work you and others have been doing with the project adoption system. Y’all do a ton of mostly thankless but extremely important work, and I’m incredibly glad you do.

I believe this was opened as an honest and sincere attempt at “defense in depth”, and mitigating whatever vectors we can dream up before they are exploited and real harm is done.

I don’t believe it is wise to only focus on what has been done (and how) from previous exploits. Malice can come in many forms. People who set their eyes on Drupal will find ways to exploit our community and processes, not necessarily replicate other attacks on other “supply chains”.

I personally oppose some (many?) of the proposed solutions in child issues. 😂 But I’m grateful for the discussions, and think there will be some agreeable and actionable changes that come out of it.

We’re all interested in the same things: preventing exploits and keeping our community and its user base safe. Let’s keep an open mind, brainstorm freely, and assume good faith and goodwill.

P.s. I’m all in favor of other meta issues to track other aspects of supply chain security that don’t directly involve the project adoption process. I tend to agree that there are plenty of possible threats that don’t require project adoption. No one should assume this is the only set of vectors worthy of exploration and mitigation. But we need small scope if we ever want to get anything done.😅

For the record: I don't perceive this meta, or any of its child issues as something that applies to me personally in any way. I just happen to dislike some of the mitigations that has been proposed so far (for reasons that I have provided here and in some of the child issues). However, I fully agree that this was opened as a honest and sincere attempt to bring to the attention of the community by what is believed to be a serious problem in need of fixing.

However, I take issue with this statement:

I don’t believe it is wise to only focus on what has been done (and how) from previous exploits. Malice can come in many forms. People who set their eyes on Drupal will find ways to exploit our community and processes, not necessarily replicate other attacks on other “supply chains”.

I do not think that we should only focus on other exploits. However, when the impetus of this proposal seems to be that the project adoption process is a major threat to the continued security of the Drupal ecosystem, I think it is prudent to point out:

1. Historically, project adoption has not been a vector for supply chain attacks (AFAIK zero reported incidents in the many years the adoption process has been practised).
2. Other vectors figure quite prominent in the supply chain attacks we know about in other ecosystems.

In other words: I think we need the perspective that is provided by our history other supply chain attacks to understand how serious a threat the project adoption process actually is.

And I still think the community will be better served by implementing mitigations that cover a broader range of vectors than just the project adaption process. I've already mentioned that IMHO, a more systematic review of code changes committed to a project should be more prominently featured as a method to mitigate supply chain attacks, no matter who it is that inject tainted code in the project.