| HN Mirror

Sometimes attestation can be involved if there are things like manual test or QA phases, and perhaps the QA manager needs to attest that the feature / release has passed some test plan. Sometimes it is possible to replace these "human attestation" process steps with automation, if the org is willing to invest. E.g. it may be possible to eliminate manual testing with automated testing, but it requires engineering effort to be allocated to it. Then perhaps "QA manager attesting the tests in the release's test plan all passed" could be replaced with an automated automated test suite pass / fail signal. There is value in having independent testing, and this could go off the rails if people don't design and then implement good test plans.

Sometimes there could also be attestation for things like "does the design and implementation of new service's architecture comply with security policy - does it have the approval of the security representative". some of these things can be automated away with tooling -- e.g. install a tool to check for glaring container security vulnerabilities that runs at code review time, and block changes from being merged or being deployed into dev or staging environments if there are high or critical sev security issues, with some manual process to override the inevitable false positives when the tooling makes a silly decision.

All that said, it isn't necessarily practical or cost effective to attempt to automate everything. Skilled human expert review of proposed designs and implementations for security flaws will likely do a much, much more effective job than relying on tools alone. So it's quite reasonable for designs and implementation to require independent security review and approval (or "attestation") in contexts where security is critical. But if things like security review of implementation (let alone design) is being done while cherry-picking commits onto a release branch, that sounds far too late in the lifecycle.

Another familiar example of attestation is things like code review, in projects that require all changes to be approved by one (or perhaps more) reviewers. By approving a PR, the reviewer "attests" that the change looks good to them, that it will implement the stated requirements and doesn't have any obvious flaws, etc. High quality code review is incredibly valuable, requires manual effort, but can be structured into sensible release and deployment processes, particularly by taking advantage of github / gitlab etc.

This reviewing and "attesting" activity can happen much earlier in the lifecycle than deployment or activation.