# Secure Release Processes with in-toto Policy Verification

Source: https://www.testifysec.com/blog/secure-release-processes/

Author: Frederick Kautz

Published: 2024-11-13

How flexible in-toto policies can verify attestations for code reviews, SBOM integrity, test results, vulnerability scans, and build provenance.

From the event archive

This is an event archive. Product names, affiliations, and demonstrations reflect the recording, not the current release. The overview is editorial context, not a transcript or a product support commitment.

- [Current TestifySec docs →](https://www.testifysec.com/docs)
- [Trust architecture →](https://www.testifysec.com/docs/cilock/trust)

## Watch the recording

The player loads from YouTube when you choose to play.

[Open the recording at its source ↗](https://www.youtube.com/watch?v=-tGn0kEeA4M)

Published by CNCF \[Cloud Native Computing Foundation\]. The source is authoritative for the recording title, date, and participants.

## Questions to take into the discussion

- Expressing release requirements as policy.
- Binding test and build evidence to artifacts.
- Deciding where verification must be enforced.

Use these as an editorial guide while watching or exploring the topic. They are not quotations or a verified transcript of the session.

## Apply the ideas to a current workflow

For an implementation, start with the [shared documentation](https://www.testifysec.com/docs). CI/lock captures the work, Pushgate checks the push, and the platform manages gates and technical control evidence. Check the [support matrix](https://www.testifysec.com/docs/concepts/support-matrix) for the release and environment you intend to use.

A signed statement can establish attribution and detect alteration under a configured trust model. It does not establish that the producer reported honestly or that a whole compliance framework is satisfied. The [trust architecture](https://www.testifysec.com/docs/cilock/trust) explains those boundaries.