shigupt202/local-container-scan

local-container-scan

local-container-scan's Issues

Check run name

Is there a way to add container-scan/<image-name> to the check name instead?

Parse logs

In case of this, we need to figure out the reason and mount it to the errors section for the action perhaps? Cause if we make it silent/move it to the job (on service side) is there any other way to bring up these details?

Whitelisted vulnerabilities for CIS checks are shown on check run page

Dockle shows all the vulnerabilities in the output logs, even the ones which are whitelisted (The whitelisted vulnerabilities are marked with level "IGNORE"). However, in the code we are simply parsing through all the vulnerabilities without checking the level, and that's why we see the whitelisted vulnerabilities in the check-run description page.

Whitelist file path and naming.

It seems that other tools are keeping their configs in root folder under .<toolname> directory.
eg. .circleci, .vscode, .dependabot.

• We should stick to this convention, i.e. .containerscan in root directory should contain the whitelist file.
• That said, should we think of a better name or container scan is good to go?

@pingvishal-msft @ammohant - thoughts?

Check run improvements.

1. Make text in the check run more meaningful. Refer to the comments in pull request #6
2. Review the texts used

---

---

3. Should we display the detailed error in case of failure while scanning, or its right place is only in logs?

---

---

Lacking consistency in details page

One is surrounded with quotes and the other isn't. One is in CAPs and one is in Lower

Make Scan calls Silent

This shouldn't show up in logs, right? Given that we don't want to display CVE logs, shouldn't we consider keeping the whole scan as a blackbox in logs?

In Trivy output, there are duplicate CVE's.

I believe Trivy reports vulnerability along with different packages. That's why there are repetitions.

So, if we are not adding packages as a part of check run details, we should filter out the duplicates.
For the logs, we should do the same.

Add README.md

Add a README file for explaining the usage and assumptions

SPIKE: Test the hard limits of check run details

Items for next iteration

1. Currently, the whitelist file is expected at a particular path in the repo with name as whitelist.yaml. This means if the user gives whitelist.yml as the name of the file, it would be ignored.

2. The action puts the .dockleignore file at the root of the repo. Try to put it in container scan folder and give cwd as an option in ToolRunner.

3. Output is not set currently.

Fix the empty section in details

Either don't print the Common Vulnerabilities section in the details page; or print None found or something similar when there are none found.

Call the section Vulnerabilities instead

Displaying Licenses in logs

Trivy

Dockle

We should remove this perhaps?