The year is 2022 A.C. Testing is entirely occupied by the DevOps teams. Well, not entirely… One small village of indomitable quality specialists still holds out against the invadors. And life is not easy for the DevOps teams who garrison the fortified camps of Threat Modellus, Arachnikus, Injectinus, Zapnius and OWASPnius…
Does this sound familiar? Or exaggerated? At the 2022 QSCamp in Hamburg, we headed out to understand more about the “Sec” in SecDevOps. Our keynote speaker Timo Pagel introduced to us the world of the “Sec” in Devops. But I wondered if it really is so different to functional test. Is it even a kind of resistance group, working against the DevOps team?
In his talk “DevSecOps For Architects” , Timo gave an overview of what needs to be done to integrate security testing into the overal quality process. In short, it seemed to me as if it is “just another testing qualitfication” – whith very specific questions and capabilities and tools. And introducing the Sec into DevOps seems a bit similar to the introduction of testing into the “Dev” of DevOps.
Ist Security just the New Quality?
I am sure, that security testing is not the same as other testing, nor will it replace what we traditionally understand of testing. But let me list some topics of Timo’s talk, where I see similarities:
Timo listed the dimensions of DevSecOps to consider. I see parallels to testing or its introduction:
- Culture and Organisation:
obviously also to be shaped when testing is introduced. I need testing ambassadors the same as security ambassadors. I need dedicated testing training as well security training and knowledge sharing! Threat modelling is just a very special kind of risk assessment
- Information Gathering:
when I functionally test software, I first perform a thorough analysis
- Build and Deployment:
from a security perspective the main issue is the use of open source and 3rd party commercial software and it’s impact on the composed project. I think these potentially cause problems for functionality as well. You also better build mechanisms to ensure that those components do not change adversly – for functionality and security.
On top, security questions relating to images and their hierarchy – and their impact on the deplyoed software seem to ask for similar solutions: image registry, organizational images and patch management.
- Hardening: comes from the developed applications and infrastrucure components…
- Test and Verification:
Here obviously similar mechanisms apply, however using different questions to be asked and different tools to be used. Using monitoring for bugs could be similar for monitoring (scanning) for vulnerabilities. Static Analysis would look out for security specific questions vs. general quality aspects..
So – Do We Need to Harvest Menhirs?
Obelix uses menhirs as one of the means to defeat romans. Would the security specialist also need menhirs to thrown them towards the DevOps team and the testers in there? Maybe the OWASP Web Security Testing Guide?
As the title says, it is a testing guide. So it is probably more like one of the fish of Givenix: it is used for a battle, but afterwards, everybody sits together, eats and drinks and is proud of the achieved. So we might have a gaulic village against bad quality – but quality assurance people and the security testers do eat the same wild boar!
Before I forget: I also drew a sketchnote during the talk.. :
Or does the security specialist live in fear of the sky falling on their head?