Singapore software supply chain and AI security rules: a 90-day plan

If you build, buy or run software in Singapore, three changes in the last twelve months matter most. The Cybersecurity (Amendment) Act 2024 brought its key provisions into force on 31 October 2025, so owners of critical information infrastructure (CII) now report incidents in systems their suppliers control when those systems connect to the CII, and must report incidents suspected of being caused by advanced persistent threats within 2 hours of becoming aware. The Cyber Security Agency of Singapore (CSA) replaced CCoP 2.0 with the Cybersecurity Code of Practice for Critical Information Infrastructure 2026, effective 29 July 2026, with new clauses due by 29 July 2027 and a Cyber Trust mark requirement due by 31 December 2027. And the Monetary Authority of Singapore (MAS) issued final Guidelines on Artificial Intelligence Risk Management in October 2026, while consulting on rules that would make banks and other financial institutions keep an inventory of open source and third-party components.

This guide reads each rule from its primary text, shows the evidence a supervisor or auditor will ask for, and ends with a 30/60/90-day plan that works with whatever tools you already have. It is a practical reading of public documents, not legal advice. Where a clause needs interpretation for your organisation, take it to counsel, to CSA or to your MAS relationship team.

Key takeaways

• The amended Cybersecurity Act is in force. Act 19 of 2024 took effect on 31 October 2025. Section 14 now covers incidents in the CII, in other systems the owner controls, and in supplier systems that connect to the CII.
• The fastest clock is 2 hours. CSA says CII owners must report incidents suspected of being caused by advanced persistent threats, and incidents that disrupt essential services through non-interconnected systems, within 2 hours of becoming aware.
• Audit every 2 years, risk assessment every year (section 15), each report due to the Commissioner within 30 days.
• CCoP 2026 replaced CCoP 2.0 on 29 July 2026. New clauses are due by 29 July 2027, and CII owners need Cyber Trust mark certification by 31 December 2027.
• Banks report to MAS in 1 hour (FSM-N05) and patch by risk (FSM-N06). The TRM Guidelines already ask for review and tracking of open-source code, and MAS has proposed a mandatory inventory of open-source and third-party components.
• AI is supervised in finance. MAS's final AI risk management guidelines expect an AI inventory within 12 months, including AI inside vendor products.
• The PDPA clock runs from assessment: assess within 30 calendar days, notify the PDPC within 3 calendar days.
• Safeguard capabilities in this guide are all GA: SBOM generation and analysis, SCA and vulnerability management, reachability analysis, autonomous remediation (ships switched off), policies and gates, the Compliance and GRC suite, TPRM, CSAF and VEX upload, Package Firewall, SAST and DAST, AI-BOM discovery, AI-SPM, AI Gateway, MCP Guardrail, agent identity, Trust Center, the CLI and local runner, Zero AI mode, bring your own model and air-gapped deployment.

Who this applies to in Singapore

Singapore has no single software security statute. Obligations follow what you operate, who licenses you and whose data you hold.

CII owners. The Commissioner of Cybersecurity, who heads CSA, designates computer systems as CII when they are necessary for the continuous delivery of an essential service listed in the First Schedule of the Cybersecurity Act, across sectors such as energy, water, banking and finance, healthcare, transport, infocomm, media, security and emergency services, and government. Since 31 October 2025, Part 3A also lets the Commissioner make a provider of an essential service responsible for CII that a third party owns, such as CII running on a cloud provider's infrastructure.

Other entities CSA now oversees. Part 3B covers Systems of Temporary Cybersecurity Concern, such as systems that support an election. The Act also defines major foundational digital infrastructure service providers, designated under section 18G(1) for Third Schedule services such as cloud. CSA's summary also describes a power to designate Entities of Special Cybersecurity Interest.

Financial institutions. MAS supervises banks, insurers, capital markets firms and payment providers. Binding requirements sit in notices such as FSM-N05 and FSM-N06; expectations sit in guidelines on technology risk, outsourcing and, since October 2026, AI risk management. MAS assesses firms against its guidelines in supervision.

Every organisation that handles personal data. The Personal Data Protection Commission (PDPC) enforces the Personal Data Protection Act 2012 (PDPA) across the private sector.

