anchore-twistlock-results (Twistlock) - Stage Failure

Overview

Below are common causes of Twistlock failures, along with recommended solutions.

False Positives

Problem

The Twistlock finding is a false positive.

Solution

Open a Twistlock Exception Request to whitelist the finding. You must provide evidence that it is a false positive.

Unresolvable Findings

Problem

The finding is a true positive, but there is no current fix, or the product team needs time to address the finding.

Solution

1. Make a best-effort attempt to fix it. For example, update dependencies that have vulnerabilities to newer versions.
2. If the vulnerability is absolutely not resolvable, request a temporary exception by opening a Pipeline Exception Request . You must provide evidence of solutions attempted. Dependencies can be forced to specific versions or replaced with alternatives.

NOTE

Temporary exceptions are usually granted for 90 days. The pipeline will be blocked after the exception period.

Twistlock Base Image Issues

Problem

There is one or more Twistlock findings that do not arise from an application's source code. For instance, the CVE link looks like the following:

'link': 'https://access.redhat.com/security/cve/CVE-XXXX-XXXXX'

This means the vulnerabilities are likely operating system-based, coming from the base image.

Solution

All findings from Iron Bank base images can and should be excluded. Submit a Pipeline Exception Request .

Notes

• In some instances, the base image exclusions are not being applied because the Twistlock server is in the process of retrieving the latest scans for all images. If you have opened a ticket, please continue to re-run your Twistlock scan job while waiting for an MDO engineer to pick up your issue. Additionally, please check the Iron Bank for the latest image before opening a ticket for base image exclusions.

• Twistlock caps Iron Bank images at 2 tags per image. If your image is out of date by more than 2 tags, then the base image exclusions will no longer apply.

• Since CVEs are added/updated continuously, it is possible that a base image will have new CVEs that VAT is not yet filtering out. VAT is updated nightly, so in this circumstance, re-running the anchore-twistlock-results (Twistlock) may resolve the findings

Private Key File(s) Found

Problem

Twistlock has detected one or more private keys.

---

{'compliance': [{'cause': 'Found: '
'/app/node_modules/public-encrypt/test/test_key.pem, '
'/app/node_modules/public-encrypt/test/test_rsa_privkey.pem, '
'/app/node_modules/public-encrypt/test/test_rsa_privkey_encrypted.pem',

---

Solution

Though this finding is a false positive, MDO cannot grant an exception due to a Twistlock limitation. The only way to resolve it is to manually remove the files from the image via the Dockerfile using RUN rm -f <path to keys>.

Example (using the above finding):

RUN rm -f /app/node_modules/public-encrypt/test/test_key.pem \
  /app/node_modules/public-encrypt/test/test_rsa_privkey.pem \
  /app/node_modules/public-encrypt/test/test_rsa_privkey_encrypted.pem

You can also check in a .dockerignore file in the root of your project with the following:

---

**/*.key
**/*.pem

---

400: No Registry Settings Specification Apply

Problem

The application has not been added to Twistlock.

__main__.InvalidTwistlockQuery: ('Request error, status code:', 400, '{"err":"no registry settings specification apply"}')

Solution

The container registry has not been added to Twistlock. Submit a Pipeline Issues ticket .

All Other Errors

Open a Pipeline Issues ticket .