Software Supply Chain

5 automated security scanners

Software Composition Analysis

Purpose: This scanner analyzes software composition analysis (SCA) practices for a given domain to identify and assess potential vulnerabilities in third-party components used within the organization’s software. It evaluates the presence of SCA tools, their integration with vulnerability management and license compliance, as well as the governance of dependencies and risk assessment of supply chain components.

What It Detects:

SCA Tools Identification: Detection of software composition analysis tools such as Snyk or Dependabot that are used to identify third-party libraries and their vulnerabilities.
Vulnerability Management: The ability to detect and prioritize vulnerabilities in the identified third-party components, including automated alerting mechanisms for critical issues.
License Compliance: Review of license agreements for third-party components to ensure compliance with licensing requirements and legal obligations.
Dependency Governance: Implementation of policies that govern how dependencies are introduced and updated, including approval workflows and update schedules.
Risk Assessment: Evaluation of the reputation and security posture of third-party component providers, as well as their contribution to overall supply chain risk.

Inputs Required:

Domain: The target domain for which the SCA practices are being assessed.
Optional: Additional Domains: For comparative analysis across multiple domains if needed.

Business Impact: Assessing and managing software composition is crucial as third-party components often introduce significant security risks, including known vulnerabilities and compliance issues with licensing terms. Proper SCA helps in mitigating these risks by providing visibility into the technology stack and enabling proactive measures to address identified threats.

Risk Levels:

Critical: The system lacks any form of SCA tool or integration, leading to a complete absence of vulnerability management and license compliance oversight.
High: The presence of SCA tools but with incomplete integration, such as missing pipeline integration for automated scanning or lack of developer environment support for these tools.
Medium: There is partial coverage in SCA practices like vulnerability detection without comprehensive remediation tracking or clear dependency governance policies.
Low: A well-established system with robust SCA practices including tool usage, continuous monitoring, and integrated risk assessment across the supply chain.

Example Findings:

The domain does not utilize any software composition analysis tools, resulting in an inability to detect or manage vulnerabilities from third-party libraries.
While Snyk is identified as a scanning tool, it lacks integration with CI/CD pipelines for automated vulnerability detection and remediation.

Signed Artifact Verification

Purpose: The purpose of this scanner is to analyze and evaluate the signed artifact verification practices for a given domain. It aims to identify the presence of code signing, signature verification, certificate management, attestation processes, and job indicators related to software supply chain security.

What It Detects:

The scanner detects whether the domain uses signing certificates and tools for code signing.
It identifies if there are any verification mechanisms in place within deployment pipelines or automated workflows.
It checks for the presence of certificate issuance, lifecycle management, and transparency processes.
It evaluates the documentation and implementation of SLSA provenance, build attestation, and witness frameworks for cryptographic attestation.
The scanner also assesses job indicators such as security engineering roles focused on supply chain integrity.

Inputs Required:

Domain: The target domain to be analyzed for signed artifact verification practices.

Business Impact: This analysis is crucial as it directly impacts the integrity and security of software products by ensuring that all artifacts are verified and trusted throughout their lifecycle. Poorly implemented or absent signing and verification mechanisms can lead to unauthorized modifications, tampering, and potential data breaches.

Risk Levels:

Critical: No artifact signing or verification controls identified; missing code signing certificates and verification workflows; no protection against tampered or substituted artifacts; critical supply chain integrity risk.
High: Artifact signing present but verification unclear; no signature verification in deployment pipelines; unsigned artifacts may be deployed without detection.
Medium: Code signing implemented but certificate management unclear; no certificate lifecycle or revocation checking documented; compromised or expired certificates may be used.
Low: Comprehensive artifact signing and verification identified; code signing with certificate management and verification enforcement; cryptographic attestation and provenance tracking present.

Example Findings:

The domain does not implement any form of code signing, leading to potential unauthorized modifications of software artifacts.
There is a lack of clear signature verification within the deployment pipeline, which could allow for unsigned or tampered artifacts to be deployed without detection.

Package Repository Security

Purpose: This scanner evaluates the security posture of a software supply chain by analyzing the configuration and practices surrounding package repositories. It aims to identify weaknesses in private registry usage, dependency confusion prevention, access controls, integrity verification, and security scanning capabilities within an organization’s infrastructure.

What It Detects:

Private Registry Usage: Identifies whether a private registry is deployed or if internal hosting of packages is utilized.
Dependency Confusion Prevention: Assesses the effectiveness of preventing dependency confusion through namespace reservation, name verification, and other mitigation strategies.
Access Controls: Evaluates the presence of authentication requirements and role-based access control (RBAC) for managing package repository interactions.
Integrity Verification: Checks for mechanisms that ensure the integrity of packages by validating checksums or signatures.
Security Scanning: Analyzes whether security scans are conducted to detect vulnerabilities, malware, or unauthorized changes in the software supply chain.

Inputs Required:

domain: The target domain whose package repository is being evaluated.

Business Impact: Evaluating and enhancing the security of a software supply chain is crucial as it directly impacts the integrity and confidentiality of digital assets. A robust package repository security framework helps prevent unauthorized access, tampering with critical components, and potential exploitation of vulnerabilities that could lead to significant business disruptions or data breaches.

Risk Levels:

