LEARN. PRACTICE. GROW.1. Identify exactly what will run
A release needs an artifact identity, not merely a readable name. In the fictional file-processor example, record image digest, production version, scan report, and promotion decision. A tag can point to different content when configuration permits changes. In ECR configured as IMMUTABLE without exclusions, attempting to reuse an existing tag fails. The proposed operational solution is to produce a newly identified artifact and promote that version through the approved process. Do not change global tag configuration merely to bypass one pipeline failure. During incident investigation, confirm that the cited report corresponds to the artifact actually running, including differences between environments and versions retained for rollback.
2. Scope image analysis
Enhanced scanning includes supported operating-system and language packages. Continuous scanning enables new analysis when relevant CVEs emerge, while scan on push refers to analysis when content is pushed. If filters for both modes cover the same repository, continuous takes precedence. An unmatched repository is not automatically covered; manual enhanced scans are not a shortcut for repairing that exclusion. At handover, present the expected repository set and effective configuration for each. When findings are absent, distinguish no identified vulnerabilities from no execution. Comparing production inventory with analyzed inventory is an original operational control that needs an owner and a frequency appropriate to application risk.
3. Investigate lost coverage
SCAN_ELIGIBILITY_EXPIRED does not mean a vulnerability was fixed. Check why eligibility was lost and what is needed to obtain current evidence for the relevant artifact. ARCHIVED images are not scanned; returning to ACTIVE triggers new analysis. For rescan duration, explicitly identify whether last pull or last in use was selected and also consider the push window. A usage report does not automatically satisfy the pull condition of a configuration using that mode. Avoid assuming identical defaults across every account. The local exercise distinguishes unknown coverage, current analysis with findings, and no findings within analyzed scope. None of those outcomes automatically authorizes release; acceptance still requires context and accountability.
4. Choose the effect of signing
Lambda signing checks integrity and trust at deployment. Adding configuration does not retroactively stop existing unsigned code. Added layers also need an allowed profile, and this feature does not apply to functions packaged as container images. For expiry, profile, or revocation failures, Warn permits deployment with a warning; Enforce blocks it. The integrity check compares the package with its signature. Do not extend the Warn rule to every failure without confirming the contract. Within the project, separate signing ownership, policy decisions, and exception approval. A valid signature demonstrates different properties from dependency analysis: the approved package can still contain a vulnerable library.
5. Compare Lambda coverage with production
Inspector standard scanning looks for dependency vulnerabilities; code scanning adds custom-code analysis and requires standard scanning to be enabled. Check runtime support, exclusions, and recent activity. Documented analysis covers $LATEST, so a clean result for that version does not establish the state of another published version used by the production alias. Functions without invocation or modification in the last 90 days are automatically excluded. Do not invoke an unknown function merely to change that indicator; first understand its effects and define an authorized rehearsal. Ask the application owner to map the analyzed artifact to the promoted artifact. Coverage gaps should appear in reporting with a concrete action, not disappear inside an aggregate zero-finding count.
6. Handle findings and deliver usable evidence
A code finding can include a snippet containing embedded credentials. Before pasting it into a shared ticket, limit access and remove sensitive data; retain sufficient evidence in the appropriate investigation location. A service-generated fix suggestion also needs review and functional tests. Compilation does not demonstrate that payments, reconciliation, or error handling remain correct. Prepare a decision identifying artifact, coverage, relevant findings, treatment, owner, and deadline. In a release meeting, explain signature trust, vulnerability analysis, and functional behavior separately. This lesson produces an evidence chain with declared limits. If a stage was not demonstrated, document the gap and risk decision without inventing automatic security certification for the package.
# Original fictional evidence triage, not an Inspector eligibility engine.
# No credentials, network calls, or deployments.
def evidence(scan_digest, running_digest, covered, findings):
if scan_digest!= running_digest:
return "artifact-mismatch"
if not covered:
return "coverage-unknown"
if findings:
return "findings-need-treatment"
return "no-findings-in-analyzed-scope"
assert evidence("a", "b", True, []) == "artifact-mismatch"
assert evidence("a", "a", False, []) == "coverage-unknown"
assert evidence("a", "a", True, ["CVE-example"]) == "findings-need-treatment"
assert evidence("a", "a", True, []) == "no-findings-in-analyzed-scope"
assert evidence("a", "b", False, []) == "artifact-mismatch"
print("five artifact-evidence cases passed; no release was authorized")
A production image lost scanning eligibility. The manager requests current evidence for that digest before closing the risk.
Common pitfalls
Signing as absence of CVEs; Warn as blocking; zero findings as coverage; $LATEST as every production version.
Related topics: Incident response · Acceptance and RUN handover
Confirm identity, coverage, and control effects before using an indicator to accept a release.
Reference: ECR enhanced scanning · SCS-C03