According to a state of agile study, 95% of organizations practice agile development methods. While agile methodologies have entailed several significant benefits, security is often not one of them.
Forrester, the analyst group, predicts that application vulnerabilities will be the most common method of external attack. And while many enterprises are trying to solve this problem – for instance, by spending money on bug bounties to identify vulnerabilities – others are not as diligent.
According to a survey by the Enterprise Strategy Group, 79% of firms push vulnerable code to production, either to meet critical deadlines or simply because they did not catch them early enough. And those who follow long checklists and compliance protocols appear to be the ones delaying releases and slowing down development.
Does this mean agility and security are at odds with each other? Absolutely not.
Shift left to achieve agile security
Leaving security to be an afterthought is one of the most common pitfalls of agile practitioners. Approaching security-as-a-need from the very beginning and addressing it when designing people (teams, structures), processes and technology systems for your application – can significantly strengthen products and offerings.
- People: champions of security
- Process: agile methods for agile problems
- Technology: automate. automate. automate
Champion security
The waterfall model has dedicated teams looking at the project through a security lens and from the outside. Agile teams and approaches do not often enjoy that ‘luxury of time.’
We recommend organizations focus on building a network of ‘Sec Champs’ or ‘security champions’ as part of their product teams. Ensure your Sec Champs have a ‘good enough to great’ understanding of application security issues and principles.
A Sec Champ’s key roles would involve:
Advocacy: they become the voice of security in every team, squad or stream. They champion the cause of security throughout the organization, keeping it top of mind for everyone.
Activity: they regularly drive threat modelling exercises within the development team to ensure everyone has security on their mind – while designing or writing code.
Operationalizing security: they ask the right questions at the right time, help with automation and ensure agile security rituals take place. They encourage security-first thinking to become muscle memory for the entire development team. For example, business analysts (BAs) cross checking key security considerations (with business) could become part of the acceptance criteria for respective stories.
Agile processes address agile challenges
To build security into the product, you need to weave it into the agile development process. One could do this by seamlessly embedding it into already existing agile rituals.
Here are some of the rituals we, at Thoughtworks follow:
Clearly outline security requirements at the beginning of any project. Of course, requirements might change as the project progresses – part of being agile. Every time it happens, involve Sec Champs or BAs who will ask the right questions to ensure security is not left out.
Put it on the story wall to ensure security needs go hand-in-hand with the functions when it needs to. This could be in the form of a security story, tech task, bug fix, a backlog or even a spike. When needed, simply add it to the Definition of Done.
Explicitly define security acceptance criteria, making them subparts of a story. Conventionally story walls discuss security only at a high level. Our recommended approach makes security a clear and quantifiable deliverable for the development team.
The review, rinse, repeat approach helps assess designs for any new feature from a security lens. Make threat modelling a ritual in itself and tie it to initial Iteration planning meetings or initial tech analysis.
Automate security whenever possible
Teams face intense pressure to not slow their releases down. In such circumstances, we have found leveraging tools, scripts and other automation techniques improve security, while also meeting required deadlines.
For instance, security issues around known vulnerable dependencies (except Zero-day), custom code (injections, XSS, etc), containers (CVEs, vulnerable libraries), application behaviour (very low hanging fruits like Dynamic Application Security Testing or DAST) etc. can be easily automated.
Additionally, there are hooks and scripts for catching secrets, security unit tests, security functional tests and other similar methods that can be used.
It is important to remember, one can not automate everything. Today’s array of tools are not yet intelligent enough to report business logic issues, authorization bypasses, API security issues, abuse of functionality, redirections etc.
Now, do this at scale
Transforming people, processes and technology systems to imbibe security at scale sounds like a gargantuan task – and for a reason. It can be difficult and time consuming. However, it is necessary to build or deliver secure software and products.
Our guidance is to build a culture of security. This will require time and investment from the organization. In our experience, the following steps have helped embed a security conscious culture at Thoughtworks:
Security should not become another program-to-follow. Those are tedious and uninteresting. The approach should be similar to a cultural transformation, aimed at building secure applications
Embrace security as a collective responsibility. Over time, it will become a part of the development practice that builds not just secure functions but secure logic as well
Make security as agile as development itself. Boundaries between development and security will eventually blur and your teams will build security into the product
Adequate security training will enhance role-specific awareness within development teams
The above described approach will require time to institutionalize. But when done, organizations are bound to notice the visible and telling rewards.
Here is a story of one such transformation, where we worked with a client to reach an optimum ‘security mindset.’ The journey began by gauging the client’s processes, identifying gaps and working towards a seamless structure.
We were involved in educating the entire team on efficiently identifying and handling threats. We automated security to ‘break the build’ when needed and set up the right processes to ensure security implementation was both timely and seamless.
The client team lived through stages of excitement, frustration, practice and maturity while on this journey. We found it extremely rewarding to see the client teams proactively address crucial security issues. Today, security is not just a part of their design and code but also their thought process, conversations and huddles.
Over a period of time the client’s project teams became self-sufficient in making security decisions, were able to identify threats and add them to the project dashboards. Sec Champs paired with developers to prioritize feedback from security tooling in their pipelines. The end result – today, the client teams are securing everything they code, design or set up right from the start.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
