SECURE Software Development Guidelines

Jan 2019 CONTENT

01 Introduction 02 Secure Software Development 03 Good coding practices 04 Principles of secure code design 05 Examples

Secure Software Development Guidelines 2 01 Introduction Introduction

Information technology is part of the life-blood The purpose of this presentation is to stand on of modern-day business operations. the shoulders of existing good practices, not Organisations are dependent on reliable and replace recognised ways of secure coding. This secure communications and IT systems. guide provides an overview of good working practices and techniques for assuring the Furthermore, the secure development of development of secure software. software is essential for ensuring the confidentiality, integrity, and availability of It is impractical to eliminate all security information processed within software vulnerabilities. However, by following applications, running upon information recognised good practices, this guide will communication technologies. facilitate changes in behaviours to reduce the likelihood of main security threats.

Secure Software Development Guidelines 4 02 Secure Software Development and Standards Overview: Secure Development

“Buffer overflows”, “zero-day vulnerabilities”, Secure software development is the art, rather “SQL injection”, are all buzz-words that signify than science, of reducing the likelihood of security problems in software that have systems compromise, given known, common, allowed, for example, a website, or a fat-client insecure development practices. application to become compromised and cracked into by an organised gang, an individual for financial or reputation gain.

The sources of these attacks are many and varied (but are explored later on). However what they have in common is an open field to plough and reap financial gain from miss- configured, and insecurely programmed software applications. Secure Software Development and Standards and Development Secure Software 02

Secure Software Development Guidelines 6 Requirements in Standards

The two standards used as key motivators that 01 PCI DSS 02 ISO 27001 underpin secure development practices are: The Payment Card Industry Data Security The information security management Standard framework

PCI DSS is a formal requirement set out by This standard is generally seen (i.e. the card schemes (Visa etc) which in turn, is Information Commissioner, and the Financial regulated by the banks, who enforce the Services Authority) as the primary suggested standard upon merchants. guidance for establishing an information security management system. PCI DSS can fit Requirement six (Develop and maintain secure under ISO 27001. systems and applications) of the PCI DSS sets out prescriptive requirements for secure The standard is less prescriptive and provides development. a wider scope with regards to guidance on secure software development. Secure Software Development and Standards and Development Secure Software All these areas are explored in section 3 of this guide. 02

Secure Software Development Guidelines 7 03 Good Coding Practices Good Coding Practices

There are a plethora of good coding practices 01 CWE/SANS Top 25 software errors available from Microsoft, Oracle, and other large and small software providers on the 02 CERT Top 10 secure coding practices Internet that provide excellent direction on securing your code (these are referred to within this guide). 03 OWASP Secure coding practices checklist

Here, we explore three approaches to Good Coding Practices encourage secure coding practices. 03

Secure Software Development Guidelines 9 B. Risky Resource Management

• Classic Buffer Overflow – Buffer copy without checking size of input

• Path Traversal – Improper limitation of a pathname to a 01 CWE/SANS Top 25 Software Errors restricted directory

• Improper checking for unusual The SANS Institute has a global reputation for or exceptional conditions been neutral on products, vendors, and standards. It provides expert guidance on secure development practices, and it works with government and private sector entities alike. A. Insecure Interaction C. Porous Defences The CWE/SANS Top 25 software errors explore Between Components Good Coding Practices the fundamental failures in programming that • Improper Access • Cross-site Scripting’ or 03 promote security weaknesses and criminal Control (Authorisation) exploitation. XSS - Failure to preserve web page structure • Reliance on untrusted The CWE/SANS Top 25 group the 25 software inputs in a security errors into THREE categories: • SQL Injection’ - Failure decision to preserve SQL Query Structure • Missing encryption of sensitive data • Cross-Site Request Forgery (CSRF)

Secure Software Development Guidelines 10 01 CWE/SANS Top 25 Software Errors

A. Insecure Interaction Between This group of problems is routed in the flexibility Given that HTTP provides flexibility, the state of HTTP as web protocol. HTTP is a stateless needs to be maintained for tracking users, Components protocol, which provides a large amount of applications, and their respective preferences. freedom in developing web technologies. This This is achieved sometimes through cookies, but freedom provides significant benefits to both the also through programming techniques that lead producer of web content and consumers. E.g. to security problems such as the web server not being tied down with a connection for every individual web user; Good Coding Practices therefore, freeing up resources for other web

