(Image: alphaspirit.it/Shutterstock)
Pitfalls in DevSecOps
“Security is one of the biggest challenges in software development,” says Davide Cioccia, senior application security architect at Veralto. He provides some best practices. “Teach security to developers and development to security.”
For IT association SAI, one of the partners of Cybersec Europe, Davide Cioccia recently shared his vision on the approach to DevSecOps, which stands for development, security & operations. DevSecOps is an approach to culture, automation and platform design that integrates security as a shared responsibility throughout the entire IT lifecycle, with development as an important aspect. “One of the most prominent pitfalls is that security is not part of development,” says Davide Cioccia.
Many organizations also have a poor security culture. “One manifestation of this is, for example, that management is not involved in discussions about security,” says Cioccia. ‘The fact that, for example, the security department is the owner of the security of the product is also a sign of the future. Just like the distribution of the workforce. For example, if there is 1 security person or expert versus 1,000 developers. Then that relationship is not right.’
Security is not an afterthought
A strong security culture starts by bringing in security experts with a development background and letting them work with the development team, Cioccia says, pointing out everyone’s role and focus. ‘The security people must understand the product tech and the business well. The development teams, in turn, own the security of their products. And management regularly talks about security.’
Another pitfall is that security is something that happens afterwards, as a kind of aftermath. “Implement security at different stages of the development cycle,” he recommends. “And teach security to developers and development to security.”
Some tools like SAST and SCA, or a combination of both, can certainly help teams. SAST (= static application security testing) mainly analyzes proprietary code for potential security risks. SCA (= software composition analysis), on the other hand, is designed to identify vulnerabilities in open source components so that organizations can remediate them before implementation or delivery. ‘But know that tools in themselves are not the solution. It is in your process. Definitely focus on that.’
Better security during development: 10 concrete pieces of advice
• Start with one or two tools (SAST and SCA) to scan your pipelines for security vulnerabilities.
• Use one maturity model and stick to it.
• Integrate vulnerabilities into developer tools (such as Jira).
• Developers are responsible for defining their pipelines.
• Don’t force one security pipeline for all.
• Only involve security in changes with a high risk.
• Do not add the security team as an approver for all Pull Request and Merge Request.
• Use a threat model that allows you to categorize and identify a range of threats.
• Identify people interested in security within your (development) team.
• Create a “Security Champions” program and curriculum for training and continuous improvement.
This article previously appeared in English in the Cybersec e-Magazine #4 (April 2024):