Built into the ZeroNorth Docker Image for CI/CD Pipeline is a feature that allows a more extended control of your CI/CD pipeline by having ZeroNorth examine the latest scan results of a related Application to determine if the current CI/CD pipeline should be halted.
Intended Uses
- The Artifact you are scanning is related to another Artifact in the same or another CI/CD pipeline, and you want to check the latest scan results of that other Artifact to optionally halt the pipeline.
- The Artifact you are scanning is related to another Target (could be a Repo, an Artifact, or a Direct/Custom type Target) whose scan results you want to consider to optionally halt the current pipeline.
In either of the cases above, you can utilize another feature of ZeroNorth’s Docker Image for CI/CD. Below is an example Docker command:
[sudo] docker run -e CYBRIC_API_KEY=... -e APPLICATION_ID=<App ID> -e FAIL_ON_HIGH_SEVERITY=Medium zeronorth/integration:latest python checkapp.py
where,
- APPLICATION_ID should be the ID of an Application defined in ZeroNorth. The Application definition should include the current Target and the related Target.
- FAIL_ON_HIGH_SEVERITY should be set to one of: CRITICAL, HIGH, MEDIUM, LOW, INFO
Set up
To use this feature, prepare the following:
- Assumptions:
- You already have a Target and a Policy in ZeroNorth to represent the Artifact in your main CI/CD pipeline.
- You already have a Target and a Policy in ZeroNorth to represent the Artifact whose results you want to check.
- Add a new Application . See Create an Application.
Example
In the below example, we are checking for presence of MEDIUM (or higher) severity Issues in a related application whose ID is specified via the “-e APPLICATION_ID” parameter:
The output shows 6 HIGH Issues, which qualifies for finishing the check with EXIT STATUS of 1, which can be detected by a pipeline to conditionally stop the CI/CD progress.
Caveats
Because the above check is a separate step from the related Artifact scan, the sequence between the scan and the check may matter. Consider the following situation:
Checking a Target’s Results Before the Scan
Assume you have an Artifact type Target “A”. You set up a pipeline that:
- Checks for scan results from the previous scan.
- Scans the build Artifact.
The above sequence may seem beneficial, because you can check for the outstanding Issues before the scan, possibly skipping the build/scan if the outstanding Issues contain things that should prevent the pipeline from progressing. However, this could cause the Catch-22 situation.
Recommendation
To avoid the possibility of the Catch-22 situation described above, perform the check after a scan.