Thoughts on xz backdoor. 1) Lack of a robust identity system on github (except when there is a tie-in to an organization which is slightly better). Anyone can create as many sock puppets accounts to do code reviews, nudge maintainers to add someone malicious as co-maintainers, etc. This is same for both most critical projects in critical infrastructure or a hobby experimental project.
2) Lack of tie-in of source to release artifacts. In xz, a malicious developer was able to modify release tarballs without anyone noticing (except test binaries). This could be solved if we have Sigstore-signed SLSA provenance everywhere, but realistically what can we do now ? Maybe OSS-Fuzz and other test frameworks need to independently test release binaries, without any developer intervention (e.g. there was some tripping on valgrind and sanitizer in this case, might not apply in other cases). Maybe, we need capability analysis (e.g. with Capslock) that looks at capability differences between versions and trips on suspicious things.
3) GOSST Upstream team had an interesting interaction with Jia Tan last year where we were trying to improve Scorecard scores for the project. The 2 PRs on Security Policy (#47) and Pinned Deps (#67) additions were successfully accepted (regular dev interactions, nothing suspicious). Jia Tan first allowed both options of email address and github security advisories, but later silently changed it to email-only a few days before launching the attack. Could someone have found this kind of PR change suspicious (or an AI commit monitoring pipeline) ?
4) Google had funded a manual security audit on xz-utils in 2023 with a vendor. The vendor didn’t spot anything suspicious and the only suggestions made were to improve fuzzing coverage. Just reinforces the fact that manual audits are hard (similar to finding a needle in a haystack). Jia Tan had a relieved response - “We are happy that no vulnerabilities were found!”.
5) OpenSSF Scorecard is not designed with the use case of a malicious maintainer. In early days, there were some attempts to create such a check but it was unfeasible to do comprehensive developer reputation checking with github token limits. We settled down to create a contributors check which relies on checking if there were any contributors from companies/orgs (could be still faked due to no validation on organizations). Should there be stronger validation of company or org identities? Still this is a tough problem for small, transitive dependencies that are operated by a single independent maintainer with losing interest in maintenance.
6) Should every binary artifact in an OSS repository be scanned (including PR upload) ? Could VirusTotal help to find some obvious things ?
7) There is quite a bit of twitter activity on OSS sustainability and how funding could have solved this. In my interactions with folks in OpenSSF Alpha-Omega, places where money has helped significantly is to give to OSS foundations (e.g. Rust, Python, etc). This helped them hire the first dedicated security staff for triaging, add security features (e.g. python trusted publishing, rust-c/c++ interoperability, etc), etc. We still need to find a scalable way to fund projects (some simple marketplace that is natively part of GitHub/GitLab/etc) and more importantly find contributors with hands on the keyboard (companies leveraging OSS, interesting vendors, etc).
8) What does a developer reputation mean ? Did Jia Tan make any mistakes that could be used to spot his malicious behavior (project activity, PR descriptions to code diff matching, user interactions, etc). This is a great area of research and we would love to collaborate here if you have ideas.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
