State Council Decree No. 834 Has Landed: Regarding Software Supply Chain Security, What Enterprises Lack is Not Tools, But These Three Things

PART 01

Regulations Have Arrived, and the Window of Opportunity Is Shrinking

On 31 March 2026, the State Council promulgated the "Regulations on the Security of Industrial and Supply Chains" (State Council Decree No. 834), which came into effect immediately.

Article 12 is written very directly:

Enterprises, scientific research institutions, etc., shall improve their risk prevention and control systems to ensure that core technologies, as well as related information systems and data, are secure and controllable.

Article 9 requires the establishment of a "monitoring and early warning system for security risks in key industrial and supply chains." If an enterprise detects any security risks, it must report them to the competent department. This is not an industry specification; it is an administrative regulation with binding force across all industries.

Prior to this, the national standard GB/T 43698—2024 "Cybersecurity Technology — Software Supply Chain Security Requirements" had already been implemented on 1 November 2024, upgrading enterprises' supply chain security obligations from "recommended" to "shall." The standard explicitly requires the demand side (i.e., software purchasers and users, which means the vast majority of enterprises) to:

• Perform integrity verification and comprehensive security testing before acquiring software to ensure that no publicly disclosed vulnerabilities remain unpatched (§7.2.3)

• Obtain installation/upgrade packages from secure and controllable channels during the operation and maintenance period, and deploy them only after integrity verification (§7.2.4(d))

• Take immediate remedial measures upon discovering any vulnerabilities and report them to the competent department in accordance with regulations (§7.2.4(i))

• Construct and maintain a software supply chain security graph (including SBOM), which must contain component vulnerability information for important business scenarios, updated at least annually (§6.2)

• Perform integrity verification, security testing, and dependency analysis before using open-source or third-party components, and establish a component repository classified into four tiers: preferred, optional, restricted, and prohibited (§8.2.2(g))

These two tiers of regulations, one top-down and one bottom-up, are now converging. Software supply chain security has shifted from "a matter of concern for the security team" to an "enterprise compliance obligation."

PART 02

Cognitive Bias in Most Enterprises

When communicating with security teams from different enterprises, we often hear remarks like:

"We have Nexus; all packages go through our private repository."

"We have SCA scanning tools that run periodically."

"If anything happens, we will know about it immediately."

These three statements represent the most typical cognitive framework currently held by enterprises regarding software supply chain security—equating "having tools" with "having capability," and "periodic scanning" with "continuous protection."

Where is the problem?

Nexus is just a conveyor belt, not a security gate. Its core function is caching and distribution, not security auditing. A compromised developer account can push any version of an internal package into Nexus; if multiple build nodes share a cache directory, a contaminated package can quietly spread to all subsequent build tasks. Nexus itself is completely unaware of these risks.

SCA scanning is a snapshot, not real-time protection. The essence of periodic scanning is "post-event auditing"—you only learn about the issue's existence after the attack has occurred and the dependency has been introduced. In the Axios poisoning incident at the end of March 2026, the malicious version took less than 4 hours from being pushed to being officially taken down. For developers or CI pipelines that executed npm install within this 4-hour window, periodic scanning could not save them.

"Being able to know" and "being able to intercept" are two entirely different things. Threat intelligence might tell you that a package is malicious, but if a developer's working environment can directly access the public network via pip install, or if the CI pipeline can bypass the private repository and connect straight to PyPI—then the only remaining value of that intelligence is "post-event attribution."

Article 7.2.4(d) of GB/T 43698—2024 requires "obtaining installation/upgrade packages from secure and controllable channels." This means more than just "using Nexus"; it means the entire link must be controllable—including who can publish what version of a package, whether the build environment has bypassed controls, and whether internal packages have been tampered with.

PART 03

The True Form of the Supply Chain Attack Surface: Expanding in Three Directions Simultaneously

To understand why "having tools" is not enough, we first need to clearly see the structure of the attack surface currently faced by enterprises.

Direction 1: Poisoning of External Open-Source Packages — Mature and Continuously Upgrading

New malicious packages are uploaded to PyPI, npm, and Maven every day. Attack methods have evolved from simple typosquatting in the early days to modern hijacks of maintainer accounts. In the Axios poisoning incident at the end of March 2026, the attacker spent three weeks socially engineering the lead maintainer of the world's most downloaded npm library. Once the account was compromised, they pushed a backdoor-ridden version to millions of running CI pipelines globally within a few hours. The malicious code self-deleted and destroyed forensic evidence immediately after execution.

