SCA Module

SCA stands for Source Composition Analysis, and is one of the most important skims checks. All major package managers are supported and analyzed using this methodology.

In order to find vulnerable dependencies, the following three-step procedure is used:

• Searching and querying official vulnerability reports.
• Storing the important information of the reports in a S3 bucket. (The S3 bucket is public and can be used for cases external to the organization)
• Comparing all of this information to the dependencies configured in a client repository.

Scheduler

A scheduler (skims_update_sca_table) was created to fetch reports from multiple sources and store them in our S3 bucket for the SCA module to use.

Each advisory has the following attributes:

• associated_advisory: Advisory id obtained from the source.
• package_name
• package_manager
• vulnerable_version: Vulnerable versions or ranges in semver format.
• severity: CVSS v3.* Base Metrics
• source
• created_at: Automatically generated creation date
• modified_at: Automatically generated update date
• cwe ids: CWE IDs uniquely identify software weaknesses and vulnerabilities for classification and prioritization purposes.

This scheduler runs every day at 5 am Colombian time.

Sometimes, a report comes of a wrong advisory in one of the sources that the scheduler uses. In order to fix these errors and keep our promise of zero FP, we generally have two options:

1. Fix the info directly on the source repo by creating an issue or a MR. Since these public sources are maintained by a large community of OS contributors, they are generally fast in fixing the mistake.
2. If it is not possible to fix the source, a manual report can be created.

Manual Reports

Manual reports will have priority over those generated by the scheduler, so they can be used to:

• Add additional advisories that are not present in our supported sources.
• Fix advisories generated by the scheduler that contain incorrect information.

How to create Manual Reports

In the universe repo, there is a folder storing all of our manual reports.

This folder contains json files named using the advisory id and containing all the relevant information about the advisory.

Namely, a manual advisory has to contain the following attributes:

• type: Either PATCH or NEW.
• id: the id for the advisory. A PATCH advisory HAS to have the same id as an existing advisory in our sources.
• package_name
• package_manager
• vulnerable_version
• sources: A list containing links to info about the advisory
• severity (Required only for NEW advisories)
• cwe_ids (Required only for NEW advisories)

If you want to add a NEW advisory or PATCH an existing one, you simply create the file using the correct structure and add it to the repository using a MR.

Next time the scheduler runs, the advisory will be added to the S3 Bucket.