In the application security testing domain, the debate, if static application security testing (SAST) is better than dynamic application security testing (DAST) or interactive application security testing (IAST) is heating up. But is this really the right question to ask?
I think it is not. Static approaches (e.g,. SAST) and dynamic approaches (e.g., DAST or IAST) to application security testing have fundamentally different properties. Thus, the important questions is how can we combine SAST and DAST/IAST to make an applications security program as effective and efficient as possible.
The there is a long and still ongoing battle between the verification community and the testing community about the right approach to showing the correctness of computer programs. Often, one side brings up the famous quote of Edsger W. Dijkstra: “Program testing can be used to show the presence of bugs, but never to show their absence!”
This quote is often used to manifest that verification is the holy grail of program correctness and testing is necessary evil as a full verification is often too expensive (even though, there are successful verification of, e.g., complete operating system kernels). But is this true?
Let’s due a small gedankenexperiment.
The proceedings of the International Workshop on OCL and Textual Modelling (OCL 2016) are now online as Volume 1759 of the CEUR Workshop Series .
The proceedings contain 11 peer-reviewed papers presenting the latest research related to Textual Modelling in general and the Object Constrained Language (OCL) in particular. Moreover, the proceedings also contain an invited paper  that summarises the lightning talks given during the open discussion session at the workshop.
Many vendors of application security testing tools are classifying their tools based on the used testing techniques, e.g., static application security testing (SAST), dynamic application security testing (DAST) or, more recently, interactive application security testing (IAST). Is this really the information users of security testing tools actually need?
Most likely not. Customers are much more interested to get the following questions answered:
- What expertise to I need to use the tool?
- What type of security vulnerabilities can be detected?
- What type of software (frameworks, technologies, programming languages) can I test?
Finding and fixing software vulnerabilities has become a major struggle for most software-development companies. While generally without alternative, such fixing efforts are a major cost factor, which is why companies have a vital interest in focusing their secure software development activities such that they obtain an optimal return on this investment.
Thus, investigating which factors have the largest impact on the actual fix time is an important research area. To shed some light on this area, we analysed the times for fixing security vulnerabilities at SAP. The results of our study have been published in the Journal on Data Science and Engineering (DSEJ) .
During the Lightning Talk session at the OCL Workshop this year, Martin Gogolla and Jordi Cabot made an excellent point that we need to make more OCL examples available to everyone. Easily available examples will not only help in learning OCL. More importantly, they make it easier to evaluate, test and compare OCL-related tools.
This year, the OCL workshop will host an open session at the end of the day where anybody will have the opportunity to talk about whatever they want for five minutes. No formal pre-submission is required. Just send an email to email@example.com with the title and one paragraph description of what you’d like to talk about for organisational purposes.
Our presentation has the title “A Formal Methods Environment for OCL: HOL-OCL 2.0”.
The question if FLOSS (Free/Libre and Open-Source Software) is more or less secure than proprietary software is often not the right question to ask. The much more important question is: How to integrate FLOSS components securely into a Secure Software Development Process? Moreover, if you think about it, the potential challenges in the secure integration of FLOSS components are also challenges integrating other types of third-party components. As a software vendor you are finally responsible for the security of the overall product, regardless which technologies and components where used in building it (you can either read more, or watch the video of our AppSecEU presentation).