Direction 2: AI Toolchain Attacks — Emerging and Fastest-Growing

When developers use AI coding assistants such as Claude Code or Cursor, they install various Skill files to extend the assistant's capabilities. Attackers are already uploading malicious Skills in bulk to platforms like ClawHub and Anthropic Marketplace. Outwardly looking like "Python utility suites," they actually guide the AI assistant to read ~/.aws/credentials, SSH private keys, or silently inject backdoor logic into the generated code. Such attacks completely bypass the detection scope of traditional SAST/DAST tools, leaving existing security scanning frameworks with almost zero coverage.

Direction 3: Internal Artifact Repositories — The Most Covert and Overlooked

This is the least discussed and hardest-to-assess attack direction. An enterprise's own Nexus repository stores a large number of internally developed shared components—such as payment modules, authentication libraries, and utility toolkits. If any publishing account is compromised, the attacker only needs to push an "updated version" with a backdoor to Nexus, and all services relying on that component will be silently infected during their next build. This type of attack is completely invisible to external intelligence databases, which only monitor public package repositories and have no visibility into an enterprise's internal packages.

Together, these three directions form the complete picture of today's enterprise software supply chain attack surface. Without a systematic methodology covering all three directions, any single-point tool will only provide limited risk reduction in a specific area.

PART 04

Supply Chain Security Protection Methodology:

The "Perceive–Intercept–Inventory–Govern" Four-Layer Closed-Loop System

Truly effective supply chain security protection is a closed-loop system covering four layers: "Perceive–Intercept–Inventory–Govern," with each layer addressing a different core issue.

Layer 1: Real-Time Perception of Threat Intelligence

The value of intelligence lies in its precision and timeliness. It must be precise down to the package name and version number level—not just "axios is risky," but "axios@1.14.1 is malicious, while axios@1.14.0 is clean." The handling logic for the two versions is completely different; coarse-grained intelligence is as good as useless in actual practice.

Intelligence sources must cover three categories of artifacts:

• Traditional Package Repositories
  (npm / PyPI / Maven / Go / NuGet / Docker Hub, etc.): Multi-source aggregation + self-developed deep analysis, covering adversarial techniques such as obfuscated code, postinstall hooks, and dynamic module loading.

• AI Skills Platforms
  (ClawHub / Anthropic Marketplace / skills.sh / GitHub/skills, etc.): This is currently a blank spot in protection for the vast majority of enterprises and requires dedicated threat intelligence coverage.

• Abnormal Changes in Internal Packages
  Listening to ADD/UPDATE events in artifact repositories to perform out-of-band scans on internal package changes—a blind spot that external intelligence databases cannot cover.

Timeliness determines the width of the protection window. In the Axios incident at the end of March 2026, Sescin Advanced Persistent Threat Intelligence had completed indexing and threat tagging approximately 41 minutes before the malicious package was officially removed by npm. These 41 minutes represent the critical window that determines whether you are "protected" or "infected."

Layer 2: Interception at Artifact Download Nodes

The value of intelligence lies not in "being notified," but in "being protected." This requires implementing interception at the physical nodes where dependencies are downloaded, rather than sending notifications in alert emails.

Three must-cover interception checkpoints:

• Checkpoint 1 — Artifact Repository Proxy
  Deploy a transparent reverse proxy upstream of Nexus / JFrog Artifactory. The developer executes npm install as usual, but all requests pass through the intelligence decision engine. Any request hitting a known malicious package is blocked, ensuring malicious code never lands locally.

• Checkpoint 2 — VSCode Extension Marketplace Proxy
  Verification of VSCode extension installation requests via intelligence. While there have been many actual cases of malicious extensions, almost no enterprises have implemented protection at this checkpoint.

• Checkpoint 3 — AI Skills / MCP Proxy
  Verification of installation requests for AI programming tool Skills via intelligence. This is currently the newest and hardest-to-cover attack surface, as well as the fastest-growing risk direction.

For internal package poisoning, scans must be triggered by listening to Nexus events:

• New Package (ADD) → Full Scan

• Updated Package (UPDATE) → Diff Scan (scanning only the changes), reducing resource consumption while improving timeliness.

• High Risk Detected: Block publishing + link to CI/CD quality gates + auto-rollback to the previous version.

Layer 3: Risk Inventory of Existing Assets (SBOM)

When responding to sudden poisoning incidents, the first hurdle many enterprises face is: I have no idea which projects depend on the affected package, or which version is being used.

