2.5.1 Definition

A Software Composition Analysis is an asset-centric security test used to identify vulnerabilities in open-source and third-party software components used in an application that could potentially be exploited, without proof of exploitation.

2.5.2 Qualifications

The Supplier’s security testers 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 security testers 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.5.3 Lifecycle

2.5.3.1 Pre-engagement matters

2.5.3.1.1 Scoping

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

• Objective of the SCA: Go-Live testing, routine scan as part of DevSecOps, etc.
• In-scope components (e.g. package managers, manifest files, all relevant application source code, binary files, container images, etc): to comprehensively cover the system or application to be tested.
• 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 SCA 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 there may be other considerations (e.g. coding language/framework, date and status of last SCA, etc) that result in a deviation from the estimated man-effort. Therefore, the Supplier should work with the Customer to decide on a reasonable testing duration and manpower.

2.5.3.1.2 Information

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

• System/product name and description.
• Security Classification and Data Sensitivity.
• All relevant application codebases are required for the scan.
• Past SCA reports (at least 1), including the name of the supplier who conducted the SCA.
• Risk register, including risk acceptance with supporting evidence.
• Development and infrastructure teams: (whether in-house or from external contractors).

2.5.3.1.3 Pre-engagement logistics

The Customer should support the Supplier with the appropriate logistical requirements for the SCA. 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 application codebase. The Customer is responsible for ensuring that the provided codebase is for the exact application/system under review and is complete.
• For on-site SCA, 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

2.5.3.2 Fieldwork

2.5.3.2.1 Methodology

An effective SCA involves an automated scan, followed by validation of the scan results and possible actions to take.

2.5.3.2.2 Conduct

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.

2.5.3.2.3 Industry tools and configurations

The Supplier should perform SCA scans using reputable, industry recognised (e.g. Leaders in Gartner Magic Quadrant or equivalent) scanning tools. A non-exhaustive list is provided below as a reference:

• Nexus IQ
• Synopsys BlackDuck
• Mend SCA
• Snyk Open Source
• OWASP Dependency Checker

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

2.5.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 application 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
• Software version updatese and patches

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 application which should be taken into account during scoping.

2.5.3.3 Reporting

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

• Sequential finding ID per scope
• Brief description of the vulnerability, including indentified CVEs
• Risk Severity of the vulnerability
• Corresponding component in the application 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. In cases where the Customer does not agree with 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 a partial codebase was provided during the SCA).

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.5.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.5.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).