Third-Party Code
Overview
Third-Party Code (타사 코드) collectively refers to software components that a development organization does not write itself but adopts from external suppliers or open-source communities. This includes libraries, frameworks, SDKs, plugins, API clients, open-source packages, and more. In modern software development, dependence on third-party code is essential for productivity and feature expansion, but at the same time, risks related to security, licensing, and maintenance must be managed together.
Main Content
Definition and Scope
Third-party code is largely classified into three categories. First, open-source components, which are packages distributed through repositories such as npm, PyPI, and Maven Central. Second, commercial software development kits (SDKs), which are official libraries from cloud services or hardware manufacturers. Third, outsourced development deliverables or code in the form of modules provided by vendors.
Reasons for Use
- Faster development: There is no need to reimplement repetitive functions such as authentication, encryption, and networking.
- Proven stability: Widely used libraries have already been tested in many projects.
- Cost reduction: It saves in-house development and maintenance personnel.
- Standards compliance: It makes it easy to support industry-standard protocols and formats.
Major Risks
Security Vulnerabilities
Third-party code is a major channel for supply chain attacks. The 2021 Log4Shell incident is a representative case in which a vulnerability in a widely used logging library affected millions of services worldwide. Typosquatting that abuses package names, malicious code insertion, and Dependency Confusion attacks are also frequent.
License Issues
If copyleft licenses such as GPL or AGPL are included, an obligation to disclose one's own source code may arise. Conversely, MIT and Apache 2.0 are relatively permissive. Omitting license notice obligations can lead to legal disputes.
Lack of Maintenance
If an open-source project is discontinued or its maintainer disappears, security patches cannot be received. This is often called the "zombie dependency" problem.
Version Conflicts
If dependencies requiring different versions of the same library become entangled, "Dependency Hell" occurs.
Management Measures
- Create an SBOM (Software Bill of Materials): List all third-party components in use.
- Introduce SCA (Software Composition Analysis) tools: Automatically scan for vulnerabilities with Dependabot, Snyk, OWASP Dependency-Check, etc.
- Establish a license policy: Codify lists of allowed and prohibited licenses.
- Regular updates: Set and automate a cycle for applying security patches.
- Principle of minimal dependencies: Introduce only essential packages and manage the number of transitive dependencies.
Latest Trends
As of 2024–2025, the paradigm of third-party code management is changing in three major directions.
First, stronger regulation. As U.S. executive orders and the EU Cyber Resilience Act (CRA) require SBOM submission, supply chain transparency is becoming mandatory. In Korea as well, software supply chain security guidelines are spreading.
Second, the spread of AI-based code generation. Concerns are being raised that code generated by tools such as Copilot and Cursor may include fragments of existing open source, and verifying the license provenance of AI-generated code is a new issue.
Third, the adoption of supply chain integrity standards such as SLSA and Sigstore. Package signing and provenance attestation are becoming established in practice, and major repositories such as npm and PyPI also support signature verification.
Related Topics
- [[Open Source]]
- [[Software Supply Chain Attack]]
- [[SBOM]]
- [[Dependency Management]]
- [[License]]