Advisory on Securing the Software Supply Chain and Development Workflows

What is affected, what to do

Threat actors are increasingly targeting the software supply chain. A single compromised external tool can grant attackers deep access to internal systems, leading to data theft, operational downtime, and severe reputational damage.

The available sources name no fixed version. Check the vendor guidance in the references below.

Not sure whether and how you are affected? Ask a question about this vulnerability

Metrics

Classification under NIS2 and CRA

Rule-based classification from exploitation status and severity. It does not replace a case-by-case assessment.

NIS2

NIS2 is EU Directive (EU) 2022/2555 to raise the level of cybersecurity across the Union. It substantially broadens obligations compared with the first NIS directive: more sectors, mandatory risk management, staged reporting duties and personal accountability of senior management.

Read in glossary

Handle the vulnerability in regular vulnerability handling under Art. 21(2)(e) NIS2.

CRA

The CRA is EU Regulation (EU) 2024/2847 setting horizontal cybersecurity requirements for „products with digital elements“ — from industrial controllers and software to connected consumer devices. For the first time manufacturers must ensure security across the entire product lifecycle, handle vulnerabilities and provide security updates.

Read in glossary

From 11.12.2027, Annex I Part II CRA requires manufacturers of affected products with digital elements to handle vulnerabilities without delay and provide security updates.

ISO/IEC 27001

ISO/IEC 27001 is the internationally leading standard for an information security management system (ISMS). It describes a risk-based, process-oriented framework to systematically plan, implement, review and improve information security.

Read in glossary

Control A.8.8, management of technical vulnerabilities: assess relevance to your systems, plan remediation and keep evidence.

Description

