This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Software Supply Chain Attacks and the Need for Security

Introduces the importance of software supply chain security, recent threat trends, and the essential strategies for defending against them.

1. What Is a Software Supply Chain Attack?

A software supply chain attack is a cyberattack technique in which an attacker infiltrates the systems of a software developer or supplier, or the development process itself, to plant malicious code or exploit vulnerabilities.

Whereas traditional attacks directly target end users, supply chain attacks contaminate trusted software updates or development tools, thereby simultaneously infecting the many downstream companies and users that rely on them.

graph LR
    A[Attacker] -->|Infiltrate| B[Supplier Build Server]
    B -->|Inject Malware| C[Compromised Software Update]
    C -->|Distribute| D[Customer A]
    C -->|Distribute| E[Customer B]
    C -->|Distribute| F[Customer C]

    classDef danger fill:#FDE1E7,stroke:#EA002C,color:#8A0019,stroke-width:1.5px
    classDef victim fill:#ffffff,stroke:#c8c8c8,color:#171717,stroke-width:1px
    class A,B,C danger
    class D,E,F victim

2. Notable Attack Cases

  • The SolarWinds incident (2020): The build system was hacked and a backdoor was planted in officially signed updates, affecting some 18,000 organizations worldwide including U.S. government agencies. It demonstrated that even software from a trusted vendor may not be safe.
  • The Log4j vulnerability (2021): A remote code execution vulnerability in a widely used logging library exposed hundreds of millions of servers worldwide. It drove home the need for a way to know which open source components your systems use — that is, an SBOM.

3. Why Supply Chain Security?

70-90% of modern application code consists of open source components. When a single common component is compromised the damage spreads worldwide, and code compromised at the build stage is hard to catch with traditional security checks such as firewalls and antivirus. To manage this risk, SK Telecom has adopted SBOMs and enforces a supply chain security policy.

1 - Regulatory Trends

Examines the state of software supply chain security regulations that are being strengthened worldwide, such as U.S. EO 14028 and the EU CRA.

1. United States: Executive Order 14028 (EO 14028)

In May 2021, the Biden administration issued the “Executive Order on Improving the Nation’s Cybersecurity (Executive Order 14028).”

Key Provisions

  • Push toward SBOM requirements: EO 14028 directed defining the minimum elements of an SBOM (data fields, automation support, etc.) and secure software development practices; the SBOM submission and self-attestation requirements for federal suppliers were detailed in subsequent OMB guidance.
  • NIST guideline compliance: Companies must comply with the Secure Software Development Framework (SSDF) defined by NIST (the U.S. National Institute of Standards and Technology).

2. European Union (EU): Cyber Resilience Act (CRA)

Through the Cyber Resilience Act (CRA), the EU has enacted into law security requirements spanning the entire lifecycle of digital products.

Key Provisions

  • CE marking certification: All products with digital elements can only be sold within the EU if they meet the cybersecurity requirements and bear the CE mark.
  • Defined security support period: Manufacturers must provide security updates throughout the expected product use period, which is, in principle, at least five years. If the expected use period is shorter than five years, the support period matches it (Regulation (EU) 2024/2847, Article 13 and Recital 60). In other words, five years is a baseline, not a cap.
  • Vulnerability reporting obligation: On becoming aware of an actively exploited vulnerability or a severe security incident, the manufacturer must submit an early warning to the coordinating CSIRT and ENISA within 24 hours, followed within 72 hours by a notification and, later, a final report (Regulation (EU) 2024/2847, Article 14).
  • SBOM management: Manufacturers must identify and document (via an SBOM) the software components of their products.

3. South Korea: SW Supply Chain Security Guidelines

In step with the global trend, the South Korean government (the Ministry of Science and ICT, KISA, and the National Intelligence Service) has also released the “SW Supply Chain Security Guidelines” and is pursuing proof-of-concept initiatives.

Key Contents (based on v1.0)

  • Recommendation to adopt SBOM: It is recommended that an SBOM be generated and utilized when developing and delivering software in both the public and private sectors.
  • Supplier security activities: Suppliers are advised to build a secure development environment, generate and provide an SBOM, and inspect for security vulnerabilities.

SK Telecom’s requirements in response to these regulatory trends are laid out in the SK Telecom Supply Chain Security Policy.

2 - SK Telecom Supply Chain Security Policy

Describes the supply chain security policy and principles that partners supplying software to SK Telecom must comply with.

NOTICE.

In accordance with internal security and document management policies, this document is a summary that excludes confidential content. Please note that it is written around high-level key points rather than the full content.

1. Purpose of the Policy

The purpose of this policy is to ensure the transparency of all software that SK Telecom adopts, and to identify and eliminate, in advance, the risks of known vulnerabilities and license violations.

2. Scope of Application

All suppliers that enter into a software supply contract with SK Telecom are subject to this policy.

3. Key Requirements

Suppliers must comply with the following three principles.

Principle 1: Mandatory SBOM Submission

  • For every software delivery, the supplier must submit an SBOM (Software Bill of Materials) corresponding to that version.
  • The accepted formats and required data fields are defined in the Submission Requirements.

Principle 2: Vulnerability Inspection and Remediation

  • Before delivery, the supplier must independently check for the latest security vulnerabilities (CVEs).
  • If Critical/High severity vulnerabilities are found, the supplier must patch them or apply mitigation measures before delivery.
  • If patching is not possible, the supplier must prove, through a “vulnerability justification statement,” that the vulnerability has no actual impact on the service.

Principle 3: Transparent Change Management

  • If the components of the software change during the contract period (updates, patches, etc.), the supplier must immediately submit an updated SBOM.
  • The supplier must warrant that it has complied with open source license obligations (notice obligations, source code disclosure obligations, etc.).