This is an early draft of something I plan to publish for more open source projects, but I wanted to send this out here first since I'm more directly involved.
Open source projects, especially widely used ones like Maven, need to be aware of and protect against the growing risk of threat actors actively seeking committer privileges on projects as a precursor to installing backdoors in the source code. In particular, it seems that one or more nation states are playing the long game by targeting specific open source projects. Someone (likely a team of people) begins sending legitimate patches and PRs and participating in the mailing lists and other fora until they earn committer privileges. Then they insert the back door using inobvious code, wait for it to ship, and proceed with the attack against their targets. Last year xz utils was very nearly compromised in this way and only avoided shipping with the backdoor because one engineer at Microsoft noticed something funky in a beta release: https://en.wikipedia.org/wiki/XZ_Utils_backdoor This is not the first time this has happened, and it almost certainly won't be the last. For all we know there could be active exploits no one has noticed already shipped by popular open source software. What should Maven (and everyone else) do about this? There are a number of things. Most importantly, we need to make sure that all PRs and commits are reviewed before merge. Directly committing to master (as many people including myself currently have the ability to do) is not safe. It makes it far too easy to hide malicious commits. If I were an attacker I would seek out projects like Maven that allow direct commits without review or PRs. Every commit needs to go through code review, and we need to enforce this at the repo level so it cannot be bypassed. Second, we need to verify the identities of new committers. If possible, new committers should be met in person at ApacheCon or other convenient events. That's probably not feasible for everyone involved in a widely dispersed project like Maven, but a quick video chat should at least verify that a real person exists. I'm not sure how long that's likely to help given the rapid advances in genAI impersonation. Nonetheless, we should do what we can to establish a chain of trust between actual human beings. Third, we should remove commitership from the large numbers of folks who haven't contributed to the project for 5+ years. They can still remain official PMC members, and can be reactivated if they one day decide to participate again. However, right now their Github accounts and Apache SVN credentials are extra risks we don't need. Compromising existing committers accounts is another attack vector that has been used in the past and will be used in the future. Fourth, we should require all committer Github accounts to turn on two factor authentication. We might already be doing this. I don't have access to check. But if we're not, it's an easy fix to reduce the risk of hacked and stolen Github accounts being used to compromise us. There's one other technical change I'd like to consider to protect Maven users more than the Maven project itself. We should eliminate, or at the very least warn, when version ranges are used in dependency elements. See https://jlbp.dev/JLBP-14 for the rationale for this one. I don't know of an attack using this vector in Java (yet) but it has been used multiple times in other ecosystems to steal bitcoins and install malware. Java has been lucky so far, but we are by no means immune to it. There might be other things we can do to improve our security posture. This is just what I've seen used elsewhere. Like a lot of security measures, they're not without inconvenience, but they are necessary given the evolving threat landscape. We've made more invasive changes in the past to increase security, most notably requiring https for downloading artifacts, so I'm confident we can do this too. -- Elliotte Rusty Harold elh...@ibiblio.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
