Digital forensic analysis of software defects

Nowadays, a large part of the activity carried out by companies and professionals depends on software applications, web platforms, management systems and software developed or configured for specific purposes. When their operation becomes the subject of dispute in legal proceedings, a forensic IT examination can assess whether the system performs the expected functions, whether it meets the applicable requirements and whether the reported incidents actually correspond to software defects.

An isolated incident, a screenshot or a support ticket is not, by itself, sufficient to conclude that a software application is not functioning correctly. The analysis may require identifying the version and configuration examined, reviewing the contractual and functional documentation, reproducing the disputed scenarios under controlled conditions and comparing the results with the available records, databases and other evidence. It is also necessary to distinguish a software defect from issues related to configuration, use, an external dependency or a new functionality that was not originally included within the scope of the project.

What do we analyse in a forensic examination of software defects?

• Technological scope, requirements and agreed scope: examination of contracts, proposals, specifications, addenda and other available documentation to determine what functions the software was expected to provide and which technical obligations had been assumed.
• Environment, version and configuration: identification of the version examined, installed components, configuration, dependencies and other conditions that may influence the behaviour of the system, documenting the restoration of the environment used for testing when appropriate.
• Functional testing and reproducibility: execution of controlled test cases, documenting the data used, the steps performed and the results obtained in order to determine whether the reported incidents can be reproduced and independently verified by another professional.
• Classification of incidents: analysis of each incident to determine whether it corresponds to a software defect, a configuration or usage issue, a version change, an external dependency or a request for functional evolution that was not originally included within the scope of the project.
• System logs, databases and traces: analysis of system logs, error messages, databases, audit trails, support tickets and other internal evidence that may help reconstruct what occurred and under what circumstances.
• Integrations and external systems: analysis of communications between the software and third-party services to determine whether an incident originates within the system itself, its configuration or the response provided by an external service.
• Source code and software components: review of source code, libraries, configuration files and other components when available and when necessary to determine the cause of a specific defect.
• Technical impact of defects: assessment of how confirmed incidents affect system functionality, data, availability, performance and overall operation, taking into account the scope of the evidence examined.
• Counter-expert analysis of software: review of expert reports and evidence submitted by another party in order to assess the methodology applied, the conditions under which the tests were performed, their reproducibility and whether the conclusions are supported by the evidence examined.