Complete Guide to Supply Chain Attack Countermeasures: SBOM Implementation and CI/CD Security Enhancement

What Are Supply Chain Attacks? From Basics to Latest Trends

In recent years, software development has become an era where it cannot function without relying on external libraries and open-source components. However, this deepening dependency simultaneously creates new security risks. This is the “supply chain attack.”

A supply chain attack refers to a method used to indirectly attack downstream organizations or users who are not directly targeted within the software supply chain (the flow of development, distribution, and updates). Specifically, malicious code is injected into development tools, libraries, package repositories, CI/CD pipelines, and even the update mechanisms themselves, spreading malware through trusted channels.

Recent Major Supply Chain Attack Incidents

SolarWinds Orion Incident (2020) Attackers compromised the build process of the company’s network management software “Orion,” embedding a backdoor into the update package. Approximately 18,000 organizations were infected, including U.S. government agencies. This incident became a turning point in making the world aware of the horrors of supply chain attacks.

Codecov Bash Uploader Incident (2021) The shell script for the code coverage tool “Codecov” was tampered with, resulting in CI/CD environment variables and credentials being sent to attackers for about two months. Sensitive information from many development organizations was leaked.

Log4Shell (December 2021) A vulnerability in Apache Log4j was discovered, sending shockwaves through the entire Java ecosystem. This is a classic example of “component dependency risk,” where a vulnerability in a widely used component affects a vast number of systems.

xz Utils Backdoor Incident (2024) Malicious code was intentionally introduced into xz Utils, creating a serious backdoor affecting sshd. It drew attention as a “social engineering” type of supply chain attack, built over a long-term trust relationship.

As these examples show, supply chain attacks are sophisticated methods that exploit not only technical vulnerabilities but also flaws in human trust relationships and processes.

Practical Guide to Implementing SBOM (Software Bill of Materials)

What is an SBOM?

An SBOM (Software Bill of Materials) is a “bill of materials” that lists all components, libraries, and dependencies contained within software. Using the same concept as food ingredient labels or manufacturing parts lists, it makes the constituent elements of software visible.

In May 2021, a U.S. presidential order mandated the provision of SBOMs for federal procurement, and in Japan, the handling of SBOMs in government procurement has been actively discussed since 2024. The European Cyber Resilience Act (CRA) also includes SBOM as a requirement, making it a global trend.

Information That Should Be Included in an SBOM

A proper SBOM should include the following information:

• Component Name and Version: All libraries used and their exact version numbers.
• Dependency Tree: Parent-child relationships and interdependencies between components.
• License Information: The license under which each component is used.
• Vulnerability Information: Results of cross-referencing with known CVEs (Common Vulnerabilities and Exposures).
• Unique Identifiers: Information that can uniquely identify the component.

Major SBOM Formats

Currently, there are two mainstream SBOM formats.

SPDX (Software Package Data Exchange) An international standard format led by the Linux Foundation. It has been standardized as ISO/IEC 5962:2021 and excels in handling license information. It features broad tool support and high adoption rates in the industry.

CycloneDX A format developed by OWASP (Open Web Application Security Project). It focuses on security information and can contain rich vulnerability information and SBOM-related metadata. Versioning and integration with component vulnerability cross-referencing are easy.

The choice between formats depends on organizational requirements, but in recent years, the adoption of CycloneDX has been on an increasing trend.

Selecting SBOM Generation Tools and Implementation Steps

Here are the main tools for generating SBOMs.

Syft (Anchore) An OSS tool that automatically generates SBOMs from container images and file systems. It supports both SPDX and CycloneDX formats and has comprehensive multi-language support. As a CLI tool, it can be easily introduced and integrated into CI/CD pipelines.

Trivy (Aqua Security) Widely known as a vulnerability scanner, it also has SBOM generation capabilities. It can scan container images, file systems, and Git repositories, with the strength of performing vulnerability detection and SBOM generation in an integrated manner.

Microsoft SBOM Tool An OSS tool released by Microsoft that runs on Windows/Linux/macOS environments. It generates SBOMs in SPDX format and also supports integration with GitHub Actions.

Tern A tool specialized in generating SBOMs for container images. It can perform more detailed analysis by identifying components based on an understanding of the Dockerfile’s intent.

As practical steps for implementation, first select one tool that suits your organization’s technology stack and trial SBOM generation in a test environment. Next, review the content of the generated SBOM and verify that known components are correctly recognized. Finally, integrate it into the CI/CD pipeline and configure it to be automatically generated during builds.

Key Points for SBOM Operations

The act of “creating” an SBOM itself is not the goal. What’s important is to use the SBOM to streamline vulnerability management. Create a mechanism to regularly cross-reference generated SBOMs with known vulnerability databases and identify affected components early. Furthermore, including the SBOM as part of release deliverables allows users to also understand the scope of vulnerability impact.

Strengthening CI/CD Pipeline Security

Why CI/CD Pipelines Are Targeted

CI/CD pipelines are mechanisms that automate the entire flow from code changes to deployment in the production environment. If this pipeline is attacked, attackers can gain permissions for direct access to the production environment or distribute malicious code via the legitimate deployment route.

CI/CD pipelines typically aggregate repository access rights, container registry credentials, cloud service API keys, and deployment destination access permissions. In other words, controlling the pipeline means controlling the entire development infrastructure.

Multi-Layered Defense Strategy for Pipeline Security

Security for CI/CD pipelines is not about a single measure but about building defenses across multiple layers.

Layer 1: Source Code Protection Access to source code repositories should be with minimal privileges, and branch protection rules should be applied. Direct pushes to the main branch should be prohibited, and code reviews via pull requests should be mandatory. Introduce signed commits to detect code tampering. Furthermore, record and monitor repository operation logs to detect abnormal access early.