This is not a defect in the information system, but the inevitable consequence of not establishing a Software Bill of Materials (SBOM). Article 6.2 of GB/T 43698—2024 has clearly made constructing and maintaining an SBOM an enterprise obligation—important business scenarios must include component vulnerability details and be updated at least once a year.

The SBOM system must support the import of both SPDX and CycloneDX standard formats. Once imported, it should automatically correlate with the intelligence database to output which projects have affected dependencies and show the distribution of risky versions, cross-verifying with real-time interception alerts.

With an SBOM, the impact assessment of a sudden poisoning incident can be shortened from hours of manual investigation to minutes of system queries.

Layer 4: Governance of R&D Behavior — The Hardest and Most Fundamental

This is the most easily overlooked yet most fundamental layer. No matter how well the first three layers are executed, they can be easily bypassed if the "access pathways" are not controlled.

This is not a hypothetical scenario:

• A developer runs npm config set registry https://registry.npmjs.org, completely bypassing the enterprise's private repository and gateway.

• The CI/CD pipeline configuration is flawed, failing to go through the private repository proxy and connecting directly to the public network during builds.

• A developer account is leaked, allowing an attacker to push a backdoor-ridden internal package directly to Nexus.

The governance layer needs to achieve five specific objectives:

① Strict Layering of Account Permissions (The first gate to prevent internal poisoning)

② Mandatory Traffic Consolidation (Closing off the possibility of "bypassing")

• Block all original domain names of public package sources at the network layer (ZTNA / firewall)—all original addresses for npm, Maven, PyPI, and Docker Hub must be blocked without exception.

• Force all requests to go through Nexus using mirrorOf=* in Maven settings.xml.

• Consequence of non-implementation: A single line of configuration command can render all defensive lines useless.

③ Isolation of CI/CD Build Environments (Preventing lateral transmission via cache)

• Each build task must use an independent cache directory (Maven: -Dmaven.repo.local=/build/.m2/repository; npm: npm config set cache /build/.npm).

• Sharing ~/.m2 / ~/.npm directories across multiple build nodes is prohibited.

• Consequence of non-implementation: A contaminated package can spread laterally through the shared cache to all subsequent build tasks, making it extremely difficult to locate the source.

④ Integrity Recording of Internal Artifacts (Detecting "tampering in your own backyard")

• Record details for every release: SHA256 fingerprint + publisher + source IP + build Pipeline ID + timestamp.

• Periodically recalculate the hash values of packages stored in Nexus and compare them with the baseline.

• Prohibit snapshot versions from entering production: Implement automated detection during the CI phase to fail non-compliant builds directly.

• Consequence of non-implementation: Internal packages can be silently replaced with no alerts, no records, and no way to trace the source.

⑤ Source Control of AI Toolchain Skills (The newest attack surface)

• Integrate Skill sources for AI programming tools (Claude Code / Cursor, etc.) into the same level of intelligence verification workflow as code packages.

• Manage access uniformly via proxy gateways, leaving no alternative bypass routes.

PART 05

Perform a Check-Up First: Quickly Assess Your Current Completion Rate

In alignment with the requirements of GB/T 43698—2024, these five questions can help you quickly determine your current status:

None of these five items are "advanced features"; rather, they represent the baseline requirements for enterprises under GB/T 43698—2024. In actual assessments, enterprises that have completed all five items simultaneously are quite rare.

PART 06

Intelligence Is the Eyes, SOP Is the Skeleton

There is a metaphor that summarizes the core message of this article:

Intelligence is the eyes, control is the hand, and governance is the skeleton.

The eyes tell you where the threat is, and the hand allows you to intercept it, but the skeleton determines whether the entire defense system can stand—whether it can truly be implemented.

Without a skeleton, no matter how good the eyes are or how fast the hand is, it is like building a castle on sand. A Nexus repository without permission layering, a CI pipeline without traffic consolidation, or a developer workstation that can freely connect to the public network can render all prior investments completely ineffective.

GB/T 43698—2024 and State Council Decree No. 834 compel enterprises to build this "skeleton" through compliance—which is actually a positive development. The skeleton cannot be built by a single security product; it requires the collaborative efforts of the IT department, R&D teams, and security teams, backed by management support and institutionalized implementation.

The regulations have clarified the direction; the only question left is: Where will you start?

Reference Regulations and Standards

Click "Regulations" to obtain the original files of the above regulations and standards.