Deployment risks
Software deployment plays a crucial role in delivering new features and updates to your users. However, with the increasing complexity of software systems, there are inherent risks that you must address to ensure the security, integrity, and privacy of your products. Understanding and mitigating these deployment risks is essential to protect both your users and your organization.
This article covers deployment risk categories that may be identified in your software during a Threat detection scan and their significance in improving your software supply chain security. Refer to your DigiCert® Software Trust Manager Threat detection reports to identify the location, description, and solution of the deployment risks identified in your software.
Categories
Five types of deployment risks may be identified during your software scan:
Threats
Threats encompass a wide range of security risks and vulnerabilities that can compromise the safety and reliability of software packages. These threats can include:
Malicious code
Malicious code or software components intentionally designed to harm or compromise the software. This includes malware, viruses, and other harmful programs.
Suspicious components
Suspicious software elements that may not be clearly malicious but exhibit behaviors or characteristics that raise concerns about their security.
Software supply chain attacks
Threats originating from vulnerabilities or malicious actions within the software supply chain, including open source dependencies and external resources.
Code tampering
Unauthorized alterations to the codebase that can introduce vulnerabilities, backdoors, or other security risks.
Hidden malware
Techniques where malware is concealed within files, documents, or images to evade detection.
Behavioral anomalies
Unusual or unexpected behaviors in software components that may indicate potential security issues.
Signatures
Digital signatures are electronic stamps of authenticity used to verify the integrity and origin of software packages. These signatures are created using digital certificates issued by Certificate Authorities (CAs) and serve as proof that the software has not been tampered with and originates from a trusted source.
Deployment risks related to digital signatures focus on ensuring the proper use and validity of these signatures, alerting you to issues like:
Certificate misuse
Certificate tampering
Incomplete certificate metadata
Expired certificates
Revoked certificates
Vulnerabilities
Vulnerabilities refer to weaknesses or flaws within a software package that can potentially be exploited by malicious actors to compromise the security and functionality of the software, as well as gain unauthorized access to systems or sensitive data.
Deployment risks related to vulnerabilities identify and address Common Vulnerabilities and Exposures (CVEs) during during the threat detection scan, aiming to prevent the exploitation of known vulnerabilities and reduce the risk of security breaches. This deployment risk category prioritizes vulnerabilities based on factors such as severity, patch mandates, malware exploitation, and active exploitation. These vulnerabilities may include issues like:
Misconfigurations
Outdated software
Remote code execution
Zero-day vulnerabilities
Nota
Zero-day vulnerabilities are undisclosed and unpatched software security flaws that are exploited by malicious actors before the software vendor becomes aware of them and has had zero days to create and distribute a fix or patch. To mitigate the risks associated with zero-day vulnerabilities, consider implementing strong cybersecurity practices, regularly update software and systems, and consider using security solutions that can detect and defend against unknown threats.
Mitigations
Mitigations refer to a set of strategies and practices aimed at reducing the risk of security vulnerabilities and minimizing the potential impact of cyberattacks. Deployment risks related to mitigation are designed to detect security gaps and weaknesses in software development practices, with a focus on preventing these vulnerabilities from being exploited by malicious actors. These policies encompass a range of measures, including secure coding practices, updated toolchains, and the implementation of security features like Address Space Layout Randomization (ASLR) and Data Execution Prevention (DEP). These mitigations may include issues like:
Risks
Identify and block potential threats or malicious activities within your software systems to reduce the likelihood of exploitation.
Insufficient security measures
Mitigation involving security practices such as code hardening, ASLR, DEP, and stack canaries to fortify software against attacks.
Unsecure coding practices
Mitigations related to secure coding practices, clean code, and reliable third-party components are essential elements of mitigations to ensure the development of secure software.
Misconfigurations
Mitigation strategies for adequate toolchain configuration and the use of up-to-date tools.
Absence of memory-safe coding
Mitigations help developers write more reliable and secure code by reducing the surface area for memory-related attacks.
Unenforced policies
Mitigation provide guidance and advice on resolving security gaps, enabling development teams to address identified issues effectively.
Secrets
Secrets are confidential and sensitive pieces of information used to access services or authenticate users. Detecting and safeguarding these secrets is crucial because their exposure can pose significant security risks. These deployment risks prevent the inadvertent leakage of these secrets in software packages caused by inadequate credential management practices, especially in complex CI/CD environments or modern GitOps and Configuration-as-Code practices. Leaked secrets can serve as a gateway for malicious actors to access critical infrastructure, confidential data, and even deploy malware.
These can include:
Service access credentials
Private keys
Tokens
Certificates
API keys
Other artifacts
Sugerencia
Not all secrets are equally harmful. Some may be placeholders for testing purposes or canary tokens intentionally placed to monitor external credential usage. Therefore, it's essential to distinguish between genuinely sensitive secrets and harmless placeholders.
Container
Containers detects issues in container images that are susceptible to attacks or security breaches and supports the following formats: Docker, Open Container Initiative (OCI) and Linux Containers (LXD).
Deployment risks categorized as Container may identify:
Built-in validation rules that are violated.
Exposed insecure ports.
Lack (or abundance) of defined instructions.
Unnecessary administrative privileges in container image configuration files.
Deployment risk priorities
Familiarize yourself with the following deployment risk priorities:
Priority | Description | Status | Recommendation |
|---|---|---|---|
P0 | This issue can result in a full outage or affect a critical function of the product. | Fail | Resolve immediately with as many resources as required. |
P1 | This issue significantly affects the security of the software and impacts the processes it supports. | Pass | Resolve quickly. |
P2 | This issue affects multiple users and requires little or no user interaction to trigger. | Pass | Resolve in a reasonable timescale. |
P3 | This issue affects singular users and requires interaction or significant prerequisites to trigger. | Pass | Resolve at your convenience to improve your software. |
P4 | This issue is informational and a non-exploitable vulnerability that are generally deemed an acceptable business risk to the customer. | Pass | Resolve eventually to improve your software. |
Sugerencia
Only critical (P0) risks will result in a Fail status. All other risks (P1-P4) found in your software will be displayed with a Pass status.
Recommended procedure:
Review and resolve all P0 deployment risks.
Review P1-P4 deployment risks even though they show a Pass status and decide if you want to resolve or accept the risks associated with the vulnerability.
Set your deployment risk threshold
Setting your risk threshold for ReversingLabs deployment risks detected in your software during a scan filters your P0 security events and ensures that you can allocate resources effectively to address the most significant threats first. ReversingLabs levels are a way to control the Threat detection scan status for P0 issues. You can adjust your risk threshold to align with your changing risk landscape and evolving security strategies. Consider finding a balance between being overly cautious and missing potentially significant threats, or being too permissive and exposing your organization to unnecessary risks.
Deployment risk levels
Deployment risk levels are predefined sets of policy controls that help you gradually improve your software security. Select a P0 level and if your threat detection scan satisfies all criteria for a specific level, your Threat detection scan status results in a PASS status.
To set your deployment risk level:
Sign in to DigiCert ONE.
Select the Manager menu (top right) > Software Trust.
Navigate to: Account > Account settings.
Select the edit icon.
Scroll down to Deployment risk level.
Select one of the following P0 levels:
Levels
Description
L0
Selecting this option disables RL levels and uses the default L5 scanning criteria.
L1
Selecting this option is suitable for CI/CD. The Threat detection scan will only fail under the most extreme conditions such as detection of:
Malware
Signature tampering
Leaked source code
Unencrypted keys
Build compromise
L2
The Threat detection scan will fail under the conditions of L1, as well as:
Riskware applications
Signing abuses
Private key leaks
CVE patching mandates
L3
Selecting this option is suitable for automated software build process that occurs on a daily basis because it will catch the most severe issues prior to release. The Threat detection scan will fail under the conditions of L1, L2, as well as:
Unsafe loading practices
Signature coverage gaps
Embedded private keys
Malware exploited CVEs
L4
Threat detection scan will fail under the conditions of L1, L2, L3, as well as:
Code loading abuses
Revoked code signatures
Depreciated code signing
Actively exploited CVEs
L5 (default)
Selecting this option is recommended for software releases because it is the most secure level. Threat detection scan will fail under the conditions of L1, L2, L3, L4, as well as:
Executable code packers
Self-modifying executables
Critical severity CVEs
Select Update settings.