Critical: When no private registry is identified and there are no controls in place to prevent dependency confusion through namespace reservation or other means. This poses a high risk as it allows direct public registry usage without any protection, making the system vulnerable to supply chain attacks.
High: When a private registry is detected but lacks documented access controls (authentication and RBAC). This exposes the organization to risks of unauthorized package publishing and access.
Medium: When there are gaps in integrity verification or security scanning capabilities within the private registry, allowing for potential consumption of compromised packages.
Low: When all aspects of package repository security are well-implemented, including a private registry with robust access controls and comprehensive integrity and security scanning practices.

Example Findings:

The domain example.com does not deploy any private package registry, leaving it vulnerable to public registry usage without protection.
Despite having a private registry, there are no documented authentication mechanisms or RBAC policies in place, exposing the repository to unauthorized access.

Build Pipeline Security

Purpose: This scanner evaluates the security posture of a software supply chain by analyzing the build pipeline for potential vulnerabilities in CI/CD platforms, secret management, artifact integrity, access controls, and dependency security. It aims to identify weaknesses that could lead to unauthorized modifications, credential exposure, or inclusion of vulnerable components in the software delivery process.

What It Detects:

CI/CD Platform Identification: The scanner identifies whether a domain uses common CI/CD platforms like GitHub Actions or Jenkins.
Secret Management and Scanning: It checks for the presence of secret scanning capabilities, rotation policies, secure injection methods, and integration with vault services.
Artifact Integrity: This includes verifying that artifacts are signed and there is evidence of integrity verification through provenance tracking.
Access Controls: The scanner evaluates whether access controls such as multi-factor authentication (MFA), role-based access control (RBAC), code review processes, and branch protection are in place.
Dependency Security: It assesses the presence of software composition analysis (SCA) for identifying vulnerabilities in dependencies and ensuring that dependencies are not compromised through insecure means.

Inputs Required:

Domain: The target domain to be analyzed for build pipeline security.
Optional - Additional Domains: For comparative analysis, additional domains can be provided to compare the security posture across different platforms.

Business Impact: The integrity and security of software supply chains are critical as they facilitate the movement of code from development through deployment and operation. Weaknesses in these areas can lead to unauthorized access, data breaches, and system vulnerabilities that could compromise sensitive information or disrupt business operations.

Risk Levels:

Critical: The scanner identifies a CI/CD platform without clear security controls or documented practices for secret management and artifact integrity. This risk level is assigned if the findings indicate significant exposure to supply chain attacks through compromised build pipelines.
High: The scanner detects missing or insufficiently enforced access controls, such as lack of code review processes or branch protection, which could lead to unauthorized modifications of critical components in the software delivery pipeline.
Medium: There is a gap in security practices like secret scanning, artifact signing, or dependency vulnerability scanning that may expose sensitive information or introduce vulnerabilities into the system.
Low: The build pipeline demonstrates strong security controls including MFA for access, RBAC implementation, and comprehensive code review processes with branch protection. Dependency management also shows proactive measures to identify and mitigate potential threats from compromised dependencies.
Info: Informational findings that do not directly impact security but highlight areas for improvement or best practices in software development lifecycle (SDLC) procedures.

Example Findings:

“CI/CD platform identified but no documentation of secret management practices.”
“Lack of artifact signing and integrity verification, posing a risk through potential supply chain attacks.”
“No implementation of dependency vulnerability scanning, leaving the software vulnerable to known threats in dependencies.”

Container Image Security

Purpose: The purpose of this scanner is to analyze container image security for a given domain by evaluating various aspects such as base image practices, vulnerability scanning, image signing, secrets management, and hardening practices. This helps in identifying potential vulnerabilities and ensuring secure software supply chain practices.

What It Detects:

Base Image Practices: Detection of the use of minimal images, distroless usage, official images, base update policy, and detection of deprecated images.
Vulnerability Scanning: Identification of automated scanning, tools used for scanning (e.g., Trivy, Snyk), enforcement of scan results, continuous scanning, and threshold policies.
Image Signing: Implementation of image signing using tools like Cosign and verification at deployment to ensure integrity.
Secrets Management: Detection of secret scanning, runtime injection awareness, and documentation of best practices for managing secrets within images.
Hardening Practices: Configuration of non-root user, read-only filesystem, minimal packages, security context, and capability restrictions to reduce attack surfaces.

Inputs Required:

Domain: The target domain for the container image security assessment.

Business Impact: Ensuring secure container images is crucial as it directly impacts application integrity and data protection. Poorly secured containers can lead to unauthorized access, data breaches, and other severe consequences. This scanner helps in identifying and mitigating such risks by enforcing best practices in image management and hardening.

Risk Levels:

Critical: No container image security controls identified; missing vulnerability scanning and image signing; no verification of image integrity or security; critical supply chain attack risk through compromised images.
High: Vulnerability scanning present but no enforcement; vulnerable images may be deployed without blocking; no threshold policies or deployment prevention.
Medium: Vulnerability scanning present but secrets management unclear; no secret scanning or runtime injection documented; hardcoded credentials may exist in image layers.
Low: Comprehensive container image security identified; vulnerability scanning, image signing, and hardening practices are present; secrets management and base image practices are documented.

Example Findings:

A domain uses a deprecated image that poses potential risks due to lack of support and increased vulnerabilities.
The automated scanning tool used does not enforce scan results, leading to unaddressed security flaws in the container images.