The security team needs to know how the jar was built. The product team owns the build script, and they will not let anyone touch it.
Many teams have this problem. The script is often years old and it works, and its owners have other work to do. So we tried to answer the question without changing the script at all.
The build
Open source Jenkins runs a Groovy pipeline. The pipeline calls python3 build.py, which clones a Git repository, compiles Java with javac, and packages a jar.
We ran that one command under cilock run --trace and changed nothing else. When the build finished, cilock signed an attestation collection. It named every program the script started, including git clone and the helper programs that git starts by itself. It also recorded the exit code and the digest of every file the build read and wrote. The digest of the jar is in a signed Merkle tree.
Trying to break it
An attestation collection is useful only if a step checks it. So the release step runs cilock verify before the jar is released. It checks the jar against the attestation collection and a policy that the security team signed with its own key. Our policy was short: the build exited with code 0, the trace shows git, javac and jar running, and the build was traced.
The jar from the pipeline passed. Then we changed one byte of it and verified again. Blocked, because its digest is not in the attestation collection.
Next we ran the same build without tracing. The policy blocked that too, and the reason named each rule it failed. The trace did not exist, so it could not show git, javac or jar running.
Last, we pointed the pipeline at a repository that does not exist. We expected cilock to change what the developer saw. It did not. The developer saw the same git error and the same failed build in Jenkins as before, and cilock still signed an attestation collection that records the failure.
What surprised us
The untraced build taught us the most. Without --trace, cilock still signed an attestation collection with the command, the exit code, the environment, and the digest of every file in the workspace and every product. A changed jar still fails verification against it.
So tracing is not what stops a swapped artifact. Tracing answers a different question: how was this built? It records the programs that started, the files they read and wrote, and the network activity. A team can start without it, then turn it on for the steps where the policy must know which programs ran.
Three ways in
We added cilock to the same pipeline three ways, and the difference is mostly about who owns the cilock flags.
With the inline option, one line in the Jenkinsfile puts cilock run in front of the command. It is the easiest to read, but every pipeline has its own copy of the flags.
With a shared library, the security team owns one Groovy step called cilockSh. A product team writes cilockSh where they wrote sh and names the step. When the security team changes a flag, no pipeline changes.
With the global shell hook, Jenkins sends every sh step through a wrapper script, and no Jenkinsfile changes at all. It also traced a small cp step that we did not think about. That is useful, because you see every step your pipelines run.
Try it
Start with the shell hook on one Jenkins controller. Read the attestation collections it writes for a few days. Then write the policy from what you see, and move the steps that matter to the shared library.
The Jenkins tutorial has every pipeline, the library step, the hook, the policy and the verify command, exactly as we ran them.