Adapting the OWASP Top Ten for database deployment security

In application development and data pipelines, risks to the security, compliance, and safety of digital products, databases, and information are nearly endless. Protecting these pipelines is critical, but where does a team begin to assess its security posture?

OWASP, the Open Worldwide Application Security Project, provides roadmaps to effectively minimize the most critical threats. Its Top Ten Security Risks lists are considered the standard consensus of the baseline security risks across the industry. 

Yet, there is no “OWASP Top Ten for Database Change Management,” leaving data store updates vulnerable and without foundational security guidance. 

Let’s change that.

Here are Liquibase’s top 10 database change management & deployment security risks, OWASP-style. Plus, how to extend automation, governance, and observability to database pipelines to optimize for security. 

First, an overview of the Top Ten Web Application and Data Security Risks helps clarify the database security gap. 

What is the OWASP Top Ten?

The OWASP Top Ten primarily refers to the Top Ten Web Application Security Risks. Collecting data from application development organizations, OWASP analyzes common weaknesses to outline and prioritize the security threats most common and painful to these teams. The organization formed in 2003, released the first Top Ten in 2017, and updated this list in 2021, as below. 

Whether it’s used as the team’s first step, like an assessment checklist, or integrated into existing security programs, this list gives the organization confidence that it’s adequately protecting its applications from internal, external, and unintended threats. The team might even build their own OWASP checklist combining risk from multiple lists. 

The OWASP Top Ten helps organizations shift left – bring security and testing closer to development rather than deployment and monitoring (the “right”). It supports DevSecOps and helps identify breaks in security continuity throughout the pipeline. 

Here are the top risks for web application developers via OWASP (2021):

1. Broken access control: Weak or ineffective user permission restrictions that expose data and systems
2. Cryptographic failures (sensitive data exposure): Inadequate or outdated encryption that weakens data protection and exposes systems 
3. Injection: Bugs in the code or platform that allow untrusted or unprocessed data to interfere with code execution, like SQL injection
4. Insecure design: Often caused by a lack of DevSecOps-style integration (shifting security left), issues with application design that open up security risks
5. Vulnerable and outdated components: Integrating technology with known risks or inadequate security capabilities
6. Identification and authentication failures: Flaws in authentication mechanisms
7. Software and data integrity failures: Failure to protect code and data from unauthorized changes, often caused by quickly scaling data journeys and development lifecycles
8. Security logging and monitoring failures: Missing or inadequate logging leads to undetected breaches and ineffective resolutions
9. Server-Side Request Forgery (SSRF):  An attacker tricks a server into making unauthorized requests to unintended resources, potentially exposing sensitive data or systems

The list above captures the most pressing issues for application development. The next update to this list has just completed data collection in June 2024 and should be released in early 2025. 

OWASP also took the same approach to data security in 2023. Here are the Top Ten Data Security Risks:

1. Injection attacks: Malicious code or commands compromising data integrity
2. Broken authentication and access control: Weak controls allowing unauthorized data access
3. Data breaches: Unauthorized data disclosure or theft
4. Malware and ransomware attacks: Infections compromising data
5. Insider threats: Unauthorized data misuse by insiders
6. Weak cryptography: Inadequate encryption making data vulnerable to exposure
7. Insecure data handling: Improper data storage or transmission
8. Inadequate third-party security: Vulnerabilities through third-party vendors
9. Data inventory and management: Poor asset management risking data security
10. Non-compliance: Failure to adhere to data protection laws

Obviously, this list has a specific focus on data, but many of the risks are fundamentally the same as those on the developer’s list. The application development Top Ten might veer more towards protecting from external attackers getting access through application interfaces. The data security Top Ten might target more internal elements, such as insider misuse or breaks from compliance regulations. 

OWASP has developed similar lists tailored to CI/CD pipelines, Large Language Models (LLMs), and other environments. But there’s no OWASP Top Ten specifically for Database Change Management and Deployment – so we’ll pose our own. 

Top 10 database change management & deployment security risks (OWASP-style)

Updates to database schemas are increasingly intertwined with application pipelines – they’re happening more often and include more complex evolutions. And every change can introduce a new security vulnerability. Why wouldn’t database change management receive the same level of scrutiny when keeping the pipeline and data secure?

Part of the problem is the manual database change review workflow that limits the speed and efficacy of security reviews. Slow and error-prone, existing database change tends to be inadequate and unreliable with automation that fails to actually add value. While significant attention and resources are dedicated to securing application development and operations, the database — where breaches can be equally devastating — often lacks adequate safeguards.

Applying the OWASP Top Ten framework to database change management allows teams to take a thorough and focused approach to shoring up database security and compliance. Just as the OWASP lists provide clear guidance for application development and data security, a similar approach completes the organization’s security assessment by including the database. 

By identifying and prioritizing the top security risks in database change management, teams can ensure that their entire pipeline — from development to deployment — is secure, reliable, and efficient. This perspective not only enhances security but also aligns change management processes with modern DevSecOps practices, ensuring that database updates are as robust and trustworthy as the rest of the application stack.

Here is Liquibase’s list of the Top 10 database change management & deployment security risks.

1: Injection attacks