Suppliers to all of the above. Most vendors are not regulated directly, but section 14(1)(bb), CCoP 2026 clause 3.10.3 and MAS's open-source expectations reach them through contract clauses, questionnaires and SBOM requests.

The rules, regulator by regulator

Cybersecurity Act 2018, as amended in 2024

The Cybersecurity Act 2018 (Act 9 of 2018) came into force on 31 August 2018. Parliament passed the Cybersecurity (Amendment) Bill on 7 May 2024, and CSA announced that the key provisions of the amendment Act (Act 19 of 2024) would commence on 31 October 2025. Singapore Statutes Online shows the current version carrying that amendment.

Section 14, incident reporting. The owner of provider-owned CII must notify the Commissioner, within the prescribed period after becoming aware, of a prescribed cybersecurity incident in: (a) the CII; (b) any system under the owner's control that is interconnected with or communicates with the CII; (ba) any other system under the owner's control; and (bb) any system under the control of a supplier to the owner that is interconnected with or communicates with the CII; plus (c) any other incident type the Commissioner specifies by written direction. Section 14(2) requires detection mechanisms as set out in any applicable code of practice. Failing to report carries a fine of up to S$100,000, imprisonment of up to 2 years, or both.

The periods sit in regulations. CSA's announcement of the 31 October 2025 commencement says CII owners must report incidents suspected of being caused by advanced persistent threats, and incidents that disrupt essential services through non-interconnected systems, within 2 hours of becoming aware. Read the amended regulations for the follow-up reports that apply to your incident category.

Section 15, audits and risk assessments. At least once every 2 years from the designation notice, an auditor approved or appointed by the Commissioner must audit the CII's compliance with the Act, prescribed standards and applicable codes of practice. At least once a year, the owner must conduct a cybersecurity risk assessment. Section 15(2) requires each report within 30 days of completion.

Part 3A, third-party-owned CII. Sections 16A to 16L let the Commissioner make a provider of an essential service responsible for CII owned by someone else. Section 16F requires the CII to conform with prescribed standards, and sections 16I and 16J mirror the reporting, audit and risk assessment duties. This is how the Act follows CII into cloud and outsourced arrangements.

Cybersecurity Code of Practice for Critical Information Infrastructure 2026

CSA's codes of practice page lists one code today: the Cybersecurity Code of Practice for Critical Information Infrastructure 2026, issued on 29 July 2026. Clause 1.1.1 says it takes effect from that date, superseding previous versions, including CCoP 2.0 (4 July 2022, revised 12 December 2022).

Its compliance timeline gives existing CII owners until 29 July 2027 for the new clauses on board-level accountability (3.1.4 and 3.1.5), senior management responsibility (3.2.1 to 3.2.5), interconnected system inventory (4.1.2 to 4.1.4), monitoring (6.2.4), exercises (parts of 7.3) and Section 12 on securing CII-interconnected systems, including patch management (12.6.1). Cyber Trust mark certification is due by 31 December 2027 (3.3.1 to 3.3.3). Every other clause applies from the effective date.

The clauses that reach software and suppliers most directly:

• 3.3.1, Cyber Trust mark. A CII owner must hold Cyber Trust mark Advocate (Tier 5) or its equivalent within 24 months of designation. CSA's preamble says attacks by advanced threat actors have used enterprise systems outside the CII as entry points.
• 3.6.1, Security-by-Design. Adopt CSA's Security-by-Design Framework across the CII's development life cycle, documenting any part that does not apply.
• 3.10, Outsourcing. The owner stays accountable (3.10.1), and contracts must cover the external party's access, its duty to protect the CII and report incidents, and the owner's audit rights (3.10.3). Clause 3.10.4 requires validating that suppliers meet those terms.
• 4.1.1, Asset inventory. Record each CII asset's dependencies and connections (e), outsourced service providers (g) and cloud services (h).
• 5.10.1, Patch management. Monitor releases, verify patch integrity, test, prioritise by risk, apply in a timely manner, track progress, apply compensating controls where a patch cannot be applied, and roll back where needed.
• 5.12, Application security. Keep an approved application list reviewed every 12 months, verify application integrity before use (5.12.3), and follow OWASP or equivalent guidance for web applications (5.12.5).
• 5.14, Vulnerability assessment. Track vulnerabilities, remediate by risk (5.14.2), assess IT systems at least every 12 months and OT every 24 months (5.14.3), reassess after major changes, and give the Commissioner the report and remediation plan within 30 working days on request (5.14.5).
• 7.1, Incident management. The response plan must set out how the owner meets its reporting obligations under the Act (7.1.1(b)) and is reviewed at least every 12 months.

