Skip to content

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.
  • Application SAST / 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.
  • Infrastructure SAST: 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.
  • 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 Type Source
Dependency Check SARIF 1) SCA API
Dependency Track Dependency Track SCA API
Grype CycloneDX SCA File
Trivy CycloneDX SCA File
Bandit SARIF Application SAST File
ESLint SARIF Application SAST File
Find-Sec-Bugs SARIF Application SAST File
Semgrep SARIF Application SAST File
Checkov SARIF Infrastructure SAST File
KICS SARIF Infrastructure SAST File
tfsec SARIF Infrastructure SAST File
Trivy SARIF Infrastructure SAST File
Gitleaks SARIF Secrets File
Trivy SARIF Secrets File
CryptoLyzer 2) CryptoLyzer DAST File
DrHeader DrHeader DAST File
ZAP ZAP DAST File
Azure Defender for Cloud 3) Azure Defender Cloud infrastructure File
Prowler Prowler Cloud infrastructure File

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.