2.4.1 Definition

A Source Code Review is an asset-centric security test used to identify vulnerabilities in the source code that could potentially be exploited, without proof of exploitation.

2.4.2 Qualifications

The Supplier’s code reviewers should minimally possess either of the following industry- recognised certifications.

1. Offensive Security Certified Profession (OSCP)
2. CREST Registered Tester (CRT)

In addition, the Supplier’s code reviewers should optionally have relevant certifications in secure coding practices and source code review, such as Offensive Security Web Expert (OSWE).

Lastly, the Supplier’s code reviewers should also possess the most recent “Mastering CVSS” certificate to demonstrate proficiency in assessing the severities of findings using the Common Vulnerability Scoring System (CVSS).

2.4.3 Lifecycle

2.4.3.1 Pre-engagement matters

The Customer and Supplier should agree on a clearly defined scope that contains the following:

• Objective of the SCR: Go-Live testing, testing of new features, testing of newly identified threats, routine SCR, etc.
• In-scope components (e.g. all relevant application source code): to comprehensively cover the system or application under test.
• Time and resources to be expended.
• Rules of engagement including timeline, location, personal data handling, testing hours, cooperation with the Customer’s security team, and permission to test.

The Customer and Supplier should allocate sufficient time and manpower for the source code review based on the following suggested guide. If a system exceeds the size of the Large scope, the Customer should consider breaking it up into multiple smaller scopes. The following tables serve as a guideline, and the Supplier should work with the Customer to decide on a reasonable testing duration and manpower.

2.4.3.1.2 Information

The Customer should provide the Supplier with all relevant information required for the source code review. This includes the following:

• System/product name and description.
• Security Classification and Data Sensitivity.
• All relevant application source code, including Git repositories and history if available
• Past SCR reports (at least 1), including the name of the supplier who conducted the SCR.
• Risk register, including risk acceptance with supporting evidence.
• Documentation of the various roles, privileges, and access control matrix.
• Network architecture diagram elaborating on the following details:
  • Identified network segments in scope for the test
  • Servers
  • Security controls/appliances
  • Network/data flow
• List of all expected services and ports exposed at the perimeter.
• Development and infrastructure teams: (whether in-house or from external contractors).

2.4.3.1.3 Pre-engagement logistics

The Customer should support the Supplier with the appropriate logistical requirements for the SCR. This may include the following:

• Assigning a Point-of-Contact (POC) from the Customer to liaise with the supplier on all logistical issues.
• Provisioning of source code. The Customer is responsible for ensuring that the provided source code is for the exact application/system under review, is complete, and if required by suppliers, also ensures that the provided source code can be compiled (including any dependencies/libraries).
• For on-site SCR, the following should be performed where applicable:
  • Clearance of suppliers’ testing machines
  • Provisioning of testing machines of mutually agreed upon technical specifications.
  • Provisioning of a reasonable working area with desk and chair, functional power outlet and access to bathroom facilities
• The Customer should provide an application walkthrough to the Supplier with an Application User Guide or UAT Report to support scoping.

2.4.3.2 Fieldwork

2.4.3.2.1 Methodology

Manual code review should adhere to relevant industry standards, e.g. OWASP Code Review Guide.

2.4.3.2.2 Conduct

An effective SCR involves an automated Static Application Security Testing (SAST) scan, followed by validation of the scan results. The Suppliers should also manually analyse critical sections of the source code based on knowledge of the application and identify vulnerabilities in these sections that may potentially be exploited.

The Supplier should review and validate scan results to identify and remove false positives.

The Supplier should export and furnish raw results to the Customer.

The Supplier should further identify critical sections of the source code and manually analyse them, including but not limited to:

• Code that parses attacker-controlled inputs such as HTTP requests, files, and inter-process communication.
• Code that calls dangerous functions and sinks.
• Code that may include hard-coded secrets.
• Code that may apply insecure configurations.

2.4.3.2.3 Industry tools and configurations

SCR is performed with a mix of automated and manual testing. The Supplier should perform scans using a reputable, industry recognised (e.g. Leaders in Gartner Magic Quadrant or equivalent) SAST tool. The tool should have a ruleset that supports the programming language/development framework of the source code. A non-exhaustive list is provided below as a reference:

• OpenText Fortify
• Checkmarx SAST
• Synopsys Coverity
• Semgrep
• CodeQL

The Supplier should configure the SAST scanner to be updated to the latest patch prior to the scan.

2.4.3.2.4 Fieldwork logistics

The Supplier should provide regular (e.g. weekly) status updates via email or meetings for the duration of the fieldwork.

For discovery of High/Critical severity findings, the Supplier should inform the Customer within 24 hours of the finding.

The Customer should not make changes to the source code that may impact the fieldwork in terms of behaviour or functionality, unless necessary. This includes, but is not limited to, the following:

• Remediation of identified vulnerabilities
• Feature updates
• Changes in application logic

If incremental features, additions or changes are made as part of agile development practices, the Customer should identify and log such changes for future testing. The Customer should inform the Supplier of any changes to the source code which should be taken into account during scoping.

2.4.3.3 Reporting

The Supplier should provide a report containing a list of validated vulnerabilities identified from the SAST scan. The report should minimally contain the following components:

• Sequential finding ID per scope
• Brief description of the vulnerability
• Risk Severity of the vulnerability
• The corresponding location in the source code of the identified issue
• Recommendations for remediation and/or mitigation

The Supplier should assign base metrics for reported vulnerabilities of the Common Vulnerability Scoring System (CVSS) version 3 or newer. The Suppliers may also collaborate with the Customer to assign temporal and environmental metrics to derive a more contextualised CVSS severity. Where the Customer does not agree with the CVSS severities proposed by the Supplier, the Customer should discuss and clarify with the Supplier and provide relevant input that may moderate the CVSS severities. This input should be technical and not people and process oriented. The Supplier should consider this input when validating and reviewing the findings, including their severities.

The Customer should perform a risk assessment of the identified vulnerabilities (e.g. using ICT RMM) and seek risk acceptance for findings that cannot be remediated within the established timeframe.

If required, the Supplier should validate the remediation/mitigation and provide evidence of remediation/mitigation.

The Supplier should declare any extenuating circumstances that were encountered during the fieldwork which might negatively affect the scan results (e.g. Only partial source code was provided during the SCR).

If there is insufficient time to complete the scan, the Supplier should at their discretion, request for an extension of testing duration to complete the scan.

The report should include the name and version of the scanner used, along with the last definition updates applied to the scanner in this report.

2.4.3.3.1 Prioritisation for remediation (CVSS)

The Customer should prioritise remediation based on the CVSS severities of the identified vulnerabilities in the scan report, according to the established timeframe. If the Customer is unable to complete remediation within the timeline, the Customer should perform a risk assessment (e.g. via ICT RMM) and seek risk acceptance of residual risks at the appropriate forum.

2.4.3.4 Post-engagement matters

If requested by the Customer, the Supplier should secure erase and destroy any data (including confidential information) obtained in connection with the testing.

The Customer should document and track individual findings internally (e.g. as a GitHub issue or GitLab vulnerability report.

The Customer should document and track remediation efforts internally (e.g. screenshots, code changes, configuration changes, etc).