Hello. This blog is for those who want to use LeanSeeks but are hesitant because they don't know if it can be integrated with their company's vulnerability scanner.

Currently, LeanSeeks can perform triage using JSON output from Prisma Cloud and Vuls, but we often receive requests to use data output from other scanners.

As introduced in the previous blog, there is an approach to triage using SBOM, but when using free services such as OSV introduced in the same blog, there may be cases where coverage is not sufficient depending on the target software configuration. It's possible.
(For example, in the case of OSV, an extremely rich amount of OSS vulnerability data is provided, but OSV only targets OSS and does not provide vulnerability information for paid software.)
In cases like this, an effective approach is to triage by converting the vulnerability data output by existing scanners into LeanSeeks format.

The format of LeanSeeks is very simple, with vulnerability information objects arranged flat in an array.

In order to perform triage, it is possible to at least enter only the above “cveId”. This is because LeanSeeks can collaborate with various intelligences on the backend and store data based on the input CVE-ID. However, if for some reason LeanSeeks is unable to obtain information on the backend, triage cannot be performed if only the CVE-ID is available. Even in such cases, triage can be carried out by filling in the above items as much as possible.

An example of a case where LeanSeeks is unable to obtain information from backend intelligence is a relatively new case where a CVE ID has not yet been assigned, but an ID such as GHAS has been assigned, and the state of the exploit is not known. There are cases where
In such cases, by substituting information into as many items as possible in addition to the cveId part, if you have enough information that can be calculated using your own logic within LeanSeeks, you can target the triage.
Note that determining which package is vulnerable is an important factor in actually dealing with vulnerabilities, so regardless of the reasons above, it is recommended to substitute the package name and version as much as possible.

The following is an overview of each data listed above.

• "cveId": (required) CVE ID
• "packageName": name of the package
• "packageVersion": Package version
• "severity": Severity of CVSS
• "cvssScore": CVSS score
• "title": CVE title
• "description": CVE description
• "link": URL to the source of information
• "AV": Attack Vector (attack classification)
• "AC": Attack Complexity (complexity of attack conditions)
• "C": Confidentiality Impact
• "I": Integrity Impact
• "A": Availability Impact
• "hasFix": Whether or not to apply a patch
• "exploit": Information on presence or absence of exploit
• "publicExploits": URL of public exploit
• "published": Publication date and time
• "updated":Updated date and time

There are a large number of vulnerability scanners in the world, ranging from simple ones that can be used for free to professional paid tools, but most of them can output scan results in JSON format or CSV format. It is also possible to obtain it using API, etc.
However, the structure of CSV arrays and JSON varies depending on the tool, so you need to consider how to parse the data according to each format.

However, once the parsing logic is clear, the conversion can be automated using scripts.

By making it a script, you can load the script in the CI build pipeline, replace traditional security criteria with LeanSeeks (SSVC-based) instead of CVSS-based, and use scanners, etc. even when triaging released software. It is also possible to automate triage on a daily basis while re-acquiring the latest vulnerability information.

In cases where such scripts are required, we provide sample scripts that can be used as is when introducing LeanSeeks.
For scanners that are in high demand from users, we will consider importing them directly into LeanSeeks in the future, but we would also like to release conversion scripts that have received many requests on GitHub in the future.

We are considering opportunities to explain actual sample scripts in future blogs, so please look forward to it.