jperezduerto.info
Security in depth · Unit 28 · Lesson 10 of 11
A signature answers a limited question
Keep signature validity separate from release suitability, support, and software behavior.
Helpful before thisThreat modeling: ask before building
After this lesson you can
- Explain why a correctly signed artifact can still fail the application’s release policy.
Authentic software can still be the wrong version for the job.
What verification establishes
Artifact verification must connect the signature to the actual content and an accepted signing identity or key. Checking the mathematics against an arbitrary key is not enough to establish the publisher your policy expects.
Even a correctly verified signature does not certify safe behavior, current support, or suitability for your application. Those are separate claims. Provenance can add evidence about how an artifact was produced, but its claims and trusted source also need evaluation.
Supplied record: the gallery kiosk
The fictional gallery wants to release a kiosk using PhotoTiles. Its review package contains:
Artifact identity: PhotoTiles 2.4, matching its signed release record.
Verification: signature and artifact binding valid; expected publisher identity accepted.
Maintainer notice: support for 2.4 ended; version 3 is supported.
Gallery policy: production components must have current support.
Compatibility assessment of version 3: not yet completed.
Assume verification correctly applied the gallery’s trust policy and the supplied support notice is current. The authenticity check passed. The proposed version still fails the support requirement, so the record does not justify release.
Preserve both conclusions
Write “signature verified” and “version unsuitable under current policy” as distinct results. Request compatibility and dependency evidence for the supported replacement before recommending it.
Do not infer that 2.4 is malicious, or that version 3 has no vulnerabilities. Neither follows from this record. Your acceptance note should identify the exact replacement artifact, repeat the required authenticity checks, and document support plus the kiosk’s functional and security review. Reusing a familiar package name is insufficient evidence that its content is unchanged.
Check yourself
No timer. No penalties. Read the explanation and try again whenever you like.
This lesson’s questions have changed. Your reading progress is saved; review the updated questions.
-
How should the team classify the PhotoTiles package record?
Show the answer
Correct answer: The signature checks passed, but version 2.4 fails the stated support requirement for release. Authenticity evidence and release policy answer different questions. This policy requires support, and the supplied maintainer record says 2.4 is unsupported.
Try it
- WriteWrite a two-part release decision: what the signature evidence establishes, and why the version is not yet acceptable. Name the next evidence needed for a supported replacement.