feat(scan): support using configuration file at local or remote URL for disabled and specially enabled queries

[mekhanique]

Is your feature request related to a problem? Please describe.

The current method of disabling false positives doesn't scale well and/or opens the door to false negatives (details below). It also does not provide a method of tracking changes to the tools configuration, which is an important thing for a scanner. Many of your competitors products (or competitive OSS projects) support the use of files for this purpose (albeit some are prettier than others in this respect).

False positives
Today a scan must either have an ignore rule in the file being scanned or have a vulnerability UUID excluded on the shell command line. The latter doesn't scale as there is a maximum number of characters allowed on the command line. This will yield a failed scanner execution or have the scanner report on one or more false positives which the user identified.

False negatives
Ignoring a line or block of lines opens the door to issues that can occur, but which aren't found. One example is a vulnerability in an application feature that is dependent upon multiple configuration values (and possibly multiple features) to be ignored. Another vulnerability comes along with a dependent configuration that had to be blocked. It's missed by the scanner, but could've been fixed a different way than commenting out the line. This issue is now a false negative.

Auditing
Changes that impact the security of an application should be documented. All scanners that indicate vulnerabilities should have an identifiable list of false positives or false negatives that are being accounted for, preferably with an associated reason. Having this data in a way that also identifies who makes a change is a best practice from a security perspective. Furthermore it helps team members to maintain and share tribal knowledge around vulnerabilities and misconfigurations that might otherwise be lost. Lastly, tools that enable this practice make life much easier on their consumers.

Describe the solution you'd like

Create support for the use of a JSON based config file (ex: .kics.config.json) who's path is indicated on the command line or through the existence of the file in the directory it is called from. The path should support the use of a file path (possibly supporting a default location if not specified) or a FQDN URL with an optional authorization header. This would allow a user to pull a raw up-to-date file from a private repository on any system (GitHub.com, Github Enterprise, Bitbucket/Stash, Gitlab, etc) helping to ensure auditability of changes while keeping the list access protected (and revokable). It should have a format similar to the one documented below:

File [URL]/.kics.config.json contents example:

{
    "falsePositives": 
    [
        {
	    "queryID": "query ID string",
            "justification": "Justification string",
            "files": 
            [
                {
                    "filePath": "relative path from root repo",
                    "lineNumbers": "string of line number(s) involved"
                }
            ]   
        }
    ],
    "falseNegatives": 
    [
        {
            "queryID": "Query ID string",
            "justification": "Justification string",
            "files": 
            [
                {
                    "filePath":  "relative path from root repo",
                    "lineNumbers": "string of line number(s) involved"
                }
            ]
        }
    ]
}

Describe alternatives you've considered

A workaround where a text file includes a list of query ids could be used in conjunction with a script to build the kics command line using --disable= string. Changes would be audited and, as above, purpose would be identified in the commit / PR comment. However, this does not address the maximum line length at the shell level. It is also sub-optimal as it doesn't provide an easy way of understanding the why without parsing the git log.

Additional context

Thanks for your time and efforts on this project! It's really valuable.
Sorry I cannot implement this myself. My employer does not allow open source contributions on projects that would be used for work purposes.

[franklycaswell]

Along the sames lines as this I'm implementing a 'helper script' during our custom docker build phase that uses a config file global-query-exclusions.yaml that allows for individual or entire 'Platform' of queries to be added to excluded-queries in the kics-config.yaml

global-query-exclusions.yaml

---
platforms:
  terraform/general:
    exclude_all:
      justification: General terraform best practice queries aren't required
  terraform/aws:
    queries:
      IAM Access Analyzer Not Enabled:
        id: e592a0c5-5bdb-414c-9066-5dba7cdea370
        justification: Not something to be checked at IaC level

Example of populated kics-config.yaml

---
exclude-queries:
- a88baa34-e2ad-44ea-ad6f-8cac87bc7c71
- eed37111-720b-4202-93d0-459fbc8c8fce
- ba046402-6a96-4f64-a175-6c7691341f74
- 3a81fc06-566f-492a-91dd-7448e409e2cd
- fc5109bf-01fd-49fb-8bde-4492b543c34a
- 2a153952-2544-4687-bcc9-cc8fea814a9b
libraries-path: /app/bin/assets/libraries/custom
log-file: false
report-formats:
- sarif
- json
type: Terraform
verbose: true

This allows for not only global exceptions to be more easily implemented in bulk ( if a specific Platform's queries aren't desired for example ) but also adds a bit more information to be collected from a rough auditing perspective.