In today’s fast-paced, digital world, cybersecurity attacks occur daily. Businesses are scrambling to protect their assets and consumers fear for the safety of their personal information. Even large enterprises with ample resources and expertise aren’t safe, with LinkedIn, Yahoo, Sony, Target and the IRS all falling victim to malicious hackers. According to recent research, the average U.S. company of 1,000 employees or more spends $15 million a year battling cybercrime (up 20 percent compared to last year). Additionally, Cybersecurity Ventures estimates that global spending on cybersecurity products and services could top $1 trillion over the next five years.

Security deserves its own line item
Software delivery teams are working more and more in an Agile manner, most of which are using the Scrum framework to deliver those products. To realistically combat rising cybercrime levels, security should be part of everything we do and a required part of releasing any software.

For instance, in the Scrum framework, we have the concept of the “Definition of Done”. In the Scrum Guide, the official body of knowledge of Scrum, we talk about the “Definition of Done” as:

When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. Although this may vary significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of “Done” for the Scrum Team and is used to assess when work is complete on the product Increment.

For many Scrum teams, the “Definition of Done” includes items such as: all unit tests have been written and passed, deployment scripts have been written, product backlog item assumptions have been fully met and code has been reviewed and approved, for example.

So, where is security? Too often, organizations and their development teams assume that security is covered as part of the code review or defined in the non-functional requirements, backlog and process items for operations. The truth is, we don’t live in a perfect world where everyone clearly understand each other and everything is black-and-white. “Done” needs to explicitly call out secure coding, code scanning, security tests and any elements of security that should be implemented as part of delivering any production-ready software.

Adapt security governance for Agile environments
In addition to prioritizing security as a “Definition of Done,” organizations should automate and delegate security governance wherever possible. By moving beyond project-level governance, development teams can streamline their review process, reduce the number of handoffs and optimize overall efficiency. Instead of relying on developers to manually perform vulnerability scanning, static and dynamic scanning solutions can be implemented and plug-ins can be run passively, notifying developers if/when security issues arise.

To streamline security governance, it’s important to rethink historical training processes. Many organizations require developers to attend formal security training, however this practice can drastically hinder time-to-market. Plus, developers often have difficulty applying what they learn in these trainings to their daily work. Instead, organizations should consider monitoring individual coding behaviors, root-cause the reason for any insecure coding outcomes and design specific training plans for certain developers or teams in need.

The cost of deprioritizing security is too high
The reality is, the way most organizations currently provide security guidance to development teams (i.e. publishing security guidelines in a reference document and holding calendar-driven security training) is not very agile and misses people along the way. With Scrum, we are always inspecting and adapting how we work, which enables teams to understand what is needed and when, so that they can evolve and learn on an ongoing basis.

With data indicating that cybercrime damages could cost the world $6 trillion annually by 2021, now is the time to prioritize security once and for all. Rather than viewing security as later stage, add-on work, organizations need to consider security an essential building block of software delivery.