Supported scanners
Types
There are different types of vulnerability scans:
- SCA / Software Composition Analysis: Modern systems are not completely rewritten from scratch, but many basic functions are used as libraries. This applies not only to application code, but in the case of Docker, also to operating system functions and programmes. All these components can have known vulnerabilities that can be exploited by attackers.
- SAST application / Static Application Security Testing: Many problems can be detected in the code through rule-based searches, e.g. injections or weak encryption. Tools exist for all common programming languages.
- SAST infrastructure: Also for Infrastructure as Code (Dockerfile, Helm Charts, Terraform, ...) many problems can be found with rule-based searches before applying the code to set up the infrastructure.
- Secrets: Secrets such as passwords or API keys must not be checked into repositories with the code, and there are tools that search, for example, Git repositories across the entire version history for such secrets.
- DAST / Dynamic Application Security Testing:: This class is black-box security testing where the tests are performed by attacking an application (typically web applications or APIs) from the outside. The tests can be passive, where only anomalies are looked for, or active attacks on the system.
- Cloud infrastructure: The running infrastructure, e.g. a Kubernetes cluster, can also be checked for vulnerabilities both with internal views (tests that run inside the infrastructure) and external views (tests from outside via the internet).
- IAST / Interactive Application Security Testing: IAST works inside an application by instrumenting the code to detect and report issues while the application is running.
Data formats
While every vulnerability scanner writes its own format, there are 2 standardized formats that are implemented by several scanners:
-
CycloneDX: CycloneDX is a Software Bill of Material (SBOM), that contains information about components of a system and their vulnerabilities. It is typically used by SCA scanners.
If the SBOM contains licenses of components, they are imported into SecObserve as well for license management.
-
SARIF: The Static Analysis Results Interchange Format is an OASIS standard which is implemented by a lot of SAST scanners.
This means the CycloneDX
and SARIF
parsers can import data from a variety of vulnerability scanners, while other vulnerability scanners need a dedicated parser for their special data format.
Scanners
These scanners have been tested with SecObserve:
Scanner | Parser | Source |
---|---|---|
SCA | ||
Dependency Track | Dependency Track | API |
Dependency Check | SARIF 1) | File |
Grype | CycloneDX | File |
Trivy | CycloneDX | File |
SAST application | ||
Bandit | SARIF | File |
ESLint | SARIF | File |
Find-Sec-Bugs | SARIF | File |
Semgrep | SARIF | File |
SAST infrastructure | ||
Checkov | SARIF | File |
KICS | SARIF | File |
tfsec | SARIF | File |
Trivy | SARIF | File |
Secrets | ||
Gitleaks | SARIF | File |
Trivy | SARIF | File |
DAST | ||
CryptoLyzer 2) | CryptoLyzer | File |
DrHeader | DrHeader | File |
ZAP | ZAP | File |
Cloud infrastructure | ||
Azure Defender for Cloud 3) | Azure Defender | File |
Prowler 3 | Prowler 3 | File |
Prowler 4 | OCSF (Open Cybersecurity Schema Framework) | File |
Trivy Operator Prometheus | JSON | API |
1) This is the exception to the rule. Even though SARIF is more suited for static code analysis, it works for Dependency Check.
2) The CryptoLyzer parser checks the results (TLS versions, cipher suites, elliptic curves and signature algorithms) against BSI (Bundesamt für Sicherheit in der Informationssicherheit) recommendations.
3) The results of Azure Defender for Cloud have to be exported manually in CSV format from the Azure Portal.
GitHub actions and GitLab CI templates support running vulnerability checks and importing the results into SecObserve via GitHub workflows or GitLab CI pipelines in an efficient way.