Databases are also susceptible to injection attacks if a malicious user tries to get into secured areas of the organization’s data stores through manipulative application-end queries. These users can then manipulate, steal, expose, or delete data with unauthorized access and control over certain database sections. To prevent these attacks, database change management workflows need to include validations and checks that catch access and query issues proactively. 

As database changes move through the pipeline, the earlier vulnerabilities can be tested and addressed, the better. 

2: Broken authentication & access control

Similar to injection attacks, databases are also at risk of breach due to unauthorized access stemming from insufficient or improperly configured controls. Weak or failing authentication methods can give external actors access to internal data or give too much access to internal users. Either way, the ability to view, modify, remove, or expose data and adjust database management settings needs to be closely guarded and continuously tested. 

In the database change management workflow, the same levels of control need to be enabled through credentials vaults and other integrations that enforce rolebased access controls and separation of duties. 

3: Cryptographic failures (sensitive data exposure)

Maintaining robust data encryption and integrity as databases and applications evolve might seem like a no-brainer, but poses a host of challenges in the real world. With more frequently changing application codes and database structures, maintaining comprehensive encryptions as data moves through modern data pipelines requires a concerted approach. 

Especially as these pipelines grow to include more unstructured data stores and duplicate across cloud and ephemeral environments, managing and maintaining encryption poses a challenge to database teams yet a major risk to the entire organization. 

4: Insecure design

Is the database, or the change management workflow, architecturally vulnerable? Structural designs, or changes to database schemas, may introduce chinks in the armor of a previously rock-solid, secure database. For instance, a poorly designed schema might allow SQL injection vulnerabilities or fail to properly isolate user data – problems 1 and 2 on this list. Addressing insecure design involves conducting thorough threat modeling during the design phase, implementing DevSecOps best practices, and regularly reviewing the database architecture – and every schema change – to ensure it remains secure.

5: Security misconfiguration

Security misconfigurations in database changes occur when updates to schemas, settings, or environments inadvertently introduce vulnerabilities. This can happen during routine updates, migrations, or new deployments. Database change management workflows can mitigate this risk by incorporating automated security checks, robust governance, and reliable validation processes. By integrating these safeguards, teams can maintain database security integrity while accommodating evolving data structures and operational needs.

6: Vulnerable & outdated components

Whether database versions itself or libraries, plugins, and integrations at the database and throughout the change management workflow – every component needs to be secure and up-to-date if any of the pipeline is to be. Attackers can and will exploit known security vulnerabilities. A balanced approach to keeping up with recent releases and continuously running security checks as schemas change are critical. 

7: Software & data integrity failures

What if a malicious or accidental change to database schema leads to corruption, data loss, or exploitation? Integrity failures can result from insufficient validation of changes, lack of version control, or insecure deployment processes. For example, if schema changes are not adequately reviewed and tested, they could introduce vulnerabilities or disrupt application functionality or security. To ensure integrity, teams must implement consistent change management practices, use checksums to verify data integrity, and employ robust version control systems.

8: Security logging & monitoring failures

If database change management activities aren’t adequately tracked, monitored, and analyzed, then suspicious activities or unauthorized access can go completely unnoticed and unresolved. Not only can this let incidents slip by undetected, but it can delay response times beyond acceptable limits and lead to increased fallout from the breach or attack. For instance, if a database does not log failed login attempts, brute-force attacks might continue unchecked.

Comprehensive database observability for change management can ensure teams have constant visibility, proper alerts, and detailed operational reports that support security analysis. Effective logging involves capturing all relevant events, such as access attempts and changes to sensitive data, and monitoring these logs for signs of malicious activity. Logs should be stored securely and reviewed regularly. Ideally, they would be integrated into broader monitoring dashboards. 

9: Insecure data handling

Data needs to be protected as it is accessed, stored, transformed, transmitted, and analyzed. The same is true for database schemas, which can introduce even more widespread architectural issues if vulnerabilities are exploited or unintentional changes go unchecked. 

As changes to database schema move through the pipeline, they need to undergo testing, validation, and review that ensures encryption and other security features remain intact. Integrating DevSecOps practices into change management while connecting with secure vaults and other tools helps avoid changes that can enable attackers to intercept, steal, or manipulate data.

10: Noncompliance with regulations

Security risks aren’t the only ones on the team’s mind when thinking about compliance. The reputational, legal, technical, punitive, and other costs associated with compliance missteps make adherence critically important to the business. If schema changes fail to protect sensitive data according to prescribed standards or maintain required access controls, unauthorized access is only the start of the organization’s concerns. 

To avoid non-compliance, databases must be configured and managed in accordance with relevant regulations, with regular audits and updates to ensure ongoing adherence. As schemas evolve, they need to be efficiently and reliably reviewed for adherence and maintain granular logging data that enables easier, faster audits. 

Automate security for database change management

The answer to the security question in the database is the same as that of application development pipelines: automation. By automating database change management, you can build in adequate security controls, reviews, and alerts – like database Drift Detection – to the integrated workflow earlier, shifting left. 

Learn how Liquibase enables security optimization at the database layer with every change, update, and migration by automating change management alongside governance and observability capabilities for control and visibility.