# Beyond “Trust Me, We Ran the Security Scan”: Evidence You Can Inspect

Source: https://www.testifysec.com/blog/cole-cryptographic-security-scan-evidence/

Author: TestifySec

Published: 2025-12-10

Updated: 2026-10-06

Tie a scan result to the source or artifact it examined, and make the producer and verification policy explicit.

Editorial update · October 6, 2026

Revised by TestifySec Editorial to remove unsupported outcome claims and explain the current product and trust boundaries. The original publication date and URL are preserved.

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

“We ran the security scan” leaves several questions unanswered. Which code was scanned? Which scanner and configuration were used? What did it report? Is that the same artifact we are about to ship?

 

A screenshot may be useful context, but it rarely answers all of those questions. A retained test record with explicit artifact identifiers is a better starting point.

 

## Transforming scans into attestations

 

Capture the test invocation, the source or artifact digest, and the resulting report. Sign the statement with an identity the verifier is configured to trust. Preserve the verification material and the result, including failures.

 

A report hash lets a reviewer detect changes to a report. It does not establish that the report was accurate. The producer’s isolation and the scanner’s coverage remain part of the trust decision.

 

## Example: scanning with Witness

 [Witness](https://witness.dev/) can wrap a configured scan as part of an attestation workflow. Follow its maintained examples for the chosen release and signer. Select the attestors and output capture needed by your policy; wrapping a command alone does not automatically collect every item an auditor needs. 

For TestifySec’s current product workflow, use [CI/lock’s first-attestation guide](https://www.testifysec.com/docs/cilock/getting-started/first-attestation). Keep Witness instructions and CI/lock instructions separate.

 

## Supporting NIST SP 800-53 SA-11

 

A scan record can support evidence for developer security testing and evaluation. The control owner must still determine the required testing plan, scope, coverage, review, and remediation. A clean scan or a pair of hashes does not by itself establish that a vulnerability was fixed or that the whole control is satisfied.

 

## Enforcement is a separate step

 

A verifier must check the expected identity, artifact binding, required result, and policy before the action that depends on them. Generating or uploading an attestation does not automatically block a deployment.

 

Pushgate evaluates configured requirements at the Git push boundary. Other release and deployment decisions need their own configured enforcement points. The platform manages gates and reuses evidence across technical control mappings.

 

## What a reviewer should be able to inspect

 

- The exact source or artifact examined.
 - The scanner, configuration, and result that support the claim.
 - The producer identity and how it was authenticated.
 - The policy and verification decision.
 - The limits of the test and when it must be repeated.

 

That is a more useful promise than “evidence without doubt”: a record whose basis and limits can be checked.

 [Originally published on LinkedIn](https://www.linkedin.com/posts/thecolekennedy_trust-me-we-ran-the-security-scan-isnt-activity-7404579655162150912-jQv2).