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. Probably get much better results from getting a skilled human export to review proposed designs and implementations for security flaws, and then emit an attestation if they think the design and build is OK. But if this is being done as part of e.g. 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.
1-2 days. Multiple senior engineers cherry picking commits into a release branch with even more seniors doing atteststion. It’s a company-wide effort that happens every sprint. We have “staff” SREs who can’t figure out automated releases.