Any replacements for the inline scanning script?

[Atharex]

What would you like to be added: Having a CI script like the previous inline_scan one, that performs a Grype scan and uploads scan results to Anchore engine

Why is this needed: To be able to use policy evaluation on the Grype scan results. CI scanning only with Grype handles vulnerabilities, but prevents usage of custom policies.

[josesa-xx]

It seems to me the only thing missing is grype capability of handling Anchore Policy Bundle files the same way inline_scan did.

It would be nice if grype itself would be able to handle this directly accepting as input the policy bundle file, something like this:

grype --output table --file all_issues.txt --policy policy_bundle.json --only-fixed --fail-on High sbom:image-sbom.json

If the policy already dictates that only "High" or "Critical" issues are to be "Stopped" and also that "only fixed" issues are to be considered the usage could be simply:

grype --output table --file all_issues.txt --policy policy_bundle.json sbom:image-sbom.json

Since grype doesn't have the same functionality as inline_scan to make use of Anchore Enterprise policy bundle, I've created some bash script wrapping this functionality as indicated below.

Assuming we have a file 'all_issues.txt' generated by grype with all vulnerabilties with fix available:

# scan image and create SBOM file
syft --output json --file image-sbom.json ${IMAGE_TO_SCAN}

# uses SBOM file to detect vulnerabities and output to a text file "all_issues.txt"
grype --output table --file all_issues.txt --only-fixed sbom:image-sbom.json

Assuming file 'policy_bundle.json' is downloaded from Anchore Server as follows:

curl --fail -o policy.raw -sS -Lk -u "username:password" \
"https://anchore.server.name.fqdn/v1/policies/12345678-90abc-def1-2345-67890abcef12" && {
  jq ".[].policybundle" policy.raw > policy_bundle.json
}

We could determine which issues are excluded from the allowed lists:

# filter allowed vulnerabilities
cp all_issues.txt breaking_issues.txt
head -1 all_issues.txt > allowed_issues.txt
cat policy_bundle.json | jq -r ".whitelists[]|.items[]|[.trigger_id,.expires_on]|@sh" |\
while read line; do
  # line="'CVE-2021-35565+java-1.8.0-openjdk*' '2021-11-27T14:52:56.000Z'"
  echo $line
  eval set -- ${line}
  trigger=$1
  expires=$2
  # skip skip expired exclusions
  if [[ "${expires}" != "null" ]]; then
    exp_sec=$(date -d "${expires}" +%s)
    now_sec=$(date +%s)
    [[ ${exp_sec} > ${now_sec} ]] || continue
  fi
  vulnerability=${trigger%+*}
  package=${trigger#*+}
  grep ${vulnerability} breaking_issues.txt | grep ${package} | tee -a allowed_issues.txt
done

# remove from scan allowed exclusions
tail -n+2 allowed_issues.txt |\
while read line; do
  sed -i "/${line}/d" breaking_issues.txt
done

Assuming that only "High" or "Critical" issues should be considered we could split the remaining issues into ignored and breaking lists:

# consider only HIGH or Critical issues
SCAN_THRESHOLD="High|Critical"
egrep -v -i "${SCAN_THRESHOLD}" breaking_issues.txt > ignored_issues.txt
egrep -i "^NAME|${SCAN_THRESHOLD}" breaking_issues.txt > _tmp
mv _tmp breaking_issues.txt

# return exit code base on number of breaking issues found
issues_count=$(egrep -i "${SCAN_THRESHOLD}" breaking_issues.txt | wc -l)
exit ${issues_count}

[Atharex]

It seems to me the only thing missing is grype capability of handling Anchore Policy Bundle files the same way inline_scan did.

Yes

It would be nice if grype itself would be able to handle this directly accepting as input the policy bundle file, something like this:

grype --output table --file all_issues.txt --policy policy_bundle.json --only-fixed --fail-on High sbom:image-sbom.json

That would be one alternative, but I guess it would mean copying the whole anchore engine functionality into this tool?

If the policy already dictates that only "High" or "Critical" issues are to be "Stopped" and also that "only fixed" issues are to be considered the usage could be simply:

grype --output table --file all_issues.txt --policy policy_bundle.json sbom:image-sbom.json

Since grype doesn't have the same functionality as inline_scan to make use of Anchore Enterprise policy bundle, I've created some bash script wrapping this functionality as indicated below.

Thanks for the script, but it is not something I want. I realize there is always a way to script around the problem, but I would prefer to use the existing functionality in Anchore Engine to do policy evaluations (especially because of auditability)

[josesa-xx]

I just provided the bash script as simple description how to "implement" the functionality, hoping someone can pick on it and implement inside grype code.

[luhring]

Hi all — thanks for the issue. Just as a heads up, we're not planning to port all of Anchore Engine's functionality into Grype. Our vision for Grype is that its primary responsibility is to surface data about a vulnerability assessment, not act on that assessment. We include minimal additional capabilities for convenience in very simple workflows (e.g. severity gating and ignore rules). But for full policy support, you'd need to use Anchore Engine or Anchore Enterprise (or develop a custom solution like has been mentioned above!).

cc: @nwl

[zhill]

Reading the ask, it does sound like the main ask is filtering on the vuln results. The gating, as you mention @luhring and also possibly the go-template capabilities of Grype to filter and present items of interest only (e.g. with fixes, or in a specific domain) might be accomplished with those using templates folks could share and/or embed in CI jobs.

@josesa-xx and @Atharex is it accurate to conclude that vuln filtering on various match parameters (severity, fix availability, namespace, etc) is what you have used in engine that you want to also accomplish with Grype?

[Atharex]

My use case here are custom policies, like presented here (https://engine.anchore.io/docs/general/concepts/policy/policy_checks/). I use more gates than just vulnerabilities (dockerfile, files, packages, etc. ), which I would like to keep in my pipeline. For this case I rely on the inline_scan script, (which scans locally built docker containers and sends results to my Anchore Engine service).

So the inline_scan script currently fulfills my needs for uploading the results, where I can separately do evaluation with custom policies and my question was if Grype would be integrated in that script to retain the functionalities? Preferably if Grype could send scanning results to an existing Anchore Engine service where I can separately in the pipeline trigger the policy evaluation step?

[josesa-xx]

In my case I wanted to make use of the same policy defined in anchore enterprise server (that I can download into a file policy_bundle.json) so I could use it in "offline scan" with grype the same way i used to do with inline_scan.

In our case the anchore enterprise server is pretty much overloaded so scans can be pretty slow, while running offline with grype the scan is much faster and independent of the enterprise server.

The only thing missing is the "gating" functionality provided by the defined policy (that includes both rules and exceptions). I would like to keep centralized these policy definitions automatically used in anchore enterprise scans, while re-using them also for offline scans (with grype).

If you have better alternative to achieve this with grype, please let me know.

[nwl]

Hi @josesa-xx - this functionality is designed to be provided by AnchoreCTL which is part of the Anchore product. Grype is a pure OSS project and is not designed to have Anchore specific functions with it. Please contact our support team to discuss further. Thanks!

[luhring]

I'm going to close this for now: it sounds like the general question "Any replacements for the inline scanning script?" has been answered. In short, Grype is the current OSS solution for vulnerability-focused workflows. For any more complex policy or Anchore Enterprise specific logic, users should check out AnchoreCTL and get in touch Anchore customer support for further support questions.