03 users, and in turn saving money, and improving performance.

Wherefore as if the HTTP protocol were stateful, every single user could have a dedicated and reserved connection to the server. This would, on the contrary, reduce available resources leading to more servers having to be made available, and web users having to wait for a free connection.

Secure Software Development Guidelines 11 01 CWE/SANS Top 25 Software Errors

A. Insecure Interaction Between This type of vulnerability is where a user is 2. Stored XSS (persistent) provided with what they believe to be genuine In this case, the XSS is saved within the web Components content from a website they have connected to, framework of the website, for example in a but this content is, in fact, hiding some malicious database, or uploaded via another vulnerability Cross-site Scripting’ or XSS - Failure to code or script. or access point; and preserve web page structure For example, you are directed to a website via a 3. DOM-Based XSS SQL Injection’ - Failure to preserve SQL link in an email, this link provides a URL to a bank In this case, the XSS is based upon the Good Coding Practices Query Structure you are a customer with. The link contains a link presentation object model (DOM), the XSS is

03 to the bank but, also has embedded content that embedded into the webpage, through client-side Cross-Site Request Forgery (CSRF) directs your login page to a malicious site which scripts which are altered and sent back to the captures these details, as part of some fraudulent website for processing, and come back to the or theft activity. user as looking like genuine website content.

There are three types of XSS:

1. Reflected XSS (non-persistent) Here the example given above is the “classic” XSS, however, the XSS is temporary, not stored within the website framework; Secure Software Development Guidelines 12 For further information, please refer to: http://cwe.mitre.org/data/definitions/79.html#Demonstrativ e%20Examples

01 CWE/SANS Top 25 Software Errors

A. Insecure Interaction Between A URL link below is an example of Reflected XSS for a PHP page which can be distributed by the Components attacker. The link will create a fake login box which sends login credentials to the attacker. Cross-site Scripting’ or XSS - Failure to preserve web page structure http://trustedSite.example.com/welcome.php?us ername=

Please SQL Injection’ - Failure to preserve SQL Login:

Username:
Password:

This URL link can be further obfuscated by translating the attack string to Unicode, rendering the text in the URL link human unreadable.

Secure Software Development Guidelines 13 01 CWE/SANS Top 25 Software Errors

A. Insecure Interaction Between SQL (Structure Query Language) is a simple query For example, if SQL statements are executed language that provides large amounts of without checking for input, an SQL injection to Components flexibility in querying data. This flexibility also drop tables or database can be performed. provides security drawbacks, in the sense that it Cross-site Scripting’ or XSS - Failure to is a flexible language, and innately trusting. To txtSQL = "SELECT * FROM Users WHERE UserId = preserve web page structure secure SQL, the environment upon which it exists " + txtUserId; and executes must be secured. SQL injection performed by passing “105; DROP SQL Injection’ - Failure to preserve SQL TABLE Suppliers” into txtUserId through an input Good Coding Practices Query Structure In a nutshell, an SQL injection attack is caused by field.

03 accepting and not validating an SQL query which Cross-Site Request Forgery (CSRF) has some form of untrusted extension appended to it. This is often achieved through a lack of input validation or an embedded query which has not been security checked.

An SQL query could be appended via a comment or Boolean logic extension. This could lead amongst a multitude of problems, to the “dropping” of a database, or execution of system command. Secure Software Development Guidelines 14 For further information, please refer to: http://cwe.mitre.org/top25/#CWE-352

01 CWE/SANS Top 25 Software Errors

A. Insecure Interaction Between Where a website user is already authenticated, and a session is established, e.g. a social Components networking or banking website; and a user accepts some invitation from another website or Cross-site Scripting’ or XSS - Failure to email, this invitation could be malicious. preserve web page structure Once the user has given this malicious site or SQL Injection’ - Failure to preserve SQL email link access to the user's web browser, it Good Coding Practices Query Structure uses this existing session to send messages to

03 these sites, as if they originated from the Cross-Site Request Forgery (CSRF) authenticated original website user.

Two examples of the malice that could come from this could be full access to the user's bank account, and a consequential loss of funds; or his social networking account, where pictures are uploaded or downloaded. The fallout from both these issues could be devastating.

Secure Software Development Guidelines 15 01 CWE/SANS Top 25 Software Errors

A. Insecure Interaction Between A GET request may be set up to transfer funds to Components another account. For example: GET http://bank.com/transfer.do?acct=BOB&amount= 100 HTTP/1.1

