Vulnerability Management¶

This section aims to explain how Vulcan manages vulnerabilities.

Although Vulcan is not primarily a vulnerability manager, it provides some vulnerability management functionality primarily designed to automate the process of detecting the presence and the resolution of vulnerabilities. However, it supports some user intervention such as flagging false positives. For more complex vulnerability management requirements, we currently recommend relying on the Vulcan API to fetch vulnerability information and use an external platform (e.g. a ticketing system) to suit your needs.

Entities¶

This section descrives the most relevant Vulcan entities related to vulnerability management.

Affected Resource¶

Although in Vulcan users only manage assets (i.e. targets), vulnerabilities are found and stored in relation to specific resources in a target. Here are some examples:

Hostname: the specific port and protocol where the vulnerability was detected.
AWSAccount: the specific S3 bucket that allows public access.
DockerImage: the specific package and version that is vulnerable.
GitRepository: the specific file where a secret was found.

Different checks and asset types will use different resources as "affected resources", which will always be stored in relation to the target where they were found.

Besides providing more information to the users about where the vulnerability was found, associating vulnerabilities to the specific affected resources allows Vulcan to accurately represent multiple instances of the same vulnerability in the same target in order to keep track of more specific metrics and allow users to flag only some of them as false positive.

Issue¶

The generic instance of a vulnerability. When Vulcan detects a vulnerability for the first time an issue will be created containing the generic description and information about the vulnerability. An example of an issue would be Outdated Packages in Docker Image with its generic summary, description and recommendations.

Finding¶

An instance of an issue as detected in a specific affected resource. This entity contains more detailed information about what exactly has been found in the affected resource and can include relevant evidence, steps to reproduce in the target... Most importantly, a finding contains the state of that vulnerability in the specific affected resource, including the status (OPEN, FIXED, FALSE_POSITIVE or EXPIRED) and the age of the vulnerability among other data.

An example would be an instace of Outdated Packages in Docker Image for the target registry.hub.docker.com/organisation/image:latest, where the affected resource is the openjdk8-jre:8.252.09-r0 package. The finding would include which specific vulnerabilities affect this package version, which severity each one has, which CWE categories they correspond to and the minimum package version that resolves the vulnerabilities. This specific finding would also include, for example, details with a command that can be run locally to check if the fix has been implemented correctly before uploading a new version of that specific Docker image.

Finding States¶

Open & Fixed¶

A finding only exists if an instance of an issue has been found in a resource of a scanned target. Once this happens, the finding will be in OPEN status. From there, it will be automatically marked as FIXED when the target is scanned again with the same check and the finding is not found.

Expired¶

If a target is not scanned again with the same check after 90 days, the finding will be automatically marked as EXPIRED. This state exists due to the impossibility of veryfing that the finding has in fact been fixed. This happens, for example, when an asset becomes unreachable or when a check returns inconclusive results or is disabled altogether.

False Positive¶

False positives are flagged manually by the user using the Vulcan API or the UI. When a finding is flagged as false positive its state will automatically change to FALSE_POSITIVE. However, it may be automatically marked as OPEN if the fingerprint of the finding changes. The fingerprint is a unique identifier of the relevant characteristics of the finding that is calculated using different parameters for each check. For example, a check may include the list of relevant CVE as part of the fingerprint, so that when a new CVE is found for the same vulnerability in the same affected resource, the fingerprint will change. This ensures that flagging a finding as false positive does not prevent users from being reported when a vulnerability of the same class but with significantly different characteristics is found again in the same affected resource.

graph LR
  A[Scan] --> B{Finding found?};
  B --> |Yes| H{Flagged false positive?}
  H --> |Yes| I{Fingerprint changed?}
  I --> |No| J(FALSE_POSITIVE)
  J --> K{User re-opens?}
  K --> |No| G
  K --> |Yes| C
  I --> |Yes| C
  H --> |No| C(OPEN);
  B --> |No| D(FIXED);
  B --> |Inconclusive, unreachable...| E{Did 90 days pass?};
  E --> |Yes| F(EXPIRED)
  E --> |No| G[Wait for next scan..]
  C --> G
  D --> G
  F --> G
  G --> A