MAS TRM Guidelines on open source and third party code

The Monetary Authority of Singapore's Technology Risk Management Guidelines (January 2021) say a financial institution should have a policy on third party and open source code so it is reviewed and tested before integration, and should track updates and reported vulnerabilities for that code. They are guidelines, using "should", and apply to MAS regulated institutions.

What section 6.1 says

• 6.1.3: a policy and procedure on the use of third party and open source software codes should ensure they are subject to review and testing before integration into the institution's software.
• 6.1.4: to remediate vulnerabilities in a timely manner, the institution should keep track of updates and reported vulnerabilities for third party and open source code incorporated in its software.
• 6.1.6 and Annex A: a comprehensive application security testing strategy that may combine static, dynamic and interactive methods, reviewed periodically.
• 6.1.7: all issues found are tracked, and major issues remediated before production deployment.

Section 7.4 on patch management adds that patches should be implemented in a timeframe commensurate with their criticality and the criticality of the systems, and tested before production.

What the guidelines do not say

They do not name SBOMs or a specific tool. Tracking updates and vulnerabilities for incorporated code is hard to do without a component inventory, which is why most teams generate one.

The binding Singapore text for banks on patches is a separate notice. MAS Notice FSM-N06 on cyber hygiene, issued 9 May 2024 and effective 10 May 2024, says a bank must apply security patches within a timeframe commensurate with the risk of each vulnerability and, where no patch exists, put controls in place to reduce the risk. See the next post in this series.

A workable open source policy

1. Intake: who may add a new dependency and what review it gets, including licence and maintainer health.
2. Inventory: a generated list of direct and transitive components per build.
3. Monitoring: alerts when a reported vulnerability affects an inventoried component.
4. Triage: decide whether the vulnerable code is reachable in your use, and set a fix window by risk.
5. Testing: patches and upgrades run through the same tests as any change.
6. Exceptions: documented, time limited, with an owner.

What to show a Singapore customer

A short policy document, a recent inventory, a sample of tracked vulnerabilities with closure dates and the test evidence for an upgrade. That covers the three sentences of 6.1.3, 6.1.4 and 7.4 directly.

Try it yourself

Open the demo and see how reachability separates findings that matter from those that do not.

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

Safeguard provides dependency scanning, SBOMs and reachability analysis for this workflow. It does not make a firm compliant with MAS guidance.

Quick check

Sources

• MAS Technology Risk Management Guidelines, January 2021
• MAS Notice FSM-N06 on Cyber Hygiene, 9 May 2024

Last reviewed: 19 October 2026.