MAS: Technology Risk Management Guidelines

The Guidelines on Risk Management Practices for Technology Risk, usually called the TRM Guidelines, were published on 18 January 2021 and apply to all financial institutions MAS regulates. Chapter 6 is the one software teams read first.

• 6.1.1 asks for standards on secure coding, source code review and application security testing.
• 6.1.3 asks for "a policy and procedure on the use of third party and open-source software codes" so that such code is reviewed and tested before it is integrated into the institution's software.
• 6.1.4 asks the institution to track updates and reported vulnerabilities for third-party and open-source code in its software, so that vulnerabilities are remediated in a timely manner.
• 6.1.6 asks for a comprehensive application security testing strategy, with a mix of testing methods described in Annex A.
• 6.1.7 asks that issues found in code review and testing are tracked, and that major issues are remediated before production deployment.

Section 3.4 covers third-party services, section 5.3 vendor evaluation, and section 7.4 patch management.

MAS: notices on technology risk and cyber hygiene

On 9 May 2024 MAS reissued its binding technology risk notices under section 29(1) of the Financial Services and Markets Act 2022. For banks, FSM-N05 (Technology Risk Management) and FSM-N06 (Cyber Hygiene) took effect on 10 May 2024, replacing Notices 644 and 655. Other institution types have parallel notices.

FSM-N05. Unscheduled downtime of each critical system is capped at 4 hours in any 12 months (paragraph 5), with a recovery time objective of not more than 4 hours (paragraph 6). Paragraph 7 requires notice to MAS "as soon as possible, but not later than 1 hour" after discovering a relevant incident, meaning a system malfunction or IT security incident with severe and widespread impact on operations or a material impact on customer service. Paragraph 8 requires a root cause and impact analysis report within 14 days.

FSM-N06. Paragraph 4 sets six practices: secure administrative accounts; apply security patches "within a timeframe that is commensurate with the risks posed by each vulnerability", with compensating controls where no patch exists (4.2); written security standards; network perimeter controls; malware protection measures; and multi-factor authentication for administrative accounts on critical systems and internet access to customer information. Paragraph 3.1 relieves a bank only where it cannot control a system directly or through the system provider, which makes supplier contracts part of compliance.

Proposed amendments, June 2026. Consultation paper P012-2026 proposes adding requirements on IT asset management, risk assessment, capacity, change management, monitoring, offline backup and incident management. Paragraph 2.4 proposes "a comprehensive and up-to-date inventory of all of their IT assets, which includes hardware, software, cryptographic assets, open-source and third-party components." Comments closed on 31 July 2026. It is a proposal until MAS issues amended notices.

MAS: outsourcing and third-party risk

The 2016 Guidelines on Outsourcing were cancelled after 10 December 2024. Since 11 December 2024, banks follow the Guidelines on Outsourcing (Banks) together with MAS Notice 658 (and merchant banks, Notice 1121), while other institutions follow the Guidelines on Outsourcing (Financial Institutions other than Banks).

In March 2026, consultation paper P004-2026 proposed Guidelines on Third-Party Risk Management that would supersede both sets of outsourcing guidelines and extend their expectations from outsourced services to all third-party services, while Notices 658 and 1121 stay in force for banks and merchant banks. Comments closed on 20 April 2026. Until MAS issues final guidelines, the outsourcing guidelines remain the text to follow, but the direction is clear: software and service providers that are not outsourcers will be inside the frame.

MAS: Guidelines on Artificial Intelligence Risk Management

MAS consulted on these guidelines on 13 November 2025 (P017-2025) and published its response to feedback on 7 October 2026 together with the final guidelines. They apply to all financial institutions and cover board and senior management oversight, AI identification and inventory, risk materiality assessment, third-party AI, lifecycle controls, and capability and capacity, with a section on generative AI and AI agents.

