This issue complicates the open source and supply chain security space. For attacks like xz, such strategies can be used by attackers to build “fake” trust among fellow OSS community members.

A few days ago, this discussion ignited in the OSSF Slack , which talked about the issue of credibility farming in several open source repositories.

OSSF Slack Discussion

So, the issue revolves around GitHub (or equivalent platforms) accounts approving or commenting on old pull requests and issues that were already resolved or closed, where these meaningless contributions show up prominently on the user’s profile and activity feed, making their involvement seem more significant than it actually is, without closer look.

Example showcasing the issue (more to be found in the references section) - https://github.com/slsa-framework/slsa-verifier/pull/379

Fake Approval

and the contributions are shown in the person’s profile. fake contributions

Receiving spam on open-source projects [fake contributions] [pixel art in github history] is a common issue that open source maintainers face regularly, but this problem escalates it to a new level. However, it is not a security vulnerability. It’s about a practice that is widespread, potentially dangerous, and significantly underreported.

How to Identify Suspicious Activity in Your Repository?

  • Users who are not members or contributors to the project approving or commenting on long-closed and approved Pull Requests and Issues.
  • Non-contributors with no genuine involvement in projects displaying seemingly significant activity in open-source software (OSS) projects.

As an Open Source Maintainer, What Can I Do?

My 2 Bits

Reputation farming isn’t a direct vulnerability, but it can escalate to that level, as seen in incidents like the xz supply chain attack. It complicates the trust-building process, which is crucial in the Open Source world for sustaining projects. Developers with impressive profiles may not always be trustworthy, requires careful scrutiny to build trust which takes time and effort. Current solutions often involve manual intervention, adding to the workload for open source contributors and maintainers. These issues underscore the risks of relying solely on simplistic metrics to evaluate software development skills and contributions. Moreover, they underscore the challenge of establishing and preserving trust within open source communities.

Addressing issues like these requires a collaborative effort between platforms that enable developers to work securely and responsibly & developers must also stay informed about emerging issues and remain vigilant against supply chain risks, by subscribing to newsletters, reading such blogs as this one, being involved in the community, etc.

References

More blogs covering this issue -

Examples -

OSSF Slack Discussion Thread - https://openssf.slack.com/archives/C019M98JSHK/p1719225074824219

SIREN Mailing List - https://lists.openssf-vuln.org/g/siren/message/1