Although DevOps was implemented within application development, there is a growing awareness that including the database within DevOps processes is vital to success. We live in a data-driven world and many front-end applications use a database at the back end to collect, process and store customer and user data.
The faster development of applications that DevOps encourages also results in more frequent updates to databases. By excluding database development from DevOps, the database becomes a counterweight to the speed of releases that otherwise can be gained.
This is already being recognized, as demonstrated in the 2019 Database DevOps Survey from Redgate, which found that 77 percent of application developers are now responsible for database development and 75 perent build database deployment scripts.
All of which is welcome news, provided DevSecOps for the database is also taken into account.
While DevSecOps is relatively new (the term was coined in 2012 by Gartner analyst Neil MacDonald), the need for it is a widely accepted facet of DevOps because DevOps radically changes how companies tackle security in application development. Whereas security used to be reviewed and certified at the end of long development cycles with a scheduled window, that window has now disappeared. Hence the rise of DevSecOps, which bakes security into the development process, with tools such as static code analyzers and open source code vulnerability scanners testing code as soon as changes are made.
In the same way that the database must be included within DevOps if the process is to be seamless, companies also need to ensure that DevSecOps is applied to the database. In fact, given the importance of protecting personal data in today’s world, ensuring privacy and security is imperative for both compliance and public reassurance.
In 2017, MacDonald continued his work on defining what DevSecOps is when he set out 10 steps that companies need to follow to protect applications during development. All of these are equally relevant to DevSecOps for the database, with the exception of the second step: Quit trying to eliminate all vulnerabilities during development. Many databases contain personal data, much of which is sensitive, so every vulnerability during database development has to be addressed and resolved.
Looking in detail at Gartner’s list, I’d say there are four key steps that particularly apply to DevSecOps for the database:
Identify the Vulnerabilities
At the center of DevSecOps for the database is the data, which has to be protected from both internal threats such as negligence or accidental exposure, and external threats such as hacking. The biggest problem with data, however, is its size and sprawl. Data is growing at an annual rate of 58 percent, according to IDC, and is now stored in a multitude of different places.
To identify what the vulnerabilities are, the data first needs to be located and classified and its risk identified. Data mapping exercises such as this can be done by hand or with a third-party tool, but it’s important to create a record of every database, including copies used in development or testing, to gain a real understanding of where data is stored and who has access to it. Classifying the data then can be undertaken to identify which data is sensitive and at risk, such as credit card details, and therefore needs to be protected.
Remove the Vulnerabilities
As we’ve seen, the recommendation to not try to eliminate every vulnerability in application development doesn’t apply to the database. Where data has been identified as sensitive and at risk, access must be limited and it cannot be widely shared.
Developers, however, often need a copy of the production database in their development, test, or QA environments to ensure changes will work once deployed. However, those same production databases invariably contain sensitive data that needs to be protected.
One solution is to create a version of the production database with a limited dataset of anonymous data. However, this means it is neither realistic, nor of a size where the impact on performance can be assessed. A second solution is to take a copy of the production database and mask the data manually, but this will age quickly as ongoing changes are deployed to the production database.
Therefore, data masking measures such as pseudonymization, encryption, anonymization and aggregation should be adopted, and companies can use third-party tools to help mask database copies, yet also provide development teams with test data that looks—and behaves—in the same way as real data.
Introduce Secure Coding
While application development typically uses an imperative programming language such as C# or Java, database development relies on a declarative language, such as T-SQL for SQL Server, which is less strict and where the coding standards vary widely.
This has resulted in developers who code in T-SQL having their own styles and preferences. With multiple developers writing updates, this often ends up with code that is confusing, difficult to understand and with errors that can cause deployments to fail.
To overcome this, code should be written in the same style, with a secure approach that follows set standards, put in place by the database administrator. Introducing this secure coding mindset at the point code is written will prevent problems later down the line.
Automate Where Possible
The ninth point in Gartner’s list is to implement strong version control on all code and components, with developers checking their changes into a common repository during the development process, preferably at the end of each working day. As a result, everyone has access to the latest version of the application, and it is always clear what was changed, when it was changed and who changed it.
This is just as true for the database code, which also can be version-controlled, preferably by integrating with and plugging into the same version control system used for applications.
Importantly, once version control is in place, processes further along the development pipeline can be automated. Continuous integration can be introduced, for example, to automatically test changes as soon as they are committed and ensure they are not breaking changes.
Data has been described as the 21st century equivalent of oil, with its use central to success in every organization. Given its sensitive nature, protecting it is equally vital. That’s why all businesses and teams need to ensure they are not only including the database within DevOps, but within DevSecOps as well.