Advisory on Securing the Software Supply Chain and Development Workflows

Was ist betroffen, was ist zu tun

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.

Die vorliegenden Quellen nennen keine Fix-Version. Prüfen Sie die Herstellerhinweise in den Referenzen unten.

Unklar, ob und wie Sie betroffen sind? Frage zu dieser Schwachstelle stellen

Metriken

Einordnung nach NIS2 und CRA

Regelbasierte Einordnung aus Ausnutzungsstatus und Schweregrad. Sie ersetzt keine Prüfung im Einzelfall.

NIS2

NIS2 ist die EU-Richtlinie (EU) 2022/2555 zur Erhöhung des Cybersicherheitsniveaus in der Union. Sie weitet Pflichten gegenüber der ersten NIS-Richtlinie deutlich aus: mehr Sektoren, verbindliches Risikomanagement, gestufte Meldepflichten und persönliche Verantwortung der Geschäftsleitung.

Im Glossar lesen

Behandeln Sie die Schwachstelle im regulären Schwachstellenmanagement nach Art. 21 Abs. 2 lit. e NIS2.

CRA

Der CRA ist die EU-Verordnung (EU) 2024/2847 mit horizontalen Cybersicherheitsanforderungen an „Produkte mit digitalen Elementen“ — von Industriesteuerungen über Software bis zu vernetzten Verbrauchergeräten. Erstmals müssen Hersteller Sicherheit über den gesamten Produktlebenszyklus gewährleisten, Schwachstellen behandeln und Sicherheitsupdates bereitstellen.

Im Glossar lesen

Ab dem 11.12.2027 verpflichtet Anhang I Teil II CRA Hersteller betroffener Produkte mit digitalen Elementen, Schwachstellen unverzüglich zu behandeln und Sicherheitsupdates bereitzustellen.

ISO/IEC 27001

ISO/IEC 27001 ist der international führende Standard für ein Informationssicherheits-Managementsystem (ISMS). Er beschreibt einen risikobasierten, prozessorientierten Rahmen, um Informationssicherheit systematisch zu planen, umzusetzen, zu überprüfen und zu verbessern.

Im Glossar lesen

Maßnahme A.8.8, Management technischer Schwachstellen: Relevanz für Ihre Systeme bewerten, Behebung einplanen und nachweisen.

Beschreibung

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/

Quelle: CSA/SingCERT