|
|
|
|
|
by dlor
1514 days ago
|
|
We use the generic in-toto Attestation data model which could capture crev style reviews, but there are no other concrete plans that I'm aware of. To be honest, crev is pretty elegant but I find manual code review like this to be pretty ineffective in stopping attacks. |
|
I think there should also be a culture of ensuring that a new patch release of some software passes the acceptance tests of the previous patch release (without changing or removing the tests).
A similar test for linting rules should also help (especially if those rules are designed to prevent Unicode homoglyph attacks), and a check for new uses of dangerous APIs like filesystem or network access would assist reviewers too.
Of course there is almost unlimited potential for underhanded code, if an attacker is skilled and patient enough to carefully introduce subtle bugs over time, but I think that a meaningful number of attacks could be avoided with these measures in place.