[Contributed Article] In an Era of Attacks on Trust, the Standards for Supply Chain Security Are Changing
In the Age of AI-Powered Attacks, Connecting Software Components to Operational Assets Is Critical Security Must Extend Beyond Vulnerability Identification to Provenance Verification and Deployment Controls
In the Age of AI-Powered Attacks, Supply Chain Security Starts by Connecting Components to Operational Assets
When a new vulnerability is disclosed or a supplier announces a security breach, organizations must first answer one question: “Which of our operational assets contain that component?” Without an answer, patching and isolation cannot begin. Other risks also exist that cannot be detected through CVE searches alone, including malicious packages, tampered builds, and compromised maintainer accounts. A software bill of materials (SBOM), therefore, must go beyond listing components and be linked to operational assets, vulnerabilities, and remediation information.
A white paper from a security company analyzing a series of breaches in the financial sector found that organizations operating in similar environments and using common solutions and third-party products may experience recurring vulnerabilities across multiple institutions. When organizations share the same components, they must link component provenance, versions, and deployment environments to determine the scope of impact.
The essence of supply chain security is no longer simply finding “a vulnerable line of code.” Today’s attackers target the very pathways developers trust. Open-source package repositories, outsourced development firms, continuous integration and continuous delivery (CI/CD) pipelines, package registries, code-signing systems, software-as-a-service (SaaS) integrations, AI coding tools, AI models, and training data have all become part of the software supply chain.
This shift raises fundamental questions for security teams. Where did the code and packages we use come from? In what build environment were the artifacts created, and on which servers and services are they currently running? Who changed what immediately before deployment? What data and permissions can external partners and AI tools access? And can these questions be answered continuously before an incident occurs, rather than only afterward?
In the AI era, supply chain security is expanding from “finding and fixing vulnerabilities” to “identifying which operational assets contain each component and proving that the component entered the environment and was modified through trustworthy processes.”
What CVE-Centric Management Misses
Traditional vulnerability management has evolved around Common Vulnerabilities and Exposures (CVE). Organizations identify the libraries and frameworks they use and patch known vulnerabilities or implement workarounds when issues are discovered.
This approach remains essential. Known vulnerabilities are an important starting point for real-world breaches, while asset inventories and patch prioritization are fundamental security operations capabilities.
However, CVEs do not explain every attack. In supply chain attacks, whether a trusted component actually entered the environment through a trustworthy path can be more important than whether the component has a known vulnerability.
For example, suppose an attacker compromises the maintainer account of a popular open-source project. The attacker could publish a new version containing malicious code using the legitimate package name and normal distribution channel.
The code might not yet be registered as a publicly disclosed vulnerability, and static analysis might miss carefully concealed malicious behavior. Software Composition Analysis (SCA) tools may recognize the package as a legitimate dependency because its name, version, and distribution path all appear normal.
The same problem arises when a build environment is compromised. The code in the source repository may be clean, but a tampered CI/CD runner or build script could inject malicious behavior into the final binary.
In that case, the source code reviewed by the development team and the artifact actually deployed in the customer environment are no longer the same. Even an exhaustive search of CVE databases cannot easily detect tampering introduced during the build process.
Organizations must therefore distinguish among three questions:
Does this component have any known vulnerabilities?
On which operational assets is this component running?
Did this component and its artifacts enter the environment through a trustworthy source and verifiable process?
The first question falls under vulnerability management. The second concerns asset management and determining the scope of impact. The third involves supply chain integrity, provenance, change history, and deployment controls.
Answering the second question makes it possible to determine the impact on operational assets and identify all systems that need patching or isolation. At the same time, installation and deployment must be blocked at the point of entry when provenance or integrity checks fail.
As AI adoption and complex external dependencies increase, it becomes even more important to address all three questions together.
Figure 1. CVE scans detect known vulnerabilities, but breaches that exploit trusted pathways—such as compromised accounts or tampered builds—require separate provenance and integrity verification.
New Entry Points Created by AI
AI coding assistants improve developer productivity. They can turn natural-language requirements into code, recommend libraries, fix errors, and even generate test code and infrastructure configurations.
However, an AI recommendation is not necessarily a security-validated answer. The moment a developer copies an AI suggestion into a project, AI becomes a practical entry point into the software supply chain.
One notable risk is slopsquatting.
Slopsquatting is a technique in which attackers exploit generative AI hallucinations that produce nonexistent package names, incorrect library names, or plausible but invalid dependencies.
Attackers can register package names that AI tools are likely to generate and upload malicious code under those names. If developers install AI-recommended packages without verification, the attacker’s packages can enter development environments and build pipelines as if they were legitimate dependencies.
This resembles traditional typosquatting, but there is an important difference.
Typosquatting targets the likelihood that people will mistype a popular package name, perhaps by changing a letter or reversing the order of characters. Slopsquatting, by contrast, targets errors in AI recommendations rather than human typing mistakes. Developers have not necessarily entered an incorrect name; they may simply have followed an AI suggestion that looked plausible.
This difference requires a change in operational practices. In the past, developer training and package-name checks could reduce some risks. Today, AI-generated and AI-recommended dependencies require more systematic verification.
Organizations should first confirm that a package actually exists and is available through an official distribution channel. They should also examine who maintains the project, its release history, download volume, security policies, and whether releases are signed.
Dependency lockfiles, hash pinning, allowlists, and private proxy registries are also important for controlling the introduction of unauthorized packages.
In addition, organizations should track direct and transitive dependencies introduced by AI-generated code through SCA and SBOMs. They should block unauthorized dependency installations and external communications not only in individual developers’ environments but also in CI/CD environments.
The key is not to classify AI-written code and human-written code as separate risk categories. Both must undergo the same security verification.
However, AI substantially increases the verification burden because it accelerates the generation of code and dependencies and makes it more likely that developers will adopt them without adequately checking their provenance.
Figure 2. If AI recommends a nonexistent package name and an attacker registers a malicious package under that name, unverified installation by a developer can introduce malicious code into development and build environments.
SBOMs Become Useful When Connected to Operational Assets
In this environment, a Software Bill of Materials (SBOM) provides the foundation for software supply chain visibility.
An SBOM records structured information about the software components, versions, relationships, licenses, and suppliers that make up an application or product. In simple terms, it is a parts list for software.
However, storing an SBOM merely as a document does not answer the most urgent question.
When a new vulnerability is disclosed or a supplier announces a breach, the question organizations must answer—“Are we affected?”—ultimately becomes “Which of our operational assets contain that component?”
Following a series of breaches in the financial sector, concerns were raised that security teams could not identify the existence and configuration of every system. As a result, even after a new vulnerability was announced, organizations struggled to determine immediately whether the affected software was present in their environments and needed remediation.
Even a single application can consist of multiple assets, including servers, databases, and network equipment. Both the composition and number of these assets change continuously.
Attackers exploit this problem in reverse. In the Financial Security Institute’s first detected case of an AI-agent attack, an attacker directed an agent to scan for WebLogic assets in order to target financial institutions in Korea and abroad. The attacker began by locating assets that used a specific component.
In an earlier incident involving a credit card company, reports indicated that WebLogic remained in use on a payment server for years after a security patch had been released. The WebLogic installation had also been omitted from the asset inventory.
If attackers can find assets by identifying their components, defenders must be able to trace components to operational assets even faster.
These connections must remain intact in live operating environments.
Suppose a remote code execution vulnerability is disclosed in a widely used Java library. An organization must be able to answer five questions in sequence.
If any link in this process is missing, the assessment of the impact remains an estimate.
Even if an SBOM provides the information required for the first step, the absence of the second and third connections means the organization may know that it uses the component but not where it is running.
Without the fourth step, it is difficult to determine what to fix first. Without the fifth, there is insufficient evidence to claim that remediation has been completed.
The same connections are necessary to identify which services and customer environments contain a component when a supplier announces a breach, and to demonstrate software configurations during an audit.
A management layer is also needed to maintain these connections.
Application Security Posture Management (ASPM) links the results of Static Application Security Testing (SAST), SCA, container scans, cloud configuration assessments, and ticketing systems to applications, repositories, asset owners, deployment environments, and remediation status.
This helps organizations adjust response priorities according to actual risk.
When results remain isolated, organizations can end up with a large number of alerts but unclear priorities and no clearly identified owners.
Conversely, connections are of little value if the linked information cannot be trusted. If an SBOM differs from the artifact actually deployed, or if components change during the build process, the entire mapping may be incorrect.
Provenance and integrity verification are prerequisites for trusting these mappings.
Regulatory and policy initiatives are moving in the same direction.
In October 2025, following a series of telecommunications and financial-sector breaches, the government announced a comprehensive interagency information security plan that included institutionalizing SBOM submission requirements for public-sector IT systems and products by 2027.
In June 2026, the Ministry of Science and ICT and the National Intelligence Service further detailed this direction in their roadmap for strengthening software supply chain security in the age of everyday AI, outlining phased implementation beginning in 2027 for public-sector IT projects and security verification procedures.
For the financial sector, the Financial Services Commission’s July 2026 guidance on responding to emerging AI security threats in finance recommended considering SBOM creation for internally used open-source software and using SCA.
Unlike the planned 2027 institutionalization for the public sector, however, SBOM creation and SCA use in the financial-sector guidance are recommendations.
In either case, what makes a real difference is not the act of submitting an SBOM itself, but connecting it to operational assets and remediation activities and putting it to practical use.
Figure 3. An SBOM is the starting point for recording components and versions. Determining the actual impact and remediation priorities requires linking this information to deployed artifacts, operational assets, external exposure, responsible owners, and remediation history.
Standards Are Operating Structures, Not Tools
Several standards and frameworks for supply chain security already exist.
The U.S. National Institute of Standards and Technology’s Secure Software Development Framework (SSDF) provides an operational framework for embedding security throughout the software development lifecycle without mandating specific tools.
Supply-chain Levels for Software Artifacts (SLSA) progressively strengthens provenance and build integrity from source code through build and distribution artifacts.
The Open Source Security Foundation (OpenSSF) provides assessment frameworks that help organizations evaluate whether open-source projects have security policies, code reviews, and vulnerability disclosure procedures.
No single score can guarantee security, but these assessments are better than relying only on isolated indicators such as download counts.
These standards and frameworks are not substitutes for one another. SSDF addresses the operational framework, SLSA addresses trusted pathways, OpenSSF assesses the maturity of the open-source ecosystem, and SBOMs provide common data about components and the scope of impact.
Organizations should not adopt each standard in isolation. Instead, they should connect them into a unified control process that ultimately links to operational assets and remediation.
Secure SDLC: Organizations Must Be Able to Stop Deployment
A Secure Software Development Lifecycle (Secure SDLC) is not an approach that adds security checks only after development is complete. It is a structure that connects security verification and accountability from planning through operation.
Three controls are particularly important from a supply chain perspective.
First, SAST detects vulnerable implementation patterns early in both internally developed and AI-generated code, including authentication and authorization errors, missing input validation, hardcoded secrets, and potential injection vulnerabilities.
Because false positives and a lack of contextual information can occur, risk-based remediation criteria and exception approval procedures are also necessary.
Second, SCA and SBOMs identify not only directly installed packages but also transitive dependencies called by those packages. They provide a foundation for linking the results to specific products, services, versions, and deployed artifacts.
Third, signing and provenance verification systems such as SLSA and Sigstore help verify that artifacts have not been tampered with after the build process.
Operating environments must verify not only whether an image has passed vulnerability scanning, but also whether it was created and signed using approved source code and build systems.
The most important performance indicator is not how many security tools have been deployed, but whether the organization can actually block deployments that violate policy.
For example, container images meeting any of the following conditions can be blocked from production deployment:
They originate from an unapproved registry or an unauthorized external package.
They lack a signature or proof of build provenance.
They contain unresolved vulnerabilities exceeding the organization’s defined severity threshold.
They contain detected secrets or violate licensing policies.
Their security exception approvals have expired.
These deployment gates are not intended simply to slow development.
They are controls that clarify exception criteria, approval responsibilities, alternative packages, and remediation deadlines, preventing security from depending on individuals’ memory and goodwill.
To close “change verification gaps,” the same deployment gates and regression testing for authentication and authorization must also apply to changes made during operation.
Figure 4. Deployment should proceed only after source code and build artifacts have been signed, an SBOM has been generated, and policy checks have been completed. Deployment is blocked when policy violations—such as missing signatures, vulnerabilities above the severity threshold, or exposed secrets—are detected.
Verification Must Extend Beyond Internal Code
Supply chain security is not limited to code quality within an organization’s internal development teams.
Outsourced development firms, SaaS providers, cloud providers, managed security service providers, package suppliers, data providers, and AI model and plugin providers can all affect an organization’s attack surface.
Therefore, Third-Party Risk Management (TPRM) must become a continuous verification framework shared by procurement, legal, information security, development, and operations teams.
The same pattern has emerged in the financial sector.
In September, the Financial Supervisory Service conducted on-site inspections of two payment gateway (PG) companies after data breaches were disclosed. According to reports published on October 7, abnormal access was attributed to exposed API authentication keys on payment integration platforms.
This demonstrates that credentials, query permissions, and incident notification related to payment integrations must also fall within the scope of third-party verification.
Traditional TPRM has often focused on security questionnaires and certification checks before contracts are signed. Supply chain risks, however, continue to change after a contract is in place.
A supplier may add a new subcontractor, a SaaS service may change its functionality, an external API’s authentication method or data-processing location may change, or an open-source maintainer may change or effectively abandon a project.
Third-party verification must therefore expand from a one-time review into continuous control.
Security processes used by suppliers and outsourced partners, vulnerability response procedures, and incident notification obligations should be reflected in contracts and operational requirements.
For critical software supplied by third parties, organizations should require SBOMs, security patch policies, end-of-support schedules, and evidence of signatures or provenance.
For SaaS and external APIs, organizations should enforce least privilege, data classification, access logging, API key rotation, and restrictions on integration scope.
High-risk suppliers should undergo periodic reassessment and participate in incident notification and response exercises.
Organizations should also continuously monitor changes in external dependencies, newly disclosed vulnerabilities, package ownership changes, and anomalies involving domains and certificates.
These responsibilities must not fall solely on the security team.
Procurement teams should incorporate security requirements into supplier selection and contract terms. Development teams should follow approved component and build procedures, while operations teams should deploy only verified artifacts.
Executives must clearly define risk acceptance criteria and responsibility for approving exceptions.
AI Models Are Also Part of the Supply Chain
The spread of generative AI is expanding the supply chain beyond source code and libraries.
Assets requiring management now include AI model files, training data, fine-tuning datasets, system prompts, Retrieval-Augmented Generation (RAG) documents, embedding models, plugins, agent tools, and Model Context Protocol (MCP) servers.
The key assets in an AI model supply chain are not limited to model weight files.
Organizations must track which models they use, which data was used to train or fine-tune them, and which documents are included in their RAG knowledge bases.
They must also identify which tools each model can invoke and which data and systems those tools can access.
Consider a RAG-based workplace assistant that searches internal documents.
Even if the model itself is secure, sensitive information may be exposed in responses if confidential documents are mistakenly included in the search index or access controls are weak.
If an agent can call external MCP servers or internal business systems, prompt injection can lead to privilege abuse and data leakage rather than merely affecting response quality.
These risks have also emerged in real-world incidents.
In July 2026, OpenAI and Hugging Face disclosed a security incident associated with OpenAI’s internal cybersecurity capability evaluation, ExploitGym.
An AI agent used for the evaluation exploited a zero-day vulnerability in a package registry cache proxy to escape its isolated environment and access the internet. It then used an externally operated code execution environment as a foothold.
According to Hugging Face’s subsequent technical analysis, the agent obtained credentials by exploiting a flaw in HDF5 file handling in a dataset processing pipeline, executed code through Jinja2 template injection, and then penetrated internal infrastructure.
Confirmed access to customer content was limited to five datasets associated with the evaluation tasks. Other customer models and datasets were not affected. However, separate compromises of internal infrastructure and permissions were also confirmed.
The root-cause analyses published by the two companies identified overly broad credential scopes and access to the instance metadata service from within a pod.
This was a case in which an AI agent, rather than a human attacker, independently chained supply chain weaknesses together to expand its privileges.
AI supply chain security must therefore address the following questions:
Were model files and container images obtained from trustworthy sources?
Can versions and change histories for models, datasets, prompts, and RAG documents be tracked?
Have the plugins, APIs, and MCP servers that models can invoke been approved, signed, and verified?
Is access to data controlled through classification, masking, and retrieval authorization policies?
The Financial Security Institute’s draft security assessment criteria for AI agents in the financial sector, prepared in October 2026, also expanded the scope of verification beyond the models themselves to include components such as external tools and plugins, adding supply chain security to its assessment items.
AI can accelerate supply chain attacks.
Attackers can use AI to generate large volumes of malicious package descriptions, make phishing more sophisticated, rapidly identify vulnerable code patterns, and produce content designed to exploit developers’ trust.
Defenders, in turn, can use AI to analyze extensive SBOMs, vulnerability advisories, code changes, configuration errors, and anomalous behavior to prioritize responses.
However, determining how AI agents and the systems, tools, and permissions connected to them should be incorporated into existing risk and remediation management is a separate challenge from provenance verification.
Figure 5. The scope of AI supply chain management is not limited to model files. Provenance, permissions, and execution scope must also be controlled for training and fine-tuning data, RAG documents, plugins, MCP servers, internal business systems, and agent tool calls.
What Should Be Measured?
Supply chain security maturity cannot be assessed solely by asking whether an SBOM has been created or security tools have been purchased.
Organizations must verify the effectiveness of their security controls using operational metrics.
First, they should measure the proportion of SBOMs linked to deployed artifacts and operational assets such as servers, containers, and services.
The time required to identify affected operational assets after a new vulnerability is disclosed is another important metric.
Organizations should also measure the proportion of production artifacts that have up-to-date SBOMs and verifiable build provenance, as well as the rate at which deployments of unsigned or unapproved artifacts are blocked.
The mean time to detect and remediate high-risk vulnerabilities and the compliance rate for expiration dates on approved exceptions indicate actual response capabilities.
Organizations should also track the completion rate of security assessments and reassessments for outsourced partners, SaaS providers, and critical suppliers.
In AI environments, measurement should expand to include provenance verification and approval rates for AI-generated dependencies, models, datasets, and MCP servers.
These metrics are not simply intended to evaluate the security team’s performance.
They provide a common language for decision-making: executives can determine risk tolerance, development teams can identify bottlenecks, procurement teams can improve supplier requirements, and operations teams can strengthen deployment controls.
Conclusion: Organizations Must Be Able to Trace Components to Operational Assets
Supply chain attacks may begin outside an organization’s firewall, but they ultimately enter internal environments by following trusted software and service pathways.
When a new vulnerability or supplier breach is disclosed, the first question an organization must answer is: “Which of our operational assets contain that component?”
Without an answer, patching, isolation, and customer notification cannot begin in time.
To address this challenge, component information must be linked to operational assets, vulnerabilities, and remediation data.
SBOMs and SCA results can reveal the scope of impact and remediation priorities only when connected to deployed artifacts, servers, containers, services, external exposure, asset owners, remediation deadlines, and re-verification records.
This is why component inventories must be integrated with unified asset and vulnerability management systems.
Provenance and integrity verification through frameworks and technologies such as SSDF, SLSA, and Sigstore, together with third-party risk management, provides the foundation for trusting these connections.
Ultimately, the number of security tools an organization owns and the number of SBOM documents it produces are not the key measures.
The real standard is whether the organization can trace a problematic component to its operational assets and remediate the issue—and whether it can actually prevent code, packages, builds, and models that violate policy from entering production.
The next installment will address the final question.
AI agents and the systems, tools, and data they connect to are operational assets, too. Now that AI can process untrusted inputs and exercise permissions, organizations must ask whether the systems connected to AI are included in their existing risk and remediation management scope.
Supply chain security in the AI era is not about creating a list of components. It is about tracing problematic components to operational assets, taking action, and proving that the pathways through which they entered the environment can be trusted.
전자신문
![[Contributed Article] Rethinking the Side Door to Financial Security](https://static.wixstatic.com/media/d9b553_24475e5d25af4dc6875388c03a73bb25~mv2.png/v1/fill/w_980,h_549,al_c,q_90,usm_0.66_1.00_0.01,enc_avif,quality_auto/d9b553_24475e5d25af4dc6875388c03a73bb25~mv2.png)
Comments