What we name things can change our attitude towards them. William Shakespeare may have written “What’s in a name? That which we call a rose / By any other name would smell as sweet” in Romeo and Juliet, but getting the right name for a product, team or initiative can play a substantial part in how successful it is.
Conversely, the wrong approach to branding can have a big financial impact too – Kraft Heinz included a $15 billion write-down on the value of its brands in February 2019, based on prioritizing short-term activation projects over long-term brand campaigns.
Why does this matter for IT security teams? Why should they care about what things are called? Because it changes attitudes to how and where IT security is managed.
DevOps and security – part of the process, or permeating the whole process?
DevOps is changing how IT teams organize their activities. Rather than separating developers and operations teams into distinct teams, as was the case in the past, DevOps focuses on how to streamline changes and get them into production faster. It is essential for IT security to be involved in this process.
It’s all too easy for security to get addressed after the fact. For developers, IT security is not front of mind when it comes to creating or adding to applications. According to GitLab’s Global Developer Report, only 25% of developers rated security at their organization as “good.” In contrast, 50% agreed that security vulnerabilities are mostly discovered by the security team following code being merged and in a test environment.
Security teams have to be involved in the software development process to help developers produce more secure code and stop vulnerabilities from getting into production. However, how this takes place in practice can make a huge difference to how fruitful these changes are.
It’s here that a simple thing like naming becomes important. There are two terms for how security gets embedded in DevOps – DevSecOps and DevOps Security. Depending on your mindset, you may pick either, but it’s critical to recognize that they are not interchangeable.
DevSecOps positions the security function as part of the overall software pipeline – in this, security is part of the flow from software development into production. On the other hand, DevOps Security positions the security function as being responsible for security across the whole process, from beginning to end. Depending on your team – and how you work with others – these two approaches will have different benefits and drawbacks.
DevSecOps is therefore quicker to implement, integrating directly with the developers on their work. It can make implementing security into the development process easier if it is not there to start with. It can also make it faster to get access to new builds and check that they are secure before going into production, but it can deliver a long-term limiting effect.
While the security team can get involved quickly, they are locked into a specific time and role in the process, rather than being involved throughout the whole development process. If an issue develops once the software project is passed into production, then it can be harder to stop.
Conversely, DevOps Security involves looking at the whole process and how security can be embedded in all the stages of software development and deployment. Rather than being involved at a specific point, the security teams work to make security available and used by developers as part of their workflows. This involves integrating any tooling concerned with vulnerabilities, security scanning or infrastructure into how the developers work.
This can be a harder ask for security – after all, you require development teams to change some of their working practices. However, it makes it easier to deliver security over time as it becomes a continuous process rather than a stage that software progresses through. This also makes security into part of the developer mission rather than being a barrier to get over. It also encourages more collaboration over time to improve software practices between all the teams involved.
Thinking long term around DevOps and security
Looking at DevOps and security, it’s imperative for us as security professionals to get into our users’ mindsets. This is particularly useful for developers, as being part of their workflow and providing them with insight early on in their work is just as important as spotting security issues.
By making it easier for developers to spot and fix issues before they hit the operations side of the DevOps house, security teams can deliver more value for the whole IT team.
This approach involves getting information into developers’ hands during the whole process, rather than just shifting the security process left. It will involve more work to get right, but it provides a vast amount more value back to the developers and to the business as a whole.
By looking at a DevOps Security approach rather than DevSecOps, security teams can use their influence and experience to their advantage. By examining our approach to naming things, security can think more positively for everyone.