Two points from MAS's response matter most for software teams. First, third-party AI is in scope, including AI incorporated within third-party products, not only AI services bought as such. Second, the timeline: unless the simplified approach in paragraph 2.3 applies, an institution should meet the oversight, identification, inventory and materiality expectations (Sections 3 and 4) within 12 months, and complete full implementation, including lifecycle controls, within 24 months. MAS adds that high-risk use cases should get appropriate lifecycle controls as soon as possible rather than at the end of the transition.

Personal Data Protection Act 2012

The PDPA applies to private sector organisations that collect, use or disclose personal data in Singapore. Three parts reach software.

• Section 24, the protection obligation, requires reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification or disposal of personal data. Most PDPC enforcement decisions turn on this section.
• Part 6A, notification of data breaches (sections 26A to 26E), came in with the 2020 amendments. Under section 26C an organisation must assess whether a suspected breach is notifiable, and the PDPC's guidance expects that assessment within 30 calendar days. Under section 26D a notifiable breach (likely to cause significant harm, or affecting 500 or more individuals) must be reported to the PDPC as soon as practicable and no later than 3 calendar days after the assessment.
• Section 4(2) and (3), data intermediaries, keep the organisation responsible for data processed on its behalf, and section 26 restricts transfers of personal data outside Singapore unless the recipient is bound to a comparable standard of protection.

The maximum financial penalty under section 48J has been S$1 million or 10% of annual turnover in Singapore, whichever is higher, since 1 October 2022 (the 10% figure applies to organisations with Singapore turnover above S$10 million).

AI governance frameworks outside finance

Outside financial services, Singapore governs AI through voluntary frameworks. IMDA's Model AI Governance Framework (second edition, 2020) covers internal governance, human involvement, operations and communication. The Model AI Governance Framework for Generative AI, launched on 30 May 2024 by IMDA and the AI Verify Foundation, sets out nine dimensions including incident reporting, testing and security. The Model AI Governance Framework for Agentic AI, announced on 22 January 2026 (version 1.5 published 20 May 2026), starts with assessing and bounding what an agent can do, whether built in-house or bought. The AI Verify Foundation maintains the AI Verify testing toolkit. On 16 October 2024, Senior Minister of State Janil Puthucheary announced that CSA was publishing its Guidelines and Companion Guide on Securing AI Systems. None is binding on its own, but supervisors, customers and tender evaluators use them as the yardstick.

What the rules ask of software and open source

Across these regimes, the same few asks repeat. None of the binding texts uses the word SBOM, and none sets a fixed number of days to fix a CVE. Each asks you to know your components, fix by risk, control suppliers and prove it. An SBOM is the most practical way to answer the CCoP's dependency record, the TRM Guidelines' open-source tracking and the component inventory MAS has proposed.

SBOMs and component inventories

No Singapore rule names the SBOM, but CCoP 2026 asks for each asset's dependencies, the TRM Guidelines ask you to track third-party and open-source code, and MAS has proposed an inventory that names open-source and third-party components. A machine-readable SPDX or CycloneDX SBOM per CII application and per release answers all three, and lets you say within the 2-hour or 1-hour window whether a newly disclosed vulnerability touches a critical system.

Vulnerability handling and patch timelines

Singapore's rules are risk-based: FSM-N06 asks for patches within a timeframe commensurate with risk, and CCoP 2026 asks for timely remediation prioritised by risk with management oversight (5.10.2). Write your own deadlines by risk tier, keep the dates, and record exceptions with compensating controls and an expiry.

Third-party and ICT supplier risk

Section 14(1)(bb) is the sharpest change: an incident in a supplier's system that connects to your CII is now yours to report. CCoP clause 3.10.3 gives you the contract terms to make that work, and clause 3.10.4 asks you to check that suppliers meet them. For financial institutions, the outsourcing guidelines and Notice 658 apply today, and MAS's proposed third-party risk guidelines would widen the scope to all third-party services. FSM-N06 paragraph 3.1 shows why the contract matters: if you could have required a provider to comply and did not, the exemption does not apply.

Incident reporting clocks

Secure development and data residency

CCoP clause 3.6.1 and TRM chapter 6 ask for security across the development life cycle: a secure coding standard, automated dependency and code checks in CI, and recorded release decisions. None of these regimes requires data to stay in Singapore as a general rule; PDPA section 26 allows transfers abroad with comparable protection.

