From our analysis of the Libarchive vulnerabilities, we develop the model depicted in Figure 5.1. The model describes four vulnerability causing phenomenon and three input or influencing elements into these phenomena. The four phenomena are "Dark side", blind spots, opportunistic fixes, and opportunistic solutions. The three inputs elements are the security culture and practises in the OSS project, the application context and report biases in the vulnerability reports.
In our analysis we have observed how "Dark side" phenomena can occur in low-level details application platforms and compiler details, and how blind spots occur in application complexity caused by cross-platform support and multi-archive format support. We have also observed how opportunistic fixes to one vulnerab-ility can cause new vulnerabilities, and also how opportunistic solutions to initial problems causes vulnerable code. We have also observed how the vulnerability causing phenomena can influence or be connected to each other. One example of this is how integer overflows can be caused both by low-level details not con-sidered by the developer and also through unexpected input values. We also see that opportunistic fixes and opportunistic solutions causes new "Dark side" and blind spot scenarios leading to new vulnerabilities, and we see that the "Dark side" and blind spot phenomena leads to opportunistic fixes of a vulnerability
in-57
fluenced by report biases in the vulnerability reports.
Figure 5.1:Vulnerability evolution model
Through our STS analysis we see how the OSS project security culture, and the structures and methods around this culture, influence the four vulnerability causing phenomena. As defined earlier, the security culture is the way our minds are programmed that will create different patterns of thinking, feeling and actions for providing the security process[46], and as we have seen in our STS analysis a mature security culture should include methods like secure coding guidelines and structures like structures like vulnerability disclosure policies. Together, a ma-ture security culma-ture with these methods and strucma-tures in place will decrease the room for the vulnerability causing phenomena to occur. To example, secure cod-ing guidelines and focus on common vulnerabilities in the project will increase the focus on possible vulnerable code and make the "Dark side" and blind spots phenomena less likely. Such guidelines together with a defined testing policy can also make opportunistic fixes and solutions less likely choices when implement-ing fixes or new solutions. A security disclosure policy can ensure a structured and defined handling of reported vulnerabilities, and to example ensure broader scope when fixing a security bug and decrease the chance for opportunistic fixes of these types of bugs. On the other hand, a less mature security culture with fewer methods and structures in place to support the vulnerability handling in OSS project will increase the room for the vulnerability causing phenomena to occur. From this we see that security culture in the OSS project determines the methods and structures in place around the security handling, and together the security culture and practices are an influencing element into the vulnerability causing phenomena in our model.
In the application context we find elements from the structure, methods, and machine in our STS analysis, and it is defined by the cross-platform support, the user base and used testing tools. As showed in the STS analysis, the cross-platform support covers both support for multiple operating systems, 32/64-bit platforms, and multiple file systems. The analysis also showed a connection between the user base and the cross-platform support in terms of user request for support of multiple operating systems, file systems, file formats, etc. In the case of Libarchive we saw this also included the support of vendor specific implementations of file format support, not always compliant with the file format specifications. Together with the used testing tools this forms the application context. As we have seen, the "Dark side" phenomenon is the security gap that occur between expected and actual behaviour, and in our analysis we have observed how this can happen in the low-level operations of cross-platform environments and compiler operations determined by the application context. The blind spot phenomenon is caused by unexpected input and system states not considered by the developer, and again we have observed how this phenomena is influenced by the application context and a cross-platform environment where the system complexity is increased by multi-format input causing more areas for blind spots to occur.
Last, we have also observed how report biases influence the phenomena caus-ing vulnerabilities. In our analysis we first observed report bias as a separate phe-nomena in the emergence and evolvement of vulnerabilities, and through the STS analysis we observed how report bias was caused by the structure, methods and machines through external security researchers, the use of automated testing tools and narrow security reports. We therefore put report bias as an influencing ele-ment in our model. The report bias can in itself cause a "Dark side" or blind spot.
The limited scope of a security report can hide broader details and consequences of the vulnerability and cause the developer to limit the scope of the fix to the error as described at hand. We have also observed how the use of automated test-ing tools like fuzzers can contribute to this phenomenon through security reports mainly consisting of trace and log files, and we have also seen how such secur-ity reports contributes to opportunistic fixes where the root cause is left unsolved and only the problem described in the trace file is solved. We also observe report biases in testing coverage of the code caused by the used testing tools. We find more vulnerabilities in code that can be automated tested than in code requiring manual testing. Last, we also observed that automated testing caused double re-porting, and this combined by the security bugs being reported as normal bugs in the issue tracking system caused the developer to look at these issues as any other issue where the goal was to close the issue.
As showed in our model, the report bias is also influenced by the security culture and practices and by the application context. The security culture and practices determine the vulnerability disclosure practice and the practices in use for fixing vulnerabilities. The application context determines the types of testing tools that can be applied to the application.