Layer 2: Dependency Management Pin the versions of external libraries to prevent the introduction of vulnerabilities through unintended updates. Automate hash value checks and package signature verification to ensure package integrity. Operating a private package registry and introducing a policy to use only packages approved within the company is also effective.

Layer 3: Build Environment Isolation and Security The build environment should be completely isolated from the production environment, with minimal privileges granted to build agents. Use container-based build environments to ensure a clean environment for each build. Regularly check the build tools themselves for vulnerabilities and apply the latest security patches.

Layer 4: Security Testing Automation Integrate SAST (Static Application Security Testing) into the pipeline to detect code-level vulnerabilities early. Use DAST (Dynamic Application Security Testing) to also check for runtime vulnerabilities. Use SCA (Software Composition Analysis) tools to scan for vulnerabilities in dependent components. Additionally, run container image scans before deployment to detect known vulnerabilities and misconfigurations.

Layer 5: Access Control and Secret Management Credentials and secrets used in CI/CD pipelines should not be stored in plaintext in hard-coded values or environment variables but should use dedicated secret management tools. Utilize solutions like Vault, AWS Secrets Manager, or GitHub Secrets to strictly control access to secrets. Grant different permissions for each step of the pipeline to minimize the impact in case of a leak.

Major CI/CD Security Tools

GitHub Advanced Security GitHub’s native security feature. Provides SAST via CodeQL, vulnerability detection and automatic updates for dependencies via Dependabot, and secret detection capabilities. For organizations using GitHub Actions for CI/CD, the high level of integration is a major advantage.

GitLab SAST/DAST Security scanning features integrated into GitLab CI/CD. SAST, DAST, container scanning, and dependency scanning can be executed in a batch within the pipeline, and vulnerability reports can be checked via a dashboard.

Snyk Highly regarded as a security platform for developers. Comprehensively detects vulnerabilities in code, containers, infrastructure, and IaC (Infrastructure as Code). A feature is that developers can check vulnerabilities while coding through IDE integration.

Aqua Security / Prisma Cloud Excels in security for containers and cloud environments. It is possible to apply consistent security policies from the CI/CD pipeline to the production environment.

Practicing DevSecOps to Secure the Entire Development Process

What is DevSecOps?

DevSecOps is the culture and practice of integrating security into the early stages of the development process by merging Development (Dev), Operations (Ops), and Security (Sec). It breaks away from the traditional model of “performing security reviews after development” and embeds security as “everyone’s responsibility” throughout the development lifecycle.

Practical Steps for DevSecOps

Step 1: Visualize the Current State First, understand the current state of security in your organization’s development process. Analyze at which stage security checks are performed, how long it takes from vulnerability detection to remediation, and what the trends in past incidents were.

Step 2: Introduce Security Gates Gradually Don’t try to introduce everything at once; prioritize based on impact and implementation cost. Start with SAST and dependency scanning, then gradually add DAST, container scanning, and IaC scanning. Apply the “fail fast” principle by fixing issues detected at each gate before proceeding to the next step.

Step 3: Educate and Empower Developers It’s important not only to introduce security tools but also to ensure developers understand security and can respond themselves. Advance initiatives in parallel to raise security awareness across the organization, such as establishing secure coding guidelines, providing vulnerability response training, and introducing a security champion system.

Step 4: Metrics and Continuous Improvement Define metrics such as the number of vulnerabilities detected, remediation time (MTTR), and vulnerability trends per release, and review them regularly. By numerically grasping the security status, measure improvement effects and review priorities.

Risk Management for Open Source Components

The Reality of Open Source Dependency

In modern software development, it is virtually impossible to develop production-level products without open source components. According to surveys, 70-90% of an enterprise’s application code consists of open source. This means, if not managed properly, it harbors a vast number of potential vulnerabilities.

Approaches for Effective Risk Management

Maintain a Component Catalog Accurately record all open source components used and their versions. By generating and regularly updating SBOMs, always maintain the latest component list.

Continuous Vulnerability Monitoring Collaborate with vulnerability databases like the NVD (National Vulnerability Database) or GitHub Advisory Database to detect new vulnerabilities affecting used components in real-time. Utilize automatic update tools like Dependabot or Renovate to automate the application of security patches.

License Compliance Unknowingly introducing components with copyleft licenses like GPL or AGPL carries the risk of obligations to disclose your own code. Utilize the license information in SBOMs to detect components that violate license policies early.

Consider Forks and Mirrors For frequently used critical components, maintaining your own fork or mirror can prepare you for upstream changes or disappearance risks. However, applying security patches to forked components becomes your own responsibility, so this should be considered alongside your operational structure.

Implementation Checklist | Countermeasures You Can Start Today

Finally, we summarize a practical checklist for introducing supply chain attack countermeasures into your organization.

Short-term measures (1-3 months): Introducing security scanning tools into the CI/CD pipeline, configuring automatic dependency update tools, improving secret management, and applying branch protection rules.

Medium-term measures (3-6 months): Building the SBOM generation process, starting to promote DevSecOps culture, establishing secure coding guidelines, and creating an incident response playbook.

Long-term measures (6 months or more): Building a system for external SBOM provision, setting KPIs for vulnerability management and continuous improvement, establishing a security evaluation process for third-party vendors, and implementing organization-wide security awareness improvement programs.

Supply chain attack countermeasures are not a one-time implementation. It is important to continuously review and improve as the technology environment evolves. Using the knowledge introduced in this article as a reference, proceed gradually with measures suited to your organization’s situation.