The Challenge
Many organisations are moving to agile delivery and changing team structures and processes to reflect these new ways of working. This presents a number of challenges for the Information Security function:
- The autonomy granted to the delivery teams can preclude traditional security assurance quality gates
- The pace of change challenges traditional security assurance methodology; including people, process and technology
- A broader selection of technology is likely to be in play, both from an infrastructure and development perspective creating a diverse portfolio to understand and secure
Common Mistakes
1. Attempt to maintain the same security gates
It’s natural to find change challenging and commonly the first response to moving to agile is the security team attempts to maintain traditional security gates and the same assurance methodology.
The outcome of this approach is it creates friction between the teams, the delivery function cannot achieve the pace expected of them and security becomes a barrier, preventing the business outcome initially intended - improved pace.
It has to be recognised that if delivery is going to be structured in a way to achieve incremental deliverables then security must react and as much as possible assure incrementally, as with all security assurance at a level appropriate to the risk.
2. Being tool focussed too early
When it’s recognised the security team is causing delays it’s common to leap to technology to solve the problem, tooling definitely has its place and is core to a successful DevSecOps capability but it should not be the first focus.
Common problems when focussing on tooling too early or implementing it too quickly are:
DevOps teams not receiving appropriate training
Delivering a security assurance tool that outputs security vulnerabilities needs to be receded by the training of DevOps to understand security vulnerabilities that can exist in code or infrastructure and how to prevent and remediate.
If this step is missed out then the outputs of the tooling won’t be actioned and investment will be wasted, if it’s done correctly this step will deliver value in preventing future issues and unlock the potential of the tooling in terms of the ability to remediate.
Security teams selecting the tooling that suits them
The security assurance tooling should be collaboratively selected, including PoCs with development, remember the key features of the assurance tooling if it is to be successful are:
- It works with the development environment including – Language in use (for SAST tooling), integration into the pipelines (API callable) and integration into ticketing systems (Jira, ServiceNow etc)
- It delivers reports that the developers understand and deem actionable
- It has a low false positive rate or is tuneable to achieve this over time
3. Not empowering the DevOps teams
When it comes to security in agile there needs to be a recognition that security is an aspect of quality and that there is a responsibility for the DevOps teams to manage security of their deliverable, with this responsibility should come support and empowerment.
Security at pace and security in agile are challenges recurring across the industry, Savanti have a wealth of experience in this area, we have integrated security into DevOps functions across large organisations and have the experience to deliver a security capability that integrates and supports agile delivery at pace, whilst reducing risk.
We’d be happy to support you on the journey, please get in touch info@savanti.co.uk or visit the chat function on our website: www.savanti.co.uk
