Scope for scaling up dependency audits / code reviews

33 views
Skip to first unread message

Aditya Sirish A Yelgundhalli

unread,
Dec 11, 2021, 7:14:14 PM12/11/21
to wg-securing-cr...@googlegroups.com
Hello folks,

I'm new-ish to this group--I've emailed once or twice, and I've attended
a couple of meetings. I'm a PhD student at NYU, and a co-maintainer of
the in-toto project. I wanted to reach out to understand some of the
broader goals of the working group, as well as talk about some things
we've discussed internally at in-toto.

One of the things we've been focusing on is scaling code review for
dependencies. As we all know, it's essentially impossible for every
developer to audit all their dependencies, and while part of the
solution is to make dependency graphs more manageable, another aspect
seems to be to develop a socially driven structure for code reviews.
This isn't a new idea--crev (https://github.com/crev-dev/crev) is
working on something similar. We've spoken to the crev folks because on
the in-toto side of things, we're beginning work on defining a code
review attestation type
(https://github.com/in-toto/attestation/issues/77). We plan to
incorporate crev-style attestations encompassing entire packages as well
as more typical code reviews you'd find on pull requests and so on.

I'm reaching out to this group because I think the folks here may be
uniquely poised to contribute to these efforts. While identification of
these projects is a first step, my understanding is that when any of
these open source projects are used by companies, they perform an audit
of the packages in question. I assume that at least some of the feedback
goes back to the maintainers, plus patches and the like, all of which
are very welcome. But is there room to formalize this process through
this working group? Further, if the reviews can be captured in crev-like
attestations, everyone could benefit from it. I'm a big fan of the idea
behind crev, and scaling up the number of reviews / attestations could
massively help. I'm curious what this would entail, and any challenges
people foresee in implementing something like this.

We'd also love to hear about your use cases for code review (or other
human review) attestations as we start work on the in-toto approach.
Please feel free to drop by the GitHub issue and leave any comments you
may have. :)

Thanks!
Aditya
OpenPGP_signature
Reply all
Reply to author
Forward
0 new messages