Provide guidance for projects with only a single maintainer

[kimsterv]

Many open source projects only have one maintainer. How will they meet the 2 person review requirement? Are tools like automated code reviews in scope for meeting this requirement?

[joshuagl]

I had been assuming that single author projects are why two person review is only added at the highest level?

Are we OK with single maintainer projects not being able to reach the highest level?

[TomHennen]

If we really think 2 person review is valuable (and I think it is) would it be possible to investigate funding critical single author projects so they can have a second maintainer might also reduce other risks that go along with just having one person running a project.

I've also wondered if it would make any sense to pair single-author projects up with one another so they can provide each other reviews (I have no idea if that's feasible).

[konstruktoid]

Many open source projects only have one maintainer. How will they meet the 2 person review requirement? Are tools like automated code reviews in scope for meeting this requirement?

Very interesting questions in my opinion, why does the 2 person review requirement require humans?
Wouldn't a "DevSecOps" pipeline with linting, SAST, DAST, etc be as, or more, valuable than a person clicking "Accept"?

I'm not saying one thing instead of the another, but since many (if not most?) public project on e.g. GitHub are single maintainer and it's actually easier to build a CI/CD pipeline than it is to find any code reviewing volunteers.

Are we OK with single maintainer projects not being able to reach the highest level?

If a 2 person review is required for the highest level, then why not be OK with it? Just a like a SMB can't afford all fancy certifications out there, a single person project can't reach the highest level.
Perhaps a bit crude, but "SLSA is a set of incrementally adoptable security guidelines" and not about being fair.

[joshuagl]

If we really think 2 person review is valuable (and I think it is) would it be possible to investigate funding critical single author projects so they can have a second maintainer might also reduce other risks that go along with just having one person running a project.

I believe this falls within the remit of the Open Source Security Foundation's (OSSF) Securing Critical Projects WG.

I've also wondered if it would make any sense to pair single-author projects up with one another so they can provide each other reviews (I have no idea if that's feasible).

I was wondering the same thing. I think it's worth exploring. I did not suggest it as SLSA rightly calls for informed review, which requires gaining familiarity with the project and the problem domain it addresses – that may make the pool of possible reviewers smaller. We'd also need each single author project to be paired up with two more projects to meet the criteria for two reviewers.

We certainly don't want to encourage a 2-person review gaming the system, where the approvals are made without actually reviewing the code.

[joshuagl]

Many open source projects only have one maintainer. How will they meet the 2 person review requirement? Are tools like automated code reviews in scope for meeting this requirement?

Very interesting questions in my opinion, why does the 2 person review requirement require humans?
Wouldn't a "DevSecOps" pipeline with linting, SAST, DAST, etc be as, or more, valuable than a person clicking "Accept"?

More valuable than a person just clicking accept? Perhaps. But more valuable than a person providing an informed review, as required by SLSA? Not for many classes of issue. Both is, of course, the ideal.

I'm not saying one thing instead of the another, but since many (if not most?) public project on e.g. GitHub are single maintainer and it's actually easier to build a CI/CD pipeline than it is to find any code reviewing volunteers.

Are we OK with single maintainer projects not being able to reach the highest level?

If a 2 person review is required for the highest level, then why not be OK with it? Just a like a SMB can't afford all fancy certifications out there, a single person project can't reach the highest level.
Perhaps a bit crude, but "SLSA is a set of incrementally adoptable security guidelines" and not about being fair.

Indeed. My question was intended to be leading. I happen to agree with this position, I am OK with the highest level being a higher bar than some projects are able to meet.

[msuozzo]

Very interesting questions in my opinion, why does the 2 person review requirement require humans?
Wouldn't a "DevSecOps" pipeline with linting, SAST, DAST, etc be as, or more, valuable than a person clicking "Accept"?

One concern here is that any automated analysis pipeline can be gamed. Assuming the attacker has access to the SAST system, they can craft a change that falls into the system's false negative and get it submitted without human review.

You can make the argument that underhanded code is similar in effect (see: Minnesota's Linux patch review paper) but this manner of attack has a higher chance of discovery. Placing the human in the loop allows a non-artificial intelligence a chance to flag things that seem suspicious.

[konstruktoid]

One concern here is that any automated analysis pipeline can be gamed. Assuming the attacker has access to the SAST system, they can craft a change that falls into the system's false negative and get it submitted without human review.

Very true, but I'm going to play Devil's advocate and paraphrase you:
One concern here is that any person performing a code review (as a trusted party) can be gamed, threatened and/or bought. E.g https://www.scribd.com/document/499459854/Plea-Agreement-for-Egor-Igorevich-Kriuchkov (even though this failed)

[msuozzo]

Right but that's kind of what I'm alluding to: Humans still have flaws (miss stuff, can be subverted) but they can also contact law enforcement or make a stink on Twitter. And managing human assets is far more burdensome and risky than compromising technical ones.

As a gold standard, I think we should require 2-Party review but perhaps we could also introduce an optional or mandatory criterion at a lower level that advocated for those sorts of automated checks. The real issue would be ensuring such checks were meaningful and well-defined (to avoid such a requirement devolving into mindless box-ticking).

[MarkLodato]

Are we OK with single maintainer projects not being able to reach the highest level?

IMO yes. Having a single maintainer is a risk, and SLSA intends to encode that risk. Human review is an industry-standard best practice to reduce risk. Any alternative would have to meet the same bar, and I'm skeptical that one exists today.

If an organization requires SLSA 4 of its dependencies but currently relies on a single-maintainer project, it has a few choices:

• Convince the dependent project to require two-party review of all changes, such as by offering to co-maintain the project or by donating for reviews. This may not always work.
• Remove the dependency.
• Accept the risk and exempt this dependency from the requirement.

Assuming you all agree, we should explain this somewhere. Perhaps in a FAQ?

[joshuagl]

Are we OK with single maintainer projects not being able to reach the highest level?

IMO yes. Having a single maintainer is a risk, and SLSA intends to encode that risk. Human review is an industry-standard best practice to reduce risk. Any alternative would have to meet the same bar, and I'm skeptical that one exists today.

Yes, agreed.