Evidence summary
Evidence summary refers to a collection of evidence pieces that are relevant for a set of artifacts. The pipeline currently uses two approaches to collect and summarize evidence, v1
and v2
. The intention is that v1
is superseded by v2
.
v2 evidence collection
The evidence locker stores three kinds of entities: Assets, Evidence, and Attachments. For more information, see v2 evidence format.
Asset
An asset represents something that you can test and scan, such as a Git commit in a repository or a docker image.
Evidence
A piece of evidence represents the outcome of a scan or test. Evidence is always connected to at least a single asset. Multiple assets are allowed. For example, a single end-to-end test suite probably tests multiple assets together.
Attachment
An attachment is arbitrary data that can be attached to a piece of evidence. It's usually the raw output of the tool that performed the scan or test.
Collecting evidence
Use the collect-evidence
script to collect evidence.
Evidence summary
In contrast to v1
, v2
evidence is stored in a flat hierarchy, where each piece of evidence is identified by its own hash. This hash provides a layer of integrity protection. That is, any modification of the evidence
content can be detected. As each piece of evidence is related to one or more assets, the evidence summarization algorithms discover the relevant evidence based on assets (as opposed to pipelines run IDs in v1
).
Evidence is summarized, based on the following.
- Pipeline Run ID: Evidences are scoped based on the pipeline run ID. Scoping sets the context of an evidence.
- Asset: An asset is a fundamental entity that is subjected to rigorous testing and scanning. These assets encompass various forms, such as existing Git commits in repositories to Docker images.
In the CI pipeline, evidence is summarized, based on the following.
- The scope is
pipeline_run_id
of the current CI run for the evidence summarization. - The asset list gets computed by using the list_artifact command that list all the saved artifacts in that run.
In the CD pipeline, evidence is summarized, based on the following.
-
The
provenance
field of each inventory item acts as theasset
for the summarization. We have three types of asset lists:- Delta asset list: Assets which got modified from the last deployment in the deployment environment.
- Non-delta asset list: Assets which are not modified from the last deployment in the deployment environment.
- Full asset list: Assets from all the inventory entries coresponding to the deployment environment.
-
The
pipeline_run_id
field of each inventory item acts as thescope
for the summarization.- The CI scope read from the
pipeline_run_id
of the inventory entries. - Thw current
pipeline_run_id
as the CD pipeline scope.
- The CI scope read from the
In the CC pipeline, evidence is summarized, based on the following.
-
The
provenance
field of each inventory item as theasset
for the summarization. Assets from all the inventory entries that corespond to the latest on the deployed environment. -
The
pipeline_run_id
field of each inventory item acts as thescope
for the summarization- The CI scope read from the
pipeline_run_id
of the inventory entries. - The CD scope read from the
CD-pipeline_run_id
tag that is created at the inventory conclude. - The current
pipeline_run_id
as the CC pipeline scope.
- The CI scope read from the
For more information, see Inventory. For more information on prod
summarization based on pre-prod evidences, see Collecting evidence summary.
The v2
evidence summary is calculated by default.
v1 evidence collection
Evidence is organized in the locker on a per-pipeline-run basis, that is, every piece of evidence that was collected in a pipeline run is stored next to each other. This organization makes evidence collection easy when you have a pipeline run ID. However, it's difficult to tell which piece of evidence is relevant for an asset, such as evidence that is related to a docker image. This difficulty is because evidence can span across multiple pipeline runs, such as a CI pipeline, a staging CD pipeline, or a production CD pipeline. For more information, see v1 evidence format.
Because of these difficulties, v1
evidence is superseded by v2
.
The v1 evidence collection is the legacy evidence collection. To opt out of v1 evidence collection, see Turning off legacy v1 evidence collection.