A similar GET request could be generated to Good Coding Practices mount a CSRF attack. For example: 03 GET http://bank.com/transfer.do?acct=MARIA&amoun t=100000 HTTP/1.1

This GET request can then be further embedded in anchor or image tags and included in emails.

Secure Software Development Guidelines 16 01 CWE/SANS Top 25 Software Errors

B. Risky Resource Management This group of security problems stems from a lack of input validation and bounds checking within the operating system, programming language, or web script.

Resources made available to the programming language lead themselves to be exploited by malicious code or script, providing an attacker Good Coding Practices with control over the subject system. 03

Secure Software Development Guidelines 17 For further information, please refer to: http://cwe.mitre.org/data/definitions/120.html

01 CWE/SANS Top 25 Software Errors

B. Risky Resource Management This security issue arises from when a given amount of memory for a buffer, or a variable, for example, is overrun, or overflowed. The data in that buffer then flows to the next memory Classic Buffer Overflow – Buffer copy address causing the program to crash. without checking size of input However, if that overrun of memory contains a Path Traversal – Improper limitation of a pointer to another memory address, this other Good Coding Practices pathname to a restricted directory address could contain malicious code which is

03 executed and provides the attacker with for Improper checking for unusual or example a shell to the operating system, with the exceptional conditions) privileges of the executed program.

Secure Software Development Guidelines 18 For further information, please refer to: http://cwe.mitre.org/data/definitions/120.html

01 CWE/SANS Top 25 Software Errors

B. Risky Resource Management This vulnerability allows the execution of a local system file, or access to a directory, which is generally prohibited or should be restricted. It is exploited when a malicious user provides a Classic Buffer Overflow – Buffer copy pathname to a website, either through a URL or without checking size of input through an upload dialogue.

Path Traversal – Improper limitation of By traversing the directory structure of the target, Good Coding Practices a pathname to a restricted directory e.g. a website, it may be possible to locate

03 information e.g. a password file, or learn more Improper checking for unusual or about the target, so as to gain additional access exceptional conditions) and control.

Secure Software Development Guidelines 19 For further information, please refer to: http://cwe.mitre.org/data/definitions/754.html

01 CWE/SANS Top 25 Software Errors

B. Risky Resource Management When creating a program, assumptions are made For example, the negative example below fails to as to what the expected inputs will be, and how handle the error when the IF condition is not these, or any unexpected behaviour should be met. handled. Classic Buffer Overflow – Buffer copy String os = System.getProperty("os.name"); without checking size of input When unusual input is received, and the program if (os.equalsIgnoreCase("Windows 95")) is unable to handle this input, or an exception is System.out.println("Not supported"); Path Traversal – Improper limitation of a caused, again, the program is unable to handle, Good Coding Practices pathname to a restricted directory the programme will end, either gracefully, or not,

03 depending on the exception handling in place. Improper checking for unusual or exceptional conditions) Without thorough exception handling in place, a program can be exploited for its weaknesses, and provide an attacker with access to the system the program resides upon, along with the privileges it was executed with.

Secure Software Development Guidelines 20 For further information, please refer to: http://cwe.mitre.org/data/definitions/285.html

01 CWE/SANS Top 25 Software Errors

C. Porous Defences When access is granted to an authorised user, or Ensuring that only those resources needed for trusted information is transferred across the the job role, or process purpose will reduce the internet, someone or thing (a process) has been likelihood that if authorisation and access control given authority and access to this information. If rights are exploited, appropriate access control Improper Access Control security controls are not implemented, this checks are in place. (Authorisation) authority could be abused, be it maliciously or accidently. Path Traversal – Improper limitation of a Good Coding Practices pathname to a restricted directory Post authentication, users or processes are

03 authorised, and have access to system resources, Improper checking for unusual or be these resources files, network shares, other exceptional conditions) code, or databases etc.

Secure Software Development Guidelines 21 For further information, please refer to: http://cwe.mitre.org/data/definitions/807.html

01 CWE/SANS Top 25 Software Errors

