Last year we met in Serbia. This time the amazing place can be described in three words: hot, wet, bright.
Key theses voiced together with colleagues from the financial industry during the discussion of secure development challenges:
- SSDL processes, roles and tools impact the time-to-market of a product, but it is possible to reduce the impact. For example, by automating the processes and, in some scenarios, by taking risks. In the latter case, it’s important to strike a balance between the risk appetite of the business owners (i.e. the financial and reputational losses that the business is willing to tolerate) and the requirements of the regulators.
- The “platformisation” of development is a trend that needs to be considered by any organisation developing financial software. Bringing key skills together in a platform team and then scaling them out to dev teams allows expert resources to be retained as the scale of development grows. Also, this is the right way to implement Security Champions program.
- Integrating and supporting open source or buying a commercial solution for secure development – the answer to this question relies on the economics. Building an in-house dev team to adapt an open source solution to your existing SSDL processes is a high-risk investment. Instead of instruments, it’s better to invest in processes that are tool-independent and can be supported by any instrument.
If you ask a product security engineer, what is the main entry point for an organization’s adversary to gain access to their crown jewels, he would answer: “a human.” He most likely means those employees with a low level of security awareness. In today’s reality, security engineers are the guards of employees’ security-related code of conduct. But who guards the guards?
Based on real scenarios of supply chain attacks, we’ve performed for various software developing companies, we demonstrated the weakest points of the “Agile Security” paradigm in software development lifecycle and redefine Code of Conduct for product security.
The research is presented at OWASP Israel.
В рамках всё более ускоряющегося процесса разработки не обойтись без автоматизации максимального количества контролей безопасности. Но что, если сами сервисы и средства безопасности окажутся уязвимыми и могут быть использованы для атаки?
В этом докладе, опубликованном на OWASP Moscow, мы переосмыслили типичные сценарии целенаправленных атак и рассмотрели security-инженеров и их повседневные инструменты в качестве опорной точки для атакующего. В ходе исследования выявлены недостатки конфигурации и баги в популярных security-инструментах (в том числе в инструментах с открытым исходным кодом), которые могут использоваться злоумышленником для компрометации жизненного цикла разработки программного обеспечения и краже интеллектуальной собственности.
В новом контексте тривиальные уязвимости приобретают новую ценность.