DevOps has transformed the way businesses create new applications and updates, by enabling teams to make fast, iterative changes and adapt quickly to feedback. But, as we discussed in our last blog, the incredibly rapid dev cycles enabled by DevOps can also create new security vulnerabilities.
Bolstered by the successes enabled by this methodology, but wary of its tendency to incur security risks, many organisations are now looking to move from DevOps to a DevSecOps environment – in other words, integrating security more closely with the dev and ops teams. But what does this mean in practice, and what does a DevSecOps environment look like?
In DevSecOps, rather than being a separate stage at the end of the software development lifecycle, security runs in close parallel to all DevOps processes. In practice, this means the dev and ops teams undertake more responsibility for security in their own work.
As well as receiving comprehensive security training to help understand and avoid common mistakes, DevSecOps teams must also use additional automated security tools to find and eliminate bugs in their work as they go.
Simultaneously, the security team will routinely inspect new code for flaws and vulnerabilities at every stage of the development cycle. They also continue to create and enforce security policies, as well as coordinating incident responses, alongside more strategic security work such as risk evaluation.
But where does final responsibility lie?
While it’s vital to stress the importance of security to the development team, and provide the necessary resources to ensure these efforts are successful, DevOps teams are ultimately aiming for speed. To make them responsible for security as well is to split allegiances, which can impact workplace cohesion. So, while DevSecOps must make security the remit of all, it’s the security team that should have ultimate ownership.
As team responsibilities change, everyone must be empowered with the right tools to support their shifting roles. Automated bug-finding tools will help developers spot and fix flaws on the spot, all without having to devote excess time to carrying out manual checks. The security teams’ tools should be adapted for quick, iterative development needs with minimal interruption or additional work.
To enable strong security checks and fixes at every stage without causing significant delays, security teams must have the right technology, including automated scanning for additional flaws, dashboards for security data, and threat modelling applications. DevSecOps teams will also require the correct permissions to access management systems and make these changes as quickly as possible.
New ways of working are a key part of DevSecOps. All teams need to practice ‘failing fast’ and be prepared to quickly abandon or rebuild new code at an early stage when security flaws are discovered.
Another key principle is ‘immutable infrastructure’: when a fault in the infrastructure is discovered – rather than patching or repairing vulnerabilities while it is live – DevSecOps professionals will build a new, secure version offline. The old infrastructure is retired, and the new, more secure iteration they have developed will then be re-deployed to replace it.
Bringing everyone on board
To be accepted in the business, DevSecOps requires broader cultural change, not only in IT teams, but up to board level. Senior executives will naturally want to reward speed and adaptability in the business – after all, that’s what has driven the rapid success of DevOps.
But, it’s important to ensure that good security is prioritised to an equal level. This of course makes sense in business terms, as security breaches can lead to not only regulatory fines, but severe reputational damage, which will shake customer trust. Putting the business case to the board may also require an emphasis on the way DevSecOps helps to reduce delays for the DevOps teams.
Finding a flaw late in the development cycle can be laborious and lengthy, forcing teams to re-write hundreds or even thousands of lines of code. DevSecOps integrates security in a way that not only improves overall security but finds issues early in the DevOps cycle, reducing delays in fixing a bug during late-stage development.
The ‘Sec’ in DevSecOps must not be seen as a niggling commitment that slows down progress, but rather an important requirement that, when built into the development process, prevents greater delays or larger problems down the line.
DevSecOps: re-balancing the relationship
Successfully implementing DevSecOps relies on a re-balancing of the priorities and responsibilities of different teams in IT, and this requires a delicate, considered approach.
DevSecOps demands practitioners to improve their security practices and maintain the security of the code developed. Automation tools will go a long way to support them, but training and support from the security team (and external help where necessary) will also be vital to empowering dev and ops teams to keep security front-of-mind.
At the same time, it’s also important that these teams are not expected to be security experts themselves. Not only would this risk stepping on the toes of the security team, it takes DevOps focus too far away from developing. Security must become a collaborative effort, with the security team leading the way in avoiding errors, to transform security into a strength, rather than an obstacle.
You can learn more about how to move to a DevSecOps environment and the business value of doing so in our whitepaper, DevSecOps: How to enable security without compromise
In our collection of whitepapers, Cyberfort’s cyber consulting experts explore issues from cyber threat intelligence to incident planning and data security. Read our whitepapers to help make informed decisions for the benefit of your business.Learn more >