C. Porous Defences Where information which a program relies upon For example, the code below reads information can be intercepted, modified, or replayed, this from a cookie, which is susceptible to information should be validated and protected modification by an attacker. appropriately. Cookie[] cookies = request.getCookies(); Improper Access Control (Authorisation) for (int i =0; i< cookies.length; i++) { For example, if a session recording mechanism Cookie c = cookies[i]; such as a cookie is used, if that cookie is if (c.getName().equals("role")) {userRole = Reliance on untrusted inputs in a unprotected, an attacker could modify that c.getValue(); Good Coding Practices security decision cookie, and substitute the credentials of one }

03 user, for another. This could lead to either } Improper checking for unusual or elevated privileges or allow an attacker to carry exceptional conditions) out some malicious act, or blame an activity on the compromised user.

Secure Software Development Guidelines 22 For further information, please refer to: http://cwe.mitre.org/top25/#CWE-311

01 CWE/SANS Top 25 Software Errors

C. Porous Defences Properly implemented cryptography provides confidentiality, integrity, and authentication for information. Without encrypting sensitive information used for authentication, Improper Access Control (Authorisation) authorisation, or subjectively sensitive information, there are no guarantees provided, that this information cannot be intercepted, Reliance on untrusted inputs in a security manipulated, and re-used for some other Good Coding Practices decision malicious purpose. 03 Missing encryption of sensitive data Protecting information that is transferred beyond your control e.g. through the Internet, is critical to ensuring the longevity of the security within the systems programmers develop, and those systems upon which these programs connect.

Secure Software Development Guidelines 23 10. Adopt a secure 9. coding Use 02 CERT Top 10 Secure Coding standard effective quality 1. assurance Practices Input techniques validation 8. Practice defence in depth The US CERT (Computer Emergency Response Team), is one of the major lines of defense for protecting the US ICT infrastructure, for civilians, in the United States. It has a global 2. CERT Top Heed 7. reputation for cutting edge advice, and risk compiler 10 Sanitize management approach to information security warnings Secure data problems. Coding sent to other Practices systems Good Coding Practices CERT provides guidance on the top ten good

03 practices for secure coding development. 3. Architect & design for 6. security 5. Principle policies 4. Default of least Keep it deny privilege simple

Secure Software Development Guidelines 24 02 CERT Top 10 Secure Coding Practices

1. Input Validation 2. Heed Complier Warnings

Checking that input which is received from the Sanitising input can be achieved by imagining Compilers can throw up warning messages user or the expected input from another all the scenarios possible, and having an which can be incredibly useful for detecting application, is critical to preventing a program exception to handle those “bad” inputs. insecure code, increasing the amount of or script from crashing. The crashing could Thorough manual and automated testing, warnings output can assist in making the code lead to a denial of service or execution of using tools to test your error handling will help more secure, and assisting you in making your

Good Coding Practices arbitrary code from an attacker. to reduce input errors. Examples of such tools code more efficient. that can assist you are explored in the next 03 Input can be sourced from a user entering section. There will be a learning curve; habits are information into a field, but also as an XML difficult to break, but heeding feedback from message, or environmental variables, or Techniques such as regular expressions and compilers will save time in the future. numerous other sources of input. using standard open libraries can also assist in reducing the effort and amount of coding required.

Secure Software Development Guidelines 25 02 CERT Top 10 Secure Coding Practices

3. Architect & design for security policies 4. Keep it simple 5. Default deny

Creating or following standard-based software Keeping the design of your code as simple Access decisions should be based upon architecture will allow the developer to design, and as small as possible will reduce the the principle of default deny, that implement and enforce security policies. By amount of effort (and cost) taken to make an privileges are granted upon a permission separating your development and production improvement at a later date, this includes basis, rather than by exclusion. This leads environments and controlling changes between security improvements. to an increase in control around any Good Coding Practices the two, you will facilitate greater control over the change in privileges. The protection releases of software, and any bugs. Therefore scheme then used (e.g. sudoers, or access 03 reducing the weakening effects of a homogenous control lists) can make access decisions. development environment.

The same principle applies to implement a security policy, for example, if different users with different privilege sets require access to information at different times, give them each their own restricted environment, and privilege set to work within.

Secure Software Development Guidelines 26 02 CERT Top 10 Secure Coding Practices

6. Principle of least privilege 7.Sanitize data sent to other 8. Practice defence in depth systems Every processes and user should execute with Any information sent to other systems or Security and information risks can be the minimum amount of rights (least privilege) subsystems should be sanitized. Attackers may managed better, with redundant security required to execute a task. If higher privileges be able to utilise functionality within the data strategies. If one control fails the other may are required, these should be time-bound, to e.g. SQL Injection or command shell execution. prevent an attacker from exploiting a system expire when no longer required, not to be It may also be the case the receiving system or gaining unauthorised access to information. Good Coding Practices assigned permanently. This reduces the does not understand the context of which the window of opportunity for an attacker. data was sent, and does not provide For example, by securing your operating 03 appropriate protection. environments, and develop secure applications, you increase the level of security within your systems.

