secureCodeBox
secureCodeBox copied to clipboard
ADR-0014: Metrics Collection
First draft for the metrics collection ADR. Discussions welcome.
MegaLinter status: :warning: WARNING
| Descriptor | Linter | Files | Fixed | Errors | Elapsed time |
|---|---|---|---|---|---|
| ✅ ACTION | actionlint | 2 | 0 | 0.04s | |
| :warning: BASH | bash-exec | 14 | 4 | 0.06s | |
| :warning: BASH | shellcheck | 14 | 18 | 0.2s | |
| :warning: BASH | shfmt | 14 | 14 | 0.01s | |
| ✅ DOCKERFILE | dockerfilelint | 1 | 0 | 0.45s | |
| ✅ DOCKERFILE | hadolint | 1 | 0 | 0.06s | |
| ✅ GIT | git_diff | yes | no | 0.15s | |
| :warning: GO | golangci-lint | 5 | 5 | 11.41s | |
| :warning: GO | revive | 5 | 2 | 0.07s | |
| :warning: JAVA | checkstyle | 2 | 2 | 5.18s | |
| :warning: JAVASCRIPT | eslint | 5 | 1 | 0.73s | |
| ✅ JSON | eslint-plugin-jsonc | 1 | 0 | 1.81s | |
| ✅ JSON | jsonlint | 1 | 0 | 0.35s | |
| :warning: JSON | prettier | 1 | 1 | 0.92s | |
| ✅ JSON | v8r | 1 | 0 | 1.5s | |
| :warning: PYTHON | bandit | 36 | 24 | 1.0s | |
| :warning: PYTHON | black | 36 | 1 | 4.16s | |
| :warning: PYTHON | flake8 | 36 | 872 | 1.21s | |
| :warning: PYTHON | isort | 36 | 24 | 0.24s | |
| :warning: PYTHON | pylint | 36 | 72 | 11.56s | |
| :warning: SPELL | misspell | 284 | 1 | 2.18s | |
| :warning: TYPESCRIPT | eslint | 1 | 1 | 0.55s | |
| :warning: YAML | prettier | 219 | 1 | 12.98s | |
| :warning: YAML | v8r | 219 | 5 | 166.01s | |
| :warning: YAML | yamllint | 219 | 1 | 27.39s |
See errors details in artifact MegaLinter reports on CI Job page
Set VALIDATE_ALL_CODEBASE: true in mega-linter.yml to validate all sources, not only the diff
awesome 👍
A couple of notes while going over the adr:
- Parsers don't save the finding into a file in the filesystems but return it directly as a function return value to the parser-sdk which then converts these into json and uploads them to s3. The points you made are still valid in that scenario :)
- A lot of scanners, including ZAP (i think) don't put this kind of information into their result file. So the parser won't always have the information available to properly gather these metrics. I think we could come up with additions to this pr to allow scanners to report additional metrics via the lurker, e.g. by using an additional (optional) file as suggested for the parser. This could then be directly generated by a scanner (e.g. zap-advanced) or produced by a special SCB specific sidecar collecting these metrics and writing them.
LGTM
Incorporated the feedback from @J12934. We can now review and merge this as a WIP ADR so we can share it with others to get their feedback on it.
Since it's a DRAFT we can merge it.