Real public incidents in or affecting Singapore

Singapore publishes less incident detail than some jurisdictions, because CII incident reports are not public. One official account from the last three years is directly relevant.

• Telecommunications sector attack, 2024 to 2025. On 18 July 2025, Coordinating Minister for National Security K Shanmugam said that the advanced persistent threat actor UNC3886 had been detected attacking Singapore's critical infrastructure. CSA and IMDA later described a multi-agency operation, codenamed Operation CYBER GUARDIAN, which they called Singapore's largest coordinated cyber incident response to date, spanning more than eleven months and involving over 100 cyber defenders. According to CSA, all four major telecommunications operators were targeted. In one instance the actor used a zero-day exploit to get past a perimeter firewall, and it used rootkits to persist. CSA said the actor gained limited access to some critical systems but did not get far enough to disrupt services, and that there was no evidence to date that customer records were accessed or exfiltrated.
• The regulator's reading. CSA's preamble to CCoP 2026 clause 3.3 says attacks attributed to advanced threat actors have shown that enterprise systems beyond CII are increasingly used as initial entry points, which is the stated reason for the new Cyber Trust mark requirement on CII owners.

This guide draws no conclusions about what any organisation should have done beyond what these sources say.

The personas who own the problem

CISO of a CII owner. Owns the 2-hour call, the incident response plan, the section 15 audit and risk assessment, and the CCoP 2026 dates (29 July 2027 and 31 December 2027). Needs board-reportable status against each, which clauses 3.1.4 and 3.1.5 will expect anyway.

Head of AppSec or VP Engineering. Owns clause 3.6.1 and TRM chapter 6 in practice: secure development, the open-source policy, component tracking, patch timing and release gates. Needs one pipeline process that produces evidence as a by-product.

Head of technology risk at a financial institution. Owns FSM-N05, FSM-N06, the TRM Guidelines and the AI guidelines. The triggers are MAS inspections, the 1-hour notice and the 12-month AI milestone.

GRC and regulatory affairs. Maps Act sections, CCoP clauses, MAS paragraphs and PDPA sections to evidence, and watches the two open MAS consultations.

Procurement and vendor risk. Owns clause 3.10.3 terms, supplier validation, outsourcing reviews under Notice 658, and SBOM requests.

Data protection officer. Owns PDPA section 24, the 30-day assessment and 3-day notification, and data intermediary contracts.

Suppliers selling into Singapore operators and banks. Asked for incident notice terms, audit cooperation, SBOMs and vulnerability status, and needs consistent answers.

A practical 30/60/90-day plan

This plan works with or without Safeguard. Adjust it to your position: a CII owner should anchor it to the designation date and the CCoP 2026 compliance dates; a financial institution to its next MAS inspection and the AI guideline milestones.

Days 1 to 30: know what you have and fix the clocks

1. Confirm your status in writing: which systems are designated CII, designation dates, any Part 3A designation, and which MAS notices apply to your licence.
2. Build the deadline calendar: annual risk assessment, 2-yearly audit, 30-day filings, 29 July 2027, 31 December 2027, and the MAS AI milestones.
3. Write the clocks into the playbook. Define who decides whether an incident is APT-suspected or a FSM-N05 relevant incident, who calls CSA within 2 hours or MAS within 1 hour, and who starts the PDPA assessment. Run it once as a tabletop with a supplier-side incident.
4. Inventory components of every critical system with an SPDX or CycloneDX SBOM per application and container image, with end-of-life flags.
5. List the suppliers behind each critical system, flagging those whose systems connect to the CII, cloud services and AI providers.

Use this checklist the same day:

Days 31 to 60: turn inventory into decisions

