slsa-framework
Strongly authenticated robots
Strong authentication: Authentication that maps back to a specific person using an authentication mechanism which is resistant to account and credential compromise. For example, 2-factor authentication (2FA) where one factor is a hardware security key (i.e. YubiKey
If you have a robot account that is performing actions in Github, like reviewing or merging PRs, can that robot be considered to have 'strong authentication'? I can configure 2FA for the robot account but the token that the robot ultimately uses could conceivably be compromised and used without any second factor being required.
Good question - this should be clarified. There are actually two places robots come in:
- Verified history: How does a robot "strongly authenticate"?
- Two-person reviewed: Can a robot count as one or even two persons?
In the original SLSA draft, we had a clause that allowed changes from "trusted robots" that themselves honored the two-person principle. In other words, it must be sufficiently locked down to prevent a single person from causing that robot to propose a change that other team members did not review. But ultimately we decided to drop this clause from the initial draft because it was too ambiguous. I suspect we'll want to reincorporate something like this, but we need to nail down the details.
Can a robot count as one or even two persons? (for Two-person reviewed)
We might consider allowing relaxing two-person review to one person if the proposal is from a "trusted robot". Most "trusted robot" changes are (unsurprisingly) very mechanical, like reformatting or renaming.
However, while you should definitely use many tools to scan proposals before accepting them, I don't think robots make very good reviewers. Robots typically look at narrow issues, not the issues a human can understand.
The bigger problem is that I think many OSS projects cannot implement "two-person reviewed", or if they do they risk long delays of security-relevant functions. That said, obviously it's better to require two-person reviewed if you can do that reliably.
Relates to #196. The two-party approval requirements will most likely not make 1.0, except the recommendation to use two-party approval for all administrative changes to the build service. Therefore I think we can defer this till post 1.0
