From a file to a verifiable process

Help Net Security’s October 26 spotlight on Witness brings a useful software-delivery question to managed service providers: what evidence accompanies the executable being installed? Witness is an existing open-source project, not a newly announced release. Its primary documentation describes a command-line framework that records software production steps and verifies them against policy. The project originated at TestifySec and is now maintained within the in-toto ecosystem. For providers that develop integrations or package software for clients, its relevance lies in making delivery requirements checkable.

What the documentation actually demonstrates

The getting-started guide records a build step, creates signed attestations and checks the resulting artifact against a signed policy. Policies identify required steps and permitted signing keys; verification failures return a nonzero exit status. The repository lists integrations with GitHub, GitLab, AWS and GCP, along with keyless-signing options. These are documented capabilities, not a test performed by this publication. The tutorial also warns that the policy-signing key controls the gates. That warning matters because evidence is useful only within a clearly defined trust arrangement.

A bounded service for small clients

Our analysis is that an MSP should start with one repeatable delivery it owns, such as a custom connector for a small accounting practice. Agree which source revision, build environment and approval are required before distribution. Then run a controlled negative test: substitute an artifact that does not match the expected evidence and confirm the delivery process stops. Keep the client’s operational needs visible. An emergency release needs an authorized exception process and a record of why normal checks could not be completed, rather than an undocumented bypass that later becomes routine.

Who can change the acceptance rules?

For a professional-services customer buying a maintained application, the contract discussion should cover who writes the policy, who approves changes and who retains the verification records. A provider that controls both delivery and acceptance should explain how changes receive review. Evidence should remain associated with the exact file delivered, including after a support handoff or rollback. A successful check does not establish that software contains no vulnerabilities or that its business behavior is correct; it answers the requirements actually encoded in the policy. Providers should describe that boundary accurately when selling assurance. The practical opportunity is a narrower, testable promise: the client can inspect how an approved artifact was produced and whether the agreed delivery process was followed.

Sources & further reading

Our practical suggestions are editorial guidance. Verify applicability against current source and vendor instructions.

Small businessProfessional services
Suggest a correction →