Preventing Supply Chain Attacks
Supply chain attacks are perpetrated by causing developers to download packages that initiate harmful activities on the developer's PC. This can provide hackers with access to sensitive information and introduce severe risks down-the-line in the development process.
Checkmarx is at the forefront of efforts to provide protection from supply chain attacks.
How We Detect Supply Chain Risks
The Checkmarx SCA scanner identifies packages with a wide range of supply chain risks, and lists those risks in the scan results. Checkmarx SCA identifies supply chain vulnerabilities of the following types:
Reputation - There is reason to suspect the credibility of the owner or contributors of the package, e.g., a newly created user is registered as the package owner.
Reliability - There are irregularities in the naming or maintenance patterns of the package, e.g., Typeosquatting, or Chainjacking.
Behavior - The behaviors of the package are unsafe. The package may be malicious by design or it may inadvertently introduce risks into your project. This category includes packages that exfiltrate info about OSs, user credentials etc.
The following table shows some examples of supply chain risks of each type that are identified by Checkmarx SCA.
Title | Description |
|---|---|
Reputation | |
New User | The owner of this package is a newly created user. |
Protestware | Software that includes functionality which aims to protest or raise an issue - learn more |
Repojacking | Taking over the repository of a legitimate package - learn more |
Account takeover | The compromise of a good maintainers account by an attacker which is then used to spread malicious packages - learn more |
Reliability | |
Dependency Confusion | This package introduces the risk of substituting a package from a public registry in place of a similarly named package in a private registry. For example, it uses private packages for which the namespace is unreserved on the public registry. learn more |
Typosquatting | This package mimics the name of a popular package, inducing users to inadvertently call this package. learn more |
StarJacking | There is a weak link between the package metadata and the referenced Git repository. learn more |
This package is stored in a renamed GitHub repository, making it vulnerable to an attacker taking control of the repo and serving malicious code through the package. | |
Behavior | |
Harmful File Download | This package downloads a harmful file. |
This package was manually inspected by a security researcher and flagged as being malicious by design. | |
Data Exfiltration | This package exfiltrates sensitive information such as stored credentials or computer and operating system details. |
Network Anomaly | This package initiates one of the following anomalous network behaviors:
|
Crypto Miner | This package executes crypto mining software. |
Viewing Supply Chain Risks in the Checkmarx SCA Web Portal
Supply chain risks are shown as a separate group in the Scan Results > Risks tab.
 |
Click on the row of a supply chain risk to open a details page showing detailed info about that risk. On the details page, you can also manage the risk state and add comments.
 |
In addition, when you click on a package with a supply chain risk on the Scan Results > Packages tab, the details page that opens shows gauge widgets representing three risk categories (Reputation, Reliability and Behavior). The scores are given on a scale of 0-10, with 10 indicating the highest level of security.
 |
Creating Supply Chain Policies
Checkmarx SCA Policy Management enables you to apply customized security rules to the open source packages in your Projects. This makes it easy to identify Projects that are non-compliant with your self-defined security policies.
Notice
Learn more about Policy Management.
Checkmarx SCA offers a specialized Policy condition for supply chain risks. You can add a condition specifying that if a supply chain risk of a particular severity level/s is detected in your project, this will trigger a Policy violation. Supply chain conditions can be combined with other conditions to create complex Policy rules. For example, you can create a Policy that is triggered only when a high severity supply chain risk is identified in a package that is not a Dev or Test Dependency.
 |