Hi,
I tried to use this plugin but found that the treshold checks (both vulnerabilities and compliance) don't seem to work. I.e. I've set

TL_COMPLIANCE_THRESHOLD=critical
TL_VULNERABILITY_THRESHOLD=critical

scanned na image which doesn't have any critical issues (confirmed that in the Twistlock Console) but still got a failed result from this plugin.

After further investigating it, I think that the logic of checking the tresholds in the entrypoint.sh is not correct. It is based on the risk scores:

COMPLIANCE_RISK_SCORE=$(cat TL_report_$REPORT_NAME.json | jq ".[0].info.complianceRiskScore")
VULNERABILITY_RISK_SCORE=$(cat TL_report_$REPORT_NAME.json | jq ".[0].info.vulnerabilityRiskScore")

which are then compared to some arbitrary treshold values, e.g.:

case $TL_VULNERABILITY_THRESHOLD in
     low)
          TL_VULNERABILITY_THRESHOLD=1
          ;;
     medium)
          TL_VULNERABILITY_THRESHOLD=10
          ;;
     high)
          TL_VULNERABILITY_THRESHOLD=100
          ;;
     critical)
          TL_VULNERABILITY_THRESHOLD=1000
          ;;
     *)
          echo TL_VULNERABILITY_THRESHOLD must be low|medium|high|critical
          ;;
esac

if [ $VULNERABILITY_RISK_SCORE -ge $TL_VULNERABILITY_THRESHOLD ]; then
  err "VULNERABILITY_THRESHOLD ($TL_VULNERABILITY_THRESHOLD) EXEECED => $CVE_VULNERABILITIES_CNT issue(s) found. VULNERABILITY_RISK_SCORE = $VULNERABILITY_RISK_SCORE (lower is better)"
else
  msg "CVEVULNERABILITY CHECK => PASSED"
fi

I had an image which risk score was way more than 1000, but it didn't have any critical vulnerabilities, so I'm not sure where these hardcoded values came from, but they don't seem to be correct.

I think that better way of doing this would be to base that logic on complianceDistribution and vulnerabilityDistribution fields from the Twistlock report as they provide exact values of vulnerabilities for each severity level. Extract from example report:

"complianceDistribution": {
				"critical": 0,
				"high": 1,
				"medium": 0,
				"low": 0,
				"total": 1
			},
"vulnerabilityDistribution": {
				"critical": 0,
				"high": 0,
				"medium": 2,
				"low": 2,
				"total": 4
			}

The README on the slack-notifier plugin is inconsistent in what to use for the environmental variable for the webhook url, it switches between:

• SLACK_WEBHOOK_URL
• SLACK_HOOK_URL
• WEBHOOK_URL

It seems to me that the 'plugin' in this case, is simply a baseline docker image plus sample syntax for how to run a command within it that is otherwise identical to a Freestyle step. All of the work of installing the script in package.json and telling the plugin which command to run is still an exercise for the user. All that's required is a docker image with npm (or the npm client of your choice) and you can do the same thing in a Freestyle pipeline step without any syntax changes.

Wouldn't it be more useful to just have a plugin for running npm-based steps, which provides a codefresh-approved npm environment (which should probably have npm, yarn, and lerna all installed, plus node), and then instead of specifying the entire npm command in the commands list, allow the user to just specify the name of the scripts that should run plus any parameters. The actual npm client can be specified in package.json. The syntax would be more like this:

npm_step:
title: Running something via npm
image: codefresh/npm-tools
token_var: NPM_TOKEN
commands:
- build --production
- prerelease --production
- release

The plugin would then know how to structure the npm commands, including the addition of the npm token via the var that was specified. Otherwise, i don't see much difference between the 'plugin' and a Freestyle step with identical syntax, other than the type of the step.

In my example, I can set my npmClient to be yarn in package.json. And if I use lerna to update versions and push npm packages, I can set up a 'release' script which calls 'yarn run lerna publish.' Even so, it's about the same number of lines of code whether using the plugin or just running a Freestyle step, so there doesn't seem much value in the re-usable component. A naive npm user may not realize how easy it would be to add commands other than release-to-npm to such a step, for example.