No. A signature on a container image shows which identity signed a specific digest and that the content has not changed since. It does not show that anyone scanned the image, found it clean, or fixed what they found. Scanning and signing answer different questions, and a buyer should ask for both.
What a signature actually proves
Image signing tools bind an identity to an image digest. Sigstore's cosign documentation describes signing as attaching a signature to an image so that others can verify it later against a public key or an identity. The signed thing is a digest, which is a hash of the image manifest. If one byte changes, the digest changes and the signature no longer matches.
So a valid signature gives you two facts: this digest was signed by this identity, and it is the same digest that was signed. That is useful. It helps you detect tampering in transit or in a registry, and it tells you who to ask if something is wrong.
What a signature does not prove
An attacker can sign a malicious image. A careless team can sign an image full of known vulnerabilities. A signature is about origin and integrity, not about quality.
| Question | Signature answers it | Scan answers it |
|---|---|---|
| Who published this digest? | Yes | No |
| Was it changed after publishing? | Yes | No |
| Does it contain a package with a known CVE? | No | Yes |
| Was it checked on a given date? | No | Yes, if the scan is dated |
| Is the package actually exploitable here? | No | Only with extra analysis |
How to connect the two
The cleanest pattern is to scan first, then sign the digest that passed. That way the signature carries a meaning: "this digest was built by our pipeline and passed our policy on this date." Without that ordering, the signature only means "our pipeline built it."
Some teams go one step further and attach the scan result or an SBOM to the image as an attestation, so the evidence travels with the digest. If you do this, record the scan date and the data version used, because a result goes stale. A clean scan from March says little about a new CVE published in October. A related point is that vulnerabilities appear after signing, so scanning has to repeat for images already deployed.
Questions to ask a vendor or a supplier
When someone hands you a signed image, ask:
- What identity signed it, and how do I verify that identity?
- Was a vulnerability scan run on this exact digest, and when?
- What policy did the scan have to pass?
- How often do you rescan images that are already released?
- Can I get the SBOM for this digest?
If the answers to 2 to 5 are vague, you have an integrity story and not a vulnerability story.
A worked example: sign on Monday, vulnerable by Friday
Consider a team that builds an API image on a Monday. The pipeline scans the image, finds nothing above its policy threshold, and signs the digest. Everyone is happy, and the signature verifies correctly from that point on.
On Friday a new CVE is published against a library inside that image. Nothing about the image changed, so its digest is the same and the signature still verifies. A verification check passes. A fresh scan, however, now reports a high severity finding. Both results are correct. They answer different questions.
This is why a signature cannot stand in for a scan. The signature is frozen at the moment of signing, while vulnerability knowledge keeps moving. Anyone who treats "signed" as "safe" will be wrong a few days later without anything in the image having changed.
Step by step: build both proofs into a pipeline
- Build the image and record its digest, not only its tag.
- Scan that exact digest and store the result with a timestamp and the data version used.
- Apply your policy, for example no fixable critical findings.
- If the policy passes, sign the digest. If it fails, do not sign, and do not publish.
- Attach the SBOM or the scan result to the image so the evidence travels with it.
- At deploy time, verify the signature and check that a scan exists that is newer than your maximum age, for example seven days.
- Rescan deployed digests on a schedule, and raise findings that appear after release.
Steps 6 and 7 are the ones teams skip. Without them the signature gives a false sense of continuing assurance.
What to look for in supplier evidence
When a supplier says an image is signed and scanned, ask for each claim separately and compare the answers with this table.
| Claim | Evidence to ask for | Weak answer |
|---|---|---|
| Signed | Signer identity and how to verify it | "We sign everything" with no verification method |
| Scanned | Dated result for this digest | A screenshot with no date or digest |
| Passed policy | The policy and the threshold | "Clean" with no definition |
| Kept current | Rescan schedule for released images | "We scan at build" only |
| Has an SBOM | SBOM for this digest | An SBOM for a different version |
A good supplier answers all five in one short document. A weak one answers the first and goes quiet on the rest.
Common mistakes
- Verifying by tag. A tag can move to a different digest, so verify the digest you will actually run.
- Treating a signature as a statement about the contents. It speaks to origin and integrity only.
- Signing before the scan finishes, so the signature carries no policy meaning.
- Never recording which scan went with which signature, which leaves you unable to answer an auditor later.
Try it yourself
Click through it at your own pace, or open it full screen.
Run the demo and notice that the findings come from the packages inside the image, not from any signature on it.
Where Safeguard fits
Safeguard can scan an image and its dependencies and produce SBOM evidence you can keep next to your signing records. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Can I trust an image from a verified publisher without scanning it?
Trust the origin, yes. Trust the contents, not automatically. A verified publisher can still ship an image with known vulnerabilities, so scan what you pull.
Should I sign before or after scanning?
After. Sign the digest that passed your policy so the signature reflects a checked image.
Does a signature expire when a new CVE is published?
No. The signature stays valid as long as the digest is unchanged. That is exactly why you also need regular rescans of released images.
Sources
Last reviewed: 19 October 2026.