Threat actors are increasingly targeting the software supply chain. A single compromised external tool can grant attackers deep access to internal systems, leading to data theft, operational downtime, and severe reputational damage. Organisations are strongly encouraged to enforce strict governance over their internal development environments. Background Organisations are increasingly relying on third-party software and automated pipelines to build and deliver products and services. Threat actors have identified these dependencies as a vector for attack and are targeting these software supply chains. A single compromised external tool can grant attackers deep access to internal systems, leading to data theft, operational downtime, and severe reputational damage. Organisations are strongly encouraged to enforce strict governance over their internal development environments. Software Supply Chain Risk Software supply chain risks may arise from multiple points across the development lifecycle, including third-party software acquisition, package installation, build automation, API integration, and internal workflow design. Attack vectors on the cyber supply chain could be through: Compromise of Package Maintainer Account Threat actors may target legitimate package maintainers, using compromised credentials to publish trojanised versions of trusted software packages. In Mar 2026, security researchers identified a supply chain compromise affecting JavaScript HTTP client Axios . Threat actors successfully compromised the npm account of a primary Axios maintainer and published unauthorised malicious package versions to the npm registry, resulting in a global supply chain attack affecting Axios users worldwide. Malicious Dependency Injection Threat actors may further exploit access to package maintainer accounts by inserting malicious dependencies or post-install scripts into software packages. In Sep 2025, security researchers identified a supply chain compromise involving multiple compromised npm packages . The campaign began with compromise of the @ctrl/tinycolor npm package, where it was injected with a malicious self-propagating install script, bundle.js . This script took advantage of the transitive nature of package management to further infect over 180 npm packages Use of Shadow IT Internal teams may adopt external services, APIs, or software packages to speed up work. However, doing so without proper IT or security oversight, they bypass critical risk management and control management processes. As a result, teams may unknowingly expose the organisation to unquantified risk into the company's core infrastructure. Impact of Supply Chain Breach Successful breaches of the software supply chain enable threat actors to exploit a trusted path for software dissemination, leading to costly consequences: Operational Disruption and Financial Loss Threat actors may also cause disruptions to organisational IT infrastructure, compromising service availability and/or data integrity. Exposure of Credentials and Sensitive Data Once threat actors have a foothold in victim organisations, they may take steps to exfiltrate API keys and credentials, such as access tokens and SSH keys, as well as sensitive business information. Distribution of Malicious Code Malicious code can be bundled into internally produced applications and delivered to customers or downstream business users. Organisations may unknowingly be used as a vector for threat actors to distribute malware. Reputational Damage Disruptions to the organisation may diminish trust among customers, partners, and regulators. Regulatory and Compliance Consequences Failure to secure the supply chain may result in non-compliance with legal, contractual, and regulatory requirements, such as the PDPA. Recommended Measures Organisations are encouraged to implement the following measures to reduce software supply chain risk: Strengthen Governance of Software Components Visible Software Bill of Material (SBOM) . Maintain an inventory of software components, packages, services, and APIs used across development and production environments. Change Management . Establish formal change management processes that include version controls, as well as review and approval processes for the adoption of third-party software and external APIs. Deny Shadow IT . Avoid integrating tools or services into internal workflows without conducting security and compliance review. Validate Third-party Software Prefer software components that have undergone trusted internal review or validation by reputable third parties. Review package maintainers, release history, and community trust indicators before adoption. Enforce Dependency Control Integrate dependency control as a mechanism in the change management process. Use lockfiles such as package-lock.json or yarn.lock to pin dependency versions until newer updates can undergo the change management process Regularly audit dependencies for vulnerabilities and suspicious changes. Minimise unnecessary dependencies in production applications. Apply Principle of Least Privilege Ensure developer accounts, service accounts, CI/CD runners, and automated jobs operate with only the minimum privileges required. Restrict access to production secrets, cloud resources, and source repositories. Segment duties between development, testing, and production deployment roles. Secure CI/CD Pipelines Integrate security checks early in the software development lifecycle, including dependency scanning, static analysis, and threat modelling. Monitor build pipelines for unusual behaviour, unauthorised workflow changes, or unexpected network connections. Require change control and approvals for modifications to build scripts, pipeline definitions, and production deployment configurations. Protect Secrets and Credentials Do not store credentials, private keys, or tokens in source code repositories. Use secure secret management or vaulting solutions for sensitive credentials. Implement detection and alerting for accidental exposure of secrets in repositories or build environments. Continuous Monitoring Establish baselines for normal build and pipeline activity. Implement alerting for anomalous dependency updates, unusual package installation scripts, or suspicious network communications from developer and CI/CD environments. Review logs from source control, package management, CI/CD, and endpoint monitoring tools regularly. Contractual Safeguards for Third-Party Vendors If your organisation engages paid vendors or managed software providers, consider incorporating the following requirements into your contracts: Timely security patching Incident reporting Defined Service Levels for handling security events Right to Audit the vendor's compliance with contractual requirements Recommended Response Actions If a compromised package is identified in the environment, organisations should take the following actions immediately: Activate Incident Response Procedures Escalate the matter to the organisation’s incident response or security operations team. Assess whether legal, regulatory, or customer notification obligations apply. Identify Affected Systems and Dependencies Determine where the affected package has been installed or executed. Review development, test, build, and production environments for exposure. Contain and Remediate Downgrade or replace the affected package with a known safe and verified version using version locking. Remove malicious artifacts and dependencies from all impacted environments. Quarantine Affected Hosts Isolate systems confirmed or suspected to be running trojanised packages until investigation and remediation are completed. Rotate Credentials Assume that exposed environments may have suffered credential compromise. Rotate API keys, access tokens, SSH keys, environment secrets, and other sensitive credentials immediately. Conduct Threat Hunting Search for known indicators of compromise, suspicious scripts, unauthorised files, and abnormal process execution. Review outbound network traffic for suspicious domains, webhook calls, or other unexpected external communications. Review CI/CD and Build Activity Examine build and deployment logs for suspicious execution, unauthorised changes, or unusual network behaviour. Conclusion Software supply chain threats and the development environment have become significant attack surfaces. The widespread use of third-party software, coupled with increasingly sophisticated attacks targeting maintainers, dependencies, and CI/CD workflows, requires organisations to adopt a proactive and defence-in-depth approach. Organisations are encouraged to review their development workflows, strengthen controls over software procurement and package management, secure CI/CD pipelines, and ensure readiness to respond to supply chain compromise campaigns. References https://www.csa.gov.sg/alerts-and-advisories/advisories/ad-2026-001/ https://www.csa.gov.sg/alerts-and-advisories/advisories/ad-2026-002/ https://www.csa.gov.sg/alerts-and-advisories/alerts/al-2025-093/

Source: CSA/SingCERT