DevSecOps: the art of bringing security into the fold

QA and testers need to be first-class members of the team

The next two or three years will see continued changes in the QA and code testing roles. Security professionals in organisations where DevOps and associated practices are more advanced have already experienced this transformation, and for others it's just a matter of time. Computing spoke to representatives of two vendors in the space about the challenges of producing secure enterprise software.

Patrick Debois, director of market strategy at Snyk, a creator of security analysis tools to identify vulnerabilities in open source code, believes that testers are well aware of the need for change: "Security people have learned that it's really hard to say no all the time and not have a solution," he said.

Security people have learned that it's really hard to say no all the time and not have a solution - Patrick Debois, Snyk

As DevOps and cloud have prompted traditional developer and operations roles to morph and merge security folks have found themselves increasingly out of step. Testers want to help, they really do, but for various reasons their specialism is generally the lowest ranking in the speed-quality-security triumvirate from the point of view of developers, a blocker to getting new features out of the door. But with everyone now - metaphorically at least - in the same room, security is no longer someone else's job. Developers are having to learn more about security, and, just like ops before them, security professionals are having to learn to code.

Having developers take more responsibility for securing their own code is surely a good thing; the trouble is, only the most senior and experienced coders are really up to the mark when it comes to security.

"Security requires some level of maturity and there's a definite correlation with being a good developer and a security savvy developer," said Matias Madou, CTO and co-founder of security tools and training provider Secure Code Warrior.

Often what I see is that DevOps is not really working, and throwing security in there only makes things worse - Matias Madou, Secure Code Warrior

So, developers don't tend to be good at security and security people don't always have the firmest of grasps on the development process. Another challenge in closing the gap is that traditional security practices, such as code audits, don't sit well with the rapid iterations inherent in Agile development. While it's hard to argue against the logic of developers being responsible for securing their own work, the gaps can be hard to bridge in practice - and organisations sometimes try to do too much too soon.

"Often what I see is that DevOps is not really working, and throwing security in there only makes things worse," said Madou, adding that once DevOps is up and running secure coding should be the very next step.

DevOps is more than a decade old now and has arrived at a certain level of maturity, said Debois. And he's in a good position to judge: known as the Godfather of DevOps ("the friendly uncle kind not the mafia kind"), Debois is credited, along with Andrew Shafer, with coining the term when the pair launched their DevOpsDays training events. But if DevOps is middle-aged, DevSecOps is still suffering growing pains. There's much to be learned from the earlier merging.

"At the start of DevOps, ops were also saying, 'No, you can't get a new server, no you can't do this, no we're not going to employ this'. But their mentality has shifted to, 'Yes, how can we help you? Yes, you can do that - but you need to do it yourself'. We're at that stage with security. Security's trying to define what they can offer as a service to the developers to help them get better at security."

Starting the conversation

As ever, the first step to coming together is opening up a channel of communication. Get a conversation going around threat modelling, which is where the security team can really bring their expertise to the table, Debois advises. Security people know all about what code runs where, how it can be secured, and what the loopholes and vulnerabilities are, issues often overlooked by developers.

A few scary demos don't hurt either: "If you demonstrate a couple of these exploits, how easy they are - because they're usually dismissed as something buried deep in the code that no-one knows about - that's a really good eye-opener."

For Madou, it's about getting new developers to think about security as early as possible in their career, so that it quickly becomes an integral part of writing code.

"Learning security takes time," he said, advising coders to practice a little and often. "They need to build up that muscle memory, so a couple of hours a month or a couple of hours a week depending on the risk level and the application."

Old flaws, new strategies

Application vulnerabilities really haven't changed much over the years: the slow-moving OWASP Top 10 includes decades-old flaws such as SQL injections, poorly configured authentication and cross-site scripting, although each new language and framework brings subtle differences in the way these bugs present themselves. Some frailties are more of a problem in certain sectors or within a particular type of application, and new tactics for attacking weak points are emerging all the time. It's a subtle and complex picture, and there's a great of additional specialist knowledge for developers to acquire. They could easily become overloaded - which is where security teams can really add value, sifting out the side issues and focusing on the high-risk problems in their sector or application.

With the security professionals mostly in conversation with lead developers, the challenge then becomes one of tightening the feedback loop and making sure that knowledge spreads quickly through the ranks, Madou said. "The senior developer needs to make sure that all the junior developers know about the things to look out for and how to code them."

TDD is not about writing your test, it's about creating a better architecture - Patrick Debois

In Debois' opinion, making code more secure really requires a holistic mindset: "I learned over the years that TDD is not about writing your test, it's about creating a better architecture. It's the same thing is now with threat modelling and your people working together, it's about creating a better, more secure more layered architecture."

From reactive to proactive

Tools are part of the solution, but they can become islands. Debois foresees a new generation of security solutions that will provide instant feedback to developers from across the entire DevOps pipeline. Such solutions may emerge from the Microsoft ecosystem, he predicts, spanning something like GitHub Actions and Visual Studio and feeding back messages straight into the IDE - although worries about lock-in would doubtless result.

In the meantime, Snyk and Secure Code Warrior both provide tools that claim to give a more holistic view to developers. Snyk is moving outwards from its roots in vulnerability scanning towards a product suite approach, aggregating licencing, vulnerability and upgrade information from across its customer base with a focus on cloud native architectures. Secure Code Warrior, meanwhile, has a solution designed to push knowledge down the experience chain, storing code patterns and security measures implemented by senior developers and using these to create suggestions in real-time as similar patterns are detected in the code of more junior coders.

But it's not really about tools of course. Turning security from a largely reactive process into a proactive one is a stepwise process. Coders cannot be expected to learn security nor security professionals code overnight, but whether you call it DevSecOps, security automation or something else, making security a first-class member of the team should certainly be on the roadmap.