1. Rank vulnerabilities by risk. Use severity, exploitability (EPSS and the CISA Known Exploited Vulnerabilities catalogue help here), exposure, data sensitivity and system criticality, and check whether vulnerable code is actually reachable before you spend an emergency change window.
2. Set patch tiers and record exceptions. For example, a tier for internet-facing critical systems with known exploitation, another for internal critical systems, a third for the rest. Each exception gets an owner, a reason, a compensating control (clause 5.10.1(g), FSM-N06 paragraph 4.2(b)) and an expiry date.
3. Add a release gate. Block a release when a critical system ships a component with a known exploited vulnerability or a disallowed licence, warn on the rest, and route exceptions through an approval record. That is the evidence for TRM 6.1.7.
4. Write the open-source policy. TRM 6.1.3 asks for review and testing before third-party and open-source code is integrated. Define intake checks, who approves new dependencies and how the approved application list in CCoP 5.12.1 is kept.
5. Update supplier contracts at renewal. Add the clause 3.10.3 terms: access, incident reporting that fits your 2-hour clock, audit rights or audit reports, plus SBOM delivery and vulnerability notice.

Days 61 to 90: make it repeatable and auditable

1. Map evidence to each CCoP 2026 clause that applies to you, and mark the clauses due by 29 July 2027.
2. Rehearse the risk and vulnerability assessments, and confirm you can deliver a report and remediation plan within 30 working days if the Commissioner asks (clause 5.14.5).
3. Prepare for the section 15 audit with dated inventories, gate decisions, exception approvals, supplier validations and drill records.
4. Close the PDPA and AI loops: data intermediary contracts, and AI materiality ratings for the 12-month milestone.
5. Report to the board on obligations, dates, open high-risk findings and exceptions.

How Safeguard does this

Everything below comes from Safeguard's offering documentation and docs.safeguard.sh, and every capability named is GA. Safeguard helps a team produce and keep the evidence these rules ask for. It does not make an organisation compliant, it is not a CSA, MAS or PDPC tool, and it holds no Singapore certification, licence, mark or government listing.

1. Choose where Safeguard runs. SaaS is multi-region (US, EU and Gov); there is no Singapore region. For teams that want code and data to stay inside their own perimeter, the GA options are private VPC or dedicated tenancy, full on-prem, and fully air-gapped deployment with the AI models running inside your environment and signed offline snapshot delivery. The air-gapped deployment docs describe how that works for environments kept off the internet.
2. Keep source code on your machines. The Safeguard CLI (GA) includes the local runner (GA): the CLI pulls the repository on your own machine, scans there and sends only encrypted results, never source code. Zero AI mode (GA) runs the whole platform deterministically with no LLM in the loop, and bring your own model (GA) lets you use a model provider your institution has already approved. For a bank working through MAS's AI inventory, a security tool that can run with AI switched off is one less AI use case to assess.
3. Generate SBOMs for every critical system. SBOM generation and analysis (GA) produces SPDX and CycloneDX from connected repositories, container registries and uploaded manifests. SCA with full transitive dependency scanning (GA) records each component's dependencies. That is the dependency record behind CCoP clause 4.1.1(e), the tracking TRM 6.1.4 asks for, and the open-source and third-party component inventory MAS proposed in P012-2026.
4. Turn on the Singapore frameworks. In Compliance, the Singapore Cybersecurity Act, MAS TRMG and Singapore PDPA framework pages are on unless you switch them off in Compliance › Manage. Each product scan checks requirements tied to the source text, such as software inventory, patch readiness and incident assessment readiness under sections 14 and 15 of the Act, open-source origin and unsupported versions under the TRM Guidelines, and breach assessment readiness under PDPA Part 6A. The Compliance and GRC suite (GA) keeps controls, evidence, tests, questionnaires, risks and vendors in one place. The pages use Safeguard's own identifiers, not CSA's or MAS's numbering, and there is no dedicated page for CCoP 2026, the MAS notices or the AI guidelines, so map those clauses yourself using the table earlier in this guide.
5. Rank and fix vulnerabilities. Vulnerability management with EPSS and CISA KEV enrichment (GA) gives you the list. Reachability analysis (GA) ranks the vulnerable code paths your application actually calls, which is the risk-based priority CCoP 5.14.2 and FSM-N06 4.2 ask for. Autonomous remediation (GA) opens tested, policy-gated upgrade pull requests, single or in bulk. It ships switched off, with every category set to Manual, so your team decides what runs on its own. SAST and DAST (GA) cover first-party code and verified running targets, which supports TRM 6.1.6 and the vulnerability assessment in CCoP 5.14. They do not replace a penetration test.
6. Gate releases and record exceptions. Policies, gates and guardrails (GA) evaluate scans with Block, Warn and Notify actions, and approvals run through time-boxed exceptions. That gives a section 15 auditor or an MAS inspector a record of what was blocked, what shipped with an approved exception, who approved it and when it expires. Policies can be written in plain English (GA). License compliance (GA) covers SPDX expressions and attribution, which feeds the open-source policy in TRM 6.1.3.
7. Collect supplier SBOMs and exploitability statements. In the Third-Party Risk Manager (GA), SBOM requests go to one vendor or many with format requirements and reminders, and a received SBOM is validated and scanned. CSAF and VEX upload (GA) puts a supplier's exploitability statements next to your findings. This supports CCoP clauses 3.10.3 and 3.10.4 and the supplier visibility that section 14(1)(bb) now demands.
8. Stop risky packages at install. Package Firewall (GA) is an install-time proxy for npm and pip that blocks malicious, typosquatted and dependency-confusion packages before they reach a build, which supports the intake review in TRM 6.1.3.
9. Inventory and govern AI. AI-BOM discovery (GA) finds AI SDK imports, model files, prompts, notebooks, MCP server configuration, inference endpoints, vector stores and agents in your code and assembles them into an AI-BOM, which is a starting point for the AI inventory MAS expects within 12 months. AI-SPM (GA) scans model artifacts in formats such as pickle, safetensors, GGUF and ONNX. AI Gateway (GA) puts LLM calls behind one gateway with prompt injection, jailbreak and PII egress guardrail policies. MCP Guardrail (GA) generates guardrail proxy URLs for MCP servers, and agent identity (GA) tracks which agent holds what access, which speaks to the IMDA agentic framework's focus on bounding what an agent can do.
10. Answer customers and auditors once. Trust Center (GA) publishes your security posture and answers questionnaires, which helps suppliers facing the same clause 3.10.3 questions from several Singapore operators. Safeguard's own posture wording is "SOC 2 Type II audit in progress" and "designed for FedRAMP High".

