Comment by Wilder7977

A classic example would be build (container build) images instructions. Of course, other examples are running a security static analysis, running tests, or whatever other standard practice is desidered for security.

Say that you build 100 images, each with its own repository where there is the code, there is the Dockerfile etc. Now, if you build images with "make build", it means that ultimately the actual command line flags for the build command are going to be in the Makefile, inside each repository. These flags could include flags like --cache-from, build arguments, --add-host, or many other flags that may not be desirable in an organization. Imagine what the workflow file would like for such a case: you have your in-repo CI file that clones the repo, and then executes make test, make build, make push, etc. Do you know if make push sent the PCI registry secret somewhere else on the internet? Do you know what exactly flags were used to build? Not really, you need to trust the code inside the repo to at most collect this information, and how do you know it was not tampered or spoofed?

Compare it with the following scenario: All 100 repos at some point in that CI invoke an external workflow, which contains instructions to build images, push them to the registry (and run tests before, whatever). This can obviously also be a combination or workflows, I am saying one for simplicity. This workflow (or workflows) at the end produces an attestation, including provenance data and about what is run. It can do so reliably, because the instructions of what had to be done are within its own context. There is no input that comes from outside (e.g., the repository) that determined build flags or instructions, outside of what the workflow exposed (e.g., few variables).

In the second case, I can then use a policy that restrict images that have attestation and that were built by my workflow(s) that contain standard and deterministic instructions. This way I know that no image was built using weird build flags, including strange dependencies, maybe tampering with network and DNS (in makefile I can write whatever) or local docker cache, etc. I know this because a standard workflow was executed in a fresh, "sterile" environment with a standard set of instructions, that can't be changed or tampered by those controlling the repository content.

Note that all of the above is solely concerned with being able to make security statements on the build artifact produced, not on the context of the build (e.g., no network access).