Secure Software Development Guidelines 27 02 CERT Top 10 Secure Coding Practices

9. Use effective quality assurance 10. Adopt a secure coding standard techniques Incorporate quality assurance techniques can Develop, implement, test and monitor a secure assist in identifying weakness and coding standard that suits your development vulnerabilities. Implementing through environment. penetration testing, vulnerability assessments, fuzzing, and source code analysis can all help Good Coding Practices reduce the likelihood of insecure coding causing system compromise, or information 03 disclosure.

Using independent assurance and external review can help tackle problems with objectivity and established assumptions.

Secure Software Development Guidelines 28 03 OWASP Secure coding practices checklist

Like CERT, the Open Web Application Security Project (OWASP) has its own checklist of secure coding practices that can be integrated into the software development lifecycle. Implementation of these practices can help to mitigate most common software vulnerabilities. Good Coding Practices The checklist is based on the premise that it is

03 much less expensive to build secure software than to correct security issues after the software package has been completed, not to mention the costs that may be associated with a security breach.

Secure Software Development Guidelines 29 03 OWASP Secure coding practices checklist

1. Input Validation Conduct all data validation on a trusted system Specify proper character sets, such as UTF-8, (e.g. the server for all sources of input

Identify all data sources and classify them into All validation failures should result in input trusted and untrusted. Validate all data from rejection untrusted sources (e.g. databases, file streams, etc.) Good Coding Practices There should be a centralised input routine for 03 the application

Secure Software Development Guidelines 30 03 OWASP Secure coding practices checklist

2. Output encoding Conduct all encoding on a trusted system (e.g. Contextually sanitise all output of untrusted the server) data to queries for SQL, XML and LDAP

Utilise a standard and tested routing for each Sanitise all output of untrusted data to type of outbound encoding operating system commands

Good Coding Practices Encode all characters unless they are known to be safe for the intended interpreter 03

Secure Software Development Guidelines 31 03 OWASP Secure coding practices checklist

3. Authentication and Require authentication for all pages and All authentication controls should fail securely resources, except those specifically intended password management to be public

Establish and utilise standard and tested Use only HTTP POST requests to transmit authentication services wherever possible authentication credentials

Good Coding Practices Segregate authentication logic from the resource being requested and use redirection 03 to and from the centralised authentication control

Secure Software Development Guidelines 32 03 OWASP Secure coding practices checklist

4. Session management Use the server or framework’s session Logout functionality should fully terminate the management controls. The application should associated session or connection only recognise these session identifiers as valid Generate a new session identifier on any re- Session management controls should use well authentication -vetted algorithms that ensure sufficient random session identifiers Good Coding Practices Set the domain and path for cookies 03 containing authenticated session identifiers to an appropriately restricted value for the site

Secure Software Development Guidelines 33 03 OWASP Secure coding practices checklist

5. Access control Use a single site-wide component to check Restrict access to protected URLs to only access authorisation. This includes libraries authorised users that call external authorisation services

Segregate privileged logic from other Deny all access if the application cannot access application code its security configuration information

Good Coding Practices Enforce application logic flows to comply with business rules 03

Secure Software Development Guidelines 34 04 Principles of Secure Code Design Threat Modelling

Modelling threats using risk modelling can in addition to the misuse cases provide clarity on potential security problems before they are designed into applications, and then have to be designed out at a later date.

OWASP uses the Microsoft method for threat modelling, using the STRIDE (classification of threats, used to qualify the type of threat) models.

Principles of Secure Code Design This model allows developers to qualitatively and quantitatively assess the risks, and the 04 likelihood of security threats, from software security issues.

Secure Software Development Guidelines 36 For further information, please refer to: https://www.owasp.org/index.php/Threat_Risk_Modeling

Threat Modelling : STRIDE

Spoofing Identity Tampering With Repudiation I nformation Denial of Service Elevation of Data Disclosure Privilege

An application must Applications should Appropriate Protecting information Applications and Ensure that users are be able to identify, not trust implicitly accounting and stored by the supporting unable to promote authorise and contain data returned from auditing should take application is critical infrastructure should their account to a a user. It must not be the user, data should place in transactions from a trust and be design to ensure higher level of possible for an be validated, and that could be security perspective. availability of privilege, such as an application to allow checked to ensure it is repudiated by a user. Ensure the resources to deliver administrative the identity of the compliant with the authentication, what has been account. Validate this Principles of Secure Code Design user to be spoofed or type of information authorisation, and promised. Threats to through an

04 assumed from expected or originally accountability of availability should be authorisation matrix, another user account. sent. users. Use quantified and ensuring that only cryptographic appropriate plans in permitted roles can protection if the risk to place to mitigate access more privileged information requires denial of service. access rights. it, and do not rely on security through obscurity to protect or hide information Secure Software Development Guidelines 37 05 Examples Examples of Secure Coding Guidelines

OWASP The Open Web Application Security Project is Example of some OWASP tools: an open community not-for-profit entity, who http://www.owasp.org/ design, test, implement and share secure Webgoat is a test environment created with coding practices for any platform or language. insecurities in mind, so as to allow testers to

Examples They are a vendor, product and services exploit security vulnerabilities and be able to agnostic, providing independent and objective recognise the main coding errors made. This is 05 advice on secure coding. in order to teach developers to recognise and therefore not reproduce the common security In addition to the Wiki site providing a range of errors in code development. guidance, they also provide tools to assist developers in testing their code. Webscarab is an intercepting proxy, allowing developers to analyse HTTP and HTTPS traffic, observe web transactions, session behaviours etc.

Secure Software Development Guidelines 39 Examples of Secure Coding Guidelines

CWE Common Weakness Enumeration is again a community-based guidance site made freely http://cwe.mitre.org/ available to the public, in order to protect the wider community from the exploitation of

Examples security vulnerabilities.

05 CWE and SANS work together to publish the top 25 coding errors, along with guidance and examples on how to prevent the most common secure coding errors.

CWE also provides a standard means for classifying security vulnerabilities, providing consistency and categorisation to make the understanding, discovery, and classification of security vulnerabilities clearer to the international community.

Secure Software Development Guidelines 40 Examples of Secure Coding Guidelines

NIST The US National Institute of Standards and Technology is globally renowned for their http://csrc.nist.gov/ definitive standards for computer security. Governments around the world refer to them

Examples in their own standards and are an authority on information security standards. 05

NIST provides guidance on security considerations in the systems development life cycle, covering all forms of a software application, not just web-based. Further detail is available from: http://csrc.nist.gov/publications/nistpubs/800- 64-Rev2/SP800-64-Revision2.pdf.

Secure Software Development Guidelines 41 Examples of Secure Coding Guidelines

Others CERT Secure Coding Standards Microsoft Secure Coding Guidelines

The CERT secure coding standards provide Microsoft provide detailed guidance on secure detailed guidance (free of charge) on the coding practices for all their development

Examples secure development of Java, C, and C++. languages, including threat models used to identify weaknesses at the design stages. 05 Available from: https://www.securecoding.cert.org/confluence These models have been recognised as good /display/seccode/CERT+Secure+Coding+Standa practice by OWASP. rds Available from: http://msdn.microsoft.com/en- us/library/d55zzx87(VS.90).aspx

Secure Software Development Guidelines 42 About Pragma

Pragma is a cyber security consultancy focused Our mission is securing your digital future, and on helping organisations secure their we offer five solutions to get there. Consult, themselves from digital risks and drive change Enable, Secure, Respond and Recover. by developing pragmatic, agile and personalised security capability. To learn more about our services, please visit our website www.pragma.sg , visit our Our world-class capabilities in cyber security LinkedIn page here or contact us at consulting, experience in technology [email protected] regulations, large scale implementation, managed security services, and incident management enable transformational work that help our clients stay secure and sustain a competitive advantage.

The above information is an overview and is not intended to be advice on any particular matter. Pragma expressly disclaims liability to any person in respect of anything done in reliance of the contents of these publications. Professional advice should be sought before taking action on any of the information contained in it. Pragma (Registration No. 201629205M) is a Private limited company registered in Singapore under the Companies Act, Chapter 50.

© 2019 Pragma Pte Ltd. All rights reserved. In this document, “Pragma Strategy” operates under the legal entity Pragma Pte Ltd.

Secure Software Development Guidelines 43