Examples in this article are illustrative, not customer case studies. Product availability and coverage are described on the linked capability pages.
A source scan can pass while the deployed image still contains an old dependency. This guide gives you a code-to-runtime coverage checklist that tests the connections between stages, so a green result means something about the application you actually run.
Consider a fictional checkout service. A developer updates a package, the pipeline builds an image, and an operator deploys it to a test cluster. The exercise is to identify the evidence at each boundary, including what remains unknown. Use an authorised non-production application with representative build and deployment behaviour; a diagram alone cannot demonstrate coverage.
Code-to-runtime coverage starts with five different questions
Source analysis asks what is present in the repository. Build checks ask what the build resolved and produced. Image scanning inspects the shipped filesystem and packages. Deployment policy evaluates whether the release satisfies your rules. Runtime assessment asks what is running, how it is configured, and which application behaviour has actually been tested.
These activities overlap, but they do not substitute for one another. A source finding does not prove that the affected code was deployed. A workload relationship does not prove exploitability. Treat each stage as a separate evidence requirement before evaluating how well the platform joins them.
| Stage | Ask the evaluator to show | Keep the limitation visible |
|---|---|---|
| Source | Repository, revision and analysis evidence | Unanalysed languages or paths |
| Build | Resolved inventory and produced artefact | Missing or untrusted provenance |
| Image | Scanned digest and affected layer | Unsupported package formats |
| Deploy | Policy inputs and recorded outcome | Exceptions and unevaluated releases |
| Runtime | Workload identity and observation time | Stale observations and untested behaviour |
Record the application owner next to this checklist. Otherwise a technically useful result may still have no destination when somebody needs to change the package, rebuild the base image or correct a deployment rule.
Source evidence must identify the revision under review
For the checkout change, capture the repository and commit before looking at severity totals. Confirm that source analysis, dependency analysis, secrets detection and infrastructure checks inspect the intended input. If a tool skips a generated directory or unsupported language, record that exclusion instead of treating the absence of findings as a successful assessment.
Ask the evaluator to open one finding and show the relevant location and rule evidence. Then switch to another revision containing a harmless test change. The platform should distinguish the two analysis contexts. This is a practical way to detect results that are attached only to a repository name, where the current view can obscure which version was inspected.
A review also needs an explanation of the result. Can an engineer tell whether a package advisory, a source trace or a credential pattern triggered it? Our comparison of SAST, SCA and secrets scanning describes why those mechanisms need separate evidence.
Build and image checks must agree on identity
The manifest is an input to the build, not necessarily a complete inventory of the final image. Dependency resolution, generated files and base-image contents can introduce differences. Compare the build’s resolved inventory with the image scan, and ask which artefact each record describes.
Use the immutable image digest as the comparison point. In the exercise, build a second image from the corrected dependency and leave the first image available in the test registry. The old finding should not disappear merely because a newer build exists. Review which digest was scanned and which digest each deployment references.
An SBOM helps describe components; it does not independently establish that a build came from an approved source. Provenance and signature verification answer different questions. Keep those checks distinct in the evaluation record, including the trusted builder or signer and the policy that accepted the evidence.
Deployment checks need a result you can explain
Write down a small, explicit release policy before the demonstration. For example, require a completed scan for the proposed digest and an acceptable signature according to your organisation’s policy. Ask for both a permitted example and a deliberately incomplete example in the test environment.
Inspect the resulting decision, not only the colour of a pipeline step. The record should identify the evaluated artefact, policy version, relevant evidence and reason. Also test an evaluation error: an unavailable policy service is a different event from a finding that violates the rule, even if both block a release under fail-closed policy.
Decide how exceptions work before you need one. An exception should identify its scope, accountable approver and review conditions. It should not silently change the original scan result or create a general bypass for later artefacts that happen to share a tag.
Code-to-runtime coverage needs fresh runtime evidence
After deployment, inspect the workload’s actual image identity. A deployment request describes intent; a recent observation describes the environment at a particular time. Keep the observation timestamp and source alongside the relationship, especially when a cluster is disconnected or a collector stops reporting.
Then separate runtime context from dynamic testing. Cloud and Kubernetes posture checks inspect configuration. DAST exercises a running application within a defined test scope. In-app instrumentation is another capability again. Ask which are available, which require configuration and which are planned; the phrase “runtime security” should not hide these distinctions.
For checkout, deploy the older image to one test workload and the corrected image to another. Check that an investigator can find the workload still using the old digest. If the relationship cannot be established, the result should remain unknown rather than becoming an inferred clean bill of health.
Close the exercise with evidence, not a demonstration score
Give each checklist item a result of demonstrated, incomplete or not tested. Attach the evidence reference, owner and follow-up question. Avoid combining those states into a single score that makes a missing deployment link look equivalent to a minor presentation issue.
Finish by asking another engineer to reproduce the investigation from the retained record. They should be able to identify the source revision, built image, affected workload and next action without relying on the presenter. This handoff test reveals whether the evaluation produced an operational workflow or only an impressive live session.
Key takeaways
- Evaluate source, build, image, deployment and runtime evidence separately before testing their connections.
- Use immutable artefact identity and observation timestamps to keep old and current deployments distinct.
- Record missing coverage and planned capabilities explicitly instead of interpreting silence as safety.
- Require a reviewable decision and a reproducible engineering handoff at the end of the exercise.
How SecurityVault approaches this
SecurityVault connects repository, commit, build, image and workload context in a shared finding model. Its platform overview describes how analysis, ownership, policy decisions and evidence fit together. The useful evaluation is whether those relationships answer a question about your application, including where a link is missing, rather than whether every view contains a populated diagram.
Source and image findings can contribute to the same investigation, while deployment policy and runtime context provide additional evidence. Those connections do not turn a package advisory into proof of exploitation, and a recorded policy decision does not replace a human disposition. Keep the scope of each check visible when planning an evaluation.
Use the fictional checkout walkthrough as an introduction, then choose a representative application and agree its inputs, permissions and acceptance criteria. Ask the team to demonstrate both a connected result and an incomplete result. To plan that exercise around your own delivery process, request a technical demonstration.