What Safeguard does not do

• It does not notify CSA, MAS or the PDPC. The 2-hour report, the 1-hour MAS notice and the PDPA notification are your organisation's acts. Safeguard holds the findings, component versions and timeline that feed them.
• It is not your section 15 auditor and does not certify you for the Cyber Trust mark. Safeguard keeps the evidence an approved auditor or certifier tests, and holds no Singapore mark itself.
• It does not replace penetration testing, and it does not inventory hardware, networks or OT. CCoP's inventory includes physical location and network topology, which stay in your CMDB.
• It does not decide materiality or interpret the law. Whether an incident is APT-suspected or an AI use case is material is a judgment for your accountable people and counsel.

Common mistakes

• Treating supplier incidents as the supplier's problem. Section 14(1)(bb) makes an incident in a supplier's connected system the CII owner's report.
• Working from CCoP 2.0 or citing Notices 644 and 655. CCoP 2026 superseded CCoP 2.0 on 29 July 2026; FSM-N05 and FSM-N06 replaced the old notices on 10 May 2024.
• Leaving vendor AI out of the AI inventory. MAS says third-party AI includes AI built into third-party products.
• Inventorying servers but not components. A server list does not tell you which systems carry a vulnerable library.

FAQ

What is Singapore's main cybersecurity law?

The Cybersecurity Act 2018, as amended by the Cybersecurity (Amendment) Act 2024, whose key provisions commenced on 31 October 2025. It regulates owners of critical information infrastructure, providers responsible for third-party-owned CII, systems of temporary cybersecurity concern and major foundational digital infrastructure service providers, and it licenses some cybersecurity service providers.

How fast must a CII owner report an incident in Singapore?

CSA says incidents suspected of being caused by advanced persistent threats, and incidents that disrupt essential services through non-interconnected systems, must be reported within 2 hours of becoming aware. The full schedule of follow-up reports sits in the amended regulations under section 14.

What is CCoP 2026?

The Cybersecurity Code of Practice for Critical Information Infrastructure 2026, issued by the Commissioner of Cybersecurity and effective from 29 July 2026. It supersedes CCoP 2.0. Existing CII owners must meet its new clauses by 29 July 2027 and hold Cyber Trust mark Advocate (Tier 5) certification or its equivalent by 31 December 2027.

