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:

1. What expertise to I need to use the tool?
2. What type of security vulnerabilities can be detected?
3. 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 analyzed 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) [1].

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 when anybody will have the opportunity to talk about whatever they want for five minutes. No formal pre-submission is required. Just email ocl16@easychair.org with the title and one-paragraph description of what you would like to talk about for organizational 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).

The DevOps model promises to allow software companies to significantly faster (i.e., more frequently) shipping updates to their customers. A key requirement for this is a high degree of test automation: This does not only apply to testing functional testing, it is at least as important for all security testing activities – which are still often done manually or semi-automated.

Specification-based sequence testing is usually associated with various kinds of automaton models. While it is intuitive to model sequential systems (or communicating systems) as automatons, there is an interesting alternative: monads. Monads have been proven to be very successful in functional programming (e.g., Haskell) for representing step-wise computations. Thus, why not use them for sequence testing?

Do you want to join a world-class computer science department and lead the establishment of a information and computer security research group? Then now is the right time to apply.