Is an SBOM mandatory in Singapore?

No binding rule uses the term. CCoP 2026 asks for each CII asset's dependencies, the TRM Guidelines ask financial institutions to track third-party and open-source code, and MAS has proposed an inventory that includes open-source and third-party components. An SBOM is the most practical way to meet all three.

Does Singapore have an AI law?

Not a general statute. Financial institutions follow MAS's Guidelines on AI Risk Management. Elsewhere, IMDA's Model AI Governance Frameworks (including the generative AI and agentic AI frameworks), AI Verify and CSA's guidance on securing AI systems are voluntary references that supervisors and customers use.

What does the PDPA require after a breach?

Assess whether the breach is notifiable, which the PDPC expects within 30 calendar days, then notify the PDPC within 3 calendar days of that assessment if it is likely to cause significant harm or affects 500 or more people.

Must data be stored in Singapore?

Not as a general rule. PDPA section 26 allows transfers abroad with comparable protection, and MAS expects institutions to control where data goes through outsourcing arrangements.

Can Safeguard run without our code leaving our environment?

Yes. The GA options are the local runner in the CLI, which scans on your machines and sends only encrypted results, plus private VPC, on-prem and fully air-gapped deployment, with Zero AI mode if no LLM may be in the loop. There is no Singapore SaaS region.

Before you fix anything

Every rule in this guide comes back to one question: when a component in a critical system is vulnerable, how fast does a tested fix reach production, and what do you do while no upstream fix exists? The section below covers how Safeguard approaches both.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real CLI session that fixes a vulnerable dependency in a repository. It reads the finding and advisory, asks before any command that changes something, edits the manifest, runs the install and tests with approval, and pushes nothing. That is the shape of the tested, recorded fix that CCoP clause 5.10.1 and FSM-N06 paragraph 4.2 ask for.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it, and scans from the terminal. For Singapore banks and CII owners that will not grant repository access to an outside platform, this is how SBOMs and findings are produced while source code stays on your systems.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. It shows the kind of scoped agent access worth recording in an AI inventory under MAS's guidelines or the IMDA agentic AI framework.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Cybersecurity Act 2018, current version (Singapore Statutes Online)
• CSA: Cybersecurity Act
• CSA: Provisions in the Cybersecurity (Amendment) Act to come into force on 31 October 2025
• CSA: Codes of Practice (Cybersecurity Code of Practice for CII 2026)
• CSA and IMDA: Operation CYBER GUARDIAN and UNC3886
• MAS: Guidelines on Risk Management Practices, Technology Risk (18 January 2021)
• MAS: Notice FSM-N05 Technology Risk Management
• MAS: Notice FSM-N06 Cyber Hygiene
• MAS: Consultation Paper P012-2026 on proposed amendments to notices on technology risk management
• MAS: Guidelines on Outsourcing (Banks)
• MAS: Guidelines on Outsourcing (Financial Institutions other than Banks)
• MAS: Consultation Paper P004-2026 on proposed Guidelines on Third-Party Risk Management
• MAS: Response to feedback on Guidelines on AI Risk Management, 7 October 2026
• Personal Data Protection Act 2012 (Singapore Statutes Online)
• PDPC: Guide on managing and notifying data breaches under the PDPA
• IMDA: Model AI Governance Framework for Agentic AI
• AI Verify Foundation: Model AI Governance Framework for Generative AI
• CSA: Keynote by SMS Janil Puthucheary at the SICW High-Level Panel on AI, 16 October 2024
• Safeguard docs: Singapore Cybersecurity Act framework
• Safeguard docs: MAS TRMG framework
• Safeguard docs: Singapore PDPA framework
• Safeguard docs: CLI and local runner
• Safeguard docs: Air-gapped deployment
• Safeguard docs: AI-BOM discovery
• Safeguard docs: TPRM SBOM requests

Related reading: Singapore Cybersecurity Act and the software supply chain, the Singapore Cybersecurity Act in plain language, MAS Technology Risk Management Guidelines in plain language, MAS TRM Guidelines and open source policy, the MAS cyber hygiene controls for banks and, from this series, Japan software supply chain and AI security rules.

To try it, download Safeguard at https://safeguard.sh/download and read the documentation at https://docs.safeguard.sh/docs .

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.