Forem: GitProtect Team

How the Shared Responsibility Model Gap Makes You Lose Money

GitProtect Team — Thu, 09 Apr 2026 09:58:30 +0000

In January 2017, GitLab experienced a major outage that lasted around 18 hours, all because an engineer accidentally deleted data from the main database server. They ended up losing about six hours’ worth of database changes permanently.

The postmortem shows how recovery paths can look good on paper, then fall apart under pressure. And, of course, the business only realizes this after the outage is already expensive.

The same failure pattern shows up across SaaS portfolios. Vendors focus on uptime and making collaboration smooth at scale. They roll out controls for retention, recovery, and audit. But defaults, plan limits, and everyday operational constraints often fail enterprise requirements unless customers configure, test, and prove those controls.

A lot of organizations treat the Shared Responsibility model—sometimes called the Limited Liability Model—more like a box to check during procurement rather than something they fund, test, and review. That’s where the losses for enterprises start to add up.

We’ll circle back to the GitLab incident later as a case study for execution failure. But first, let’s take a look at the highest-cost gaps between what platforms do and what enterprises need.

The Economics of the Shared Responsibility Model Gap

Gaps in the Shared Responsibility model can lead to unexpected costs and missed commitments. Weak recovery and weak proof create predictable expenses. Uptime alone does not cap them.

Four Cost Buckets

Reconstruction and rework

When restore paths only give back partial results, teams end up spending time and money to rebuild lost data, metadata, and relationships.

Take this example: Jira CSV-based recovery can break attachments and needs some special handling for issue links. If 10,000 issues are affected and around 20% need manual fixes after export/import, at 5 minutes per issue, we are talking about 167 hours of rework. With loaded labor rates of $66 to $87/hour, that adds up to roughly $11.0k to $14.5k in direct labor, not even counting the extra downtime.

Downtime and productivity loss

Every hour that core tools are down or just not usable is time you’re paying for but can’t turn into work.

For instance, if you have 100 developers at $66 to $87/hr facing 6 hours of downtime, you’re looking at around $40k to $53k in lost paid time. Even when the tools are backed up, the time it takes to switch contexts adds more costs. A commonly cited estimate from Microsoft suggests it takes about 23 minutes to get back on track after being interrupted. It could add about $2.5k to $3.3k for those 100 developers.

Compliance and audit drag

The costs here aren’t just about fines. You’ve also got to factor in the work needed for remediation, audit exceptions, and delays in procurement when you can’t prove that controls are working.

For example, in enterprise deals that hinge on SOC 2 Type II, the reporting period can stretch on for months. If there are significant gaps, it can delay getting the enterprise ready for the reporting windows.

Trust and commercial friction

Incidents come with downstream costs that go beyond the technical side. There is a loss of confidence, added scrutiny, and extra process overhead. Internally, teams might lose trust and have to create workarounds. Externally, customers and users might slow down adoption, ask for more support, renegotiate contracts, or even churn.

Take security questionnaires, for example. They’re pretty standard and often seen as a hassle in B2B settings. After an incident, they get even more complicated and time-sensitive. Producing answers can take up to 15 hours each time, and it adds up with each review cycle.

Five Gaps Where Default Platform Controls Fail Enterprise Obligations

Enterprise exposure often stems from defaults, retention windows, and operational constraints. Here are five gaps that highlight these issues.

Note on terminology: organizations tier systems differently. In this post, “critical systems” means the applications where loss of access, integrity, or collaboration context would cause material, operational, or compliance impact. Start with the top tier, then expand.

Gap 1: Retention Duration

Service providers often maintain long-term retention, mainly for their own operational needs and critical system info. This helps them run, secure and troubleshoot their services. Platforms like GitLab, GitHub, or Atlassian follow standards like SOC 2 or ISO 27001, which usually require them to retain certain internal data for much longer than 365 days.

This can give customers a false sense of security. They often assume that the same long-term retention applies to their own data too. In reality, that’s usually not the case, and customer-level data retention and recoverability may be much more limited. For instance, GitHub Enterprise audit log events and Microsoft Purview Audit (Standard) audit records cover 180 days by default. Enterprise obligations (legal, contractual, and regulatory) often call for records to be kept for several years. Examples include HIPAA documentation retention requirements of six years and SEC Rule 17a-4 broker-dealer record retention requirements of not less than 3–6 years.

Shared Responsibility model boundary

The provider takes care of audit logging and retention controls, but they come with defaults and limits based on your plan. It’s up to you to define the necessary retention periods, configure those settings, and ensure coverage across critical systems.

Impact if you do nothing

If an incident happens, late detection makes it tough to figure out what went wrong because the trail of “who did what when” is gone.
Litigation risks increase if you can’t keep or produce electronically stored information under Rule 37(e).
Not producing required historical records can lead to audit findings, remediation, and enforcement exposure in regulated environments.

Test

Can you piece together “what changed” and “who did it” over the required timeframe?

How to close the gap

Implement a backup strategy with a flexible retention policy of up to unlimited.
Set clear retention requirements for each system with designated owners and a regular review schedule.
Centralize and keep audit and configuration evidence beyond the platform defaults (SIEM, archive, backup) and check coverage periodically.

Metric to track

The percentage of critical systems where the evidence lookback meets or exceeds the required duration (goal: 100%)

Gap 2: Metadata Preservation

One big pitfall is treating migration tools like they’re a backup solution.

“Migration” can refer to shifting data within the same platform (cloud-to-cloud, or on-premises to cloud) or switching to a completely different platform. In any case, exports often bring back the primary records, but they can miss the collaboration layer that makes systems usable. We’re talking about relationships, discussions, review context and history here.

Cross-platform migrations raise the stakes because each platform structures and stores metadata slightly differently, so one-to-one preservation is not guaranteed.Vendors warn against this in their documentation. For instance, GitHub mentions that migration archives are just migration artifacts, not backups. They also point out that migration outcomes might include warnings where data was skipped or migrated with caveats.

Shared Responsibility model boundary

The provider puts out APIs and migration or export mechanisms. It’s up to you to ensure that recovery keeps the metadata and relationships essential for smooth operation.

Impact if you do nothing

Teams might get their code back, but they’ll lose the decision-making context.
Rework can pile up since intent and review history are missing.
I*ncident response can drag on* because scope and intent are harder to reconstruct.

Test

After a restore, can teams explain what changed and why using the recovered collaboration context, or do they only have the raw repository?

How to close the gap

Go for backups that keep full metadata and relationships.
Run granular restore tests to make sure the metadata is intact.
Define and document key metadata for each system.

Metric to track

The percentage of systems where the last restore test confirmed metadata integrity. Aim for 100%.
Measure the average time to reconstitute in-scope systems. Set a target and check it quarterly.

Gap 3: Tested Recovery

Many organizations run backups, but recovery fails because restores are not tested in real-world scenarios. In SaaS, restore speed is often bound by API and platform limits. Even a correct backup can miss RTO if restoration depends on thousands of API operations that can’t be executed fast enough. Breakpoints often show up only during incidents, such as corrupted archives, missing credentials, and unclear runbooks.

Shared Responsibility model boundary

The provider sets the stage with APIs and exports that have rate limits and operational constraints. Meanwhile, you have to show that recovery meets RTO/RPO by routinely testing restores in realistic conditions and keeping a record of the results.

Impact if you do nothing

A restore might work, but if it misses the RTO, it turns into a business outage. Teams end up waiting, rebuilding things manually, or dealing with only partial restorations.
The scope of investigation and remediation grows.
Restore throughput becomes a bottleneck that competes with ongoing delivery work.

Test

Can you restore within RTO if your most privileged production credentials are compromised and primary data is deleted or corrupted?

How to close the gap

Conduct quarterly restore tests for your most important systems with documented RTO/RPO results and pass/fail criteria.
Automate restore testing wherever you can.
Maintain restore runbooks that include escalation paths and evidence collection.

Metric to track

Restore success rate, defined as the percentage of quarterly tests that meet RTO/RPO. Start by measuring the critical systems, then gradually expand to other systems based on priority.
Percentage of critical systems with a documented, tested restore runbook. Goal: 100%.

Gap 4: Independent Recovery

Recovery copies that are stored in the same tenant/account and under the same credentials as production can be deleted, encrypted, or invalidated by someone using a compromised admin account. Replication doesn’t solve this issue. It improves availability, but it also spreads deletions and corruption around.

Shared Responsibility model boundary

The provider builds availability and redundancy. You make sure recovery points exist outside the danger zone of production-admin compromises.

Impact if you do nothing

One compromised account can wipe out all your recovery points. Even if some copies survive, you might not have a reliable restore point after a destructive event.
Logical corruption and ransomware can spread across replicated systems. With time-limited rollback tools, if you catch it too late, you may end up with no clean point-in-time restore.

Test

If privileged admin credentials get stolen, can that account delete backups or invalidate recovery copies?

How to close the gap

Store backups in a different account/tenant with separate admin credentials.
Add deletion safeguards that match your risk level, like immutable storage (WORM) or time-delayed deletion.

Metric to track

Percentage of critical systems where production admin can delete backups. Goal: 0%.

Gap 5: Compliance Evidence

Auditors and enterprise buyers want proof that backups run, restores are tested, retention is applied, and failures are reviewed. SOC 2 Type II is built around this concept. It checks how well controls are working over a specific audit period. In the Availability criteria, A1.2 covers backup and recovery infrastructure, and A1.3 dives into testing recovery procedures, including the regular check on backup completeness.

This is where a lot of teams trip up. They run backups, but cannot prove when the last successful restore test was, when a retention policy was in effect, or who reviewed failures.

Shared Responsibility model boundary

The provider offers platform audit logs, often with retention limits. You produce evidence packs: backup coverage, retention settings, restore-test results, exception handling, and exported logs.

Impact if you do nothing

Weak evidence can slow down audits, procurement processes, and customer security reviews. Missing elements can lead to SOC 2 exceptions, requiring you to fix things and push reporting deadlines back.
Collecting data manually turns into weeks of screenshot chasing and log reconstruction across IT, Sec, and GRC teams.

Test

If evidence lives only in the compromised tenant, can an attacker tamper with or delete it?

How to close the gap

Automate evidence capture for backup coverage, retention settings, and restore-test results.
Export and protect audit and config logs outside the production admin plane.
Collect evidence continuously.

Metrics to track

Time to produce an audit-ready evidence pack for in-scope systems. Aim for under 24 hours.
Percentage of systems with automated evidence reporting. Goal: 100%.

Learn more about the Shared Responsibility model for different service providers:

📌 Shared Responsibility Model in Azure DevOps
📌 Atlassian Cloud Shared Responsibility Model
📌 GitLab Shared Responsibility Model
📌 GitHub Shared Responsibility Model
📌 Microsoft 365: What Are Your Duties Within The Shared Responsibility Model

Three Real-Life Cases: When the Gap Caused Loss

Let’s take a look at three incidents that map directly to one or more gaps above.

GitLab com (2017)

Gaps exposed: metadata preservation, tested recovery

As we talked about in the intro, in 2017, GitLab.com accidentally removed data from the main database server. This outage affected roughly 5,000 projects, 5,000 comments, and 700 new users. Issues and snippets were also impacted.

They noted that several recovery options just weren’t available when they needed them. The replica wasn’t usable. Azure disk snapshots hadn’t been enabled for the database servers. pg_dump backups were failing due to a PostgreSQL version mismatch, leaving the expected S3 backups out of commission. Recovery relied on an LVM snapshot created for staging, and copying and restoring it took many hours due to slow disks.

Even though GitLab was the provider here, this kind of failure can happen anywhere. “Backup exists” and “recovery works” are not the same without a tested, metadata-complete recovery. If you can’t restore the collaboration layer, you risk losing operational continuity.

What would reduce the impact?

Independent backups that capture both repos and the collaboration layer, allowing for point-in-time restores.
Restore testing that proves RTO/RPO and checks the metadata integrity.

Atlassian Cloud (2022)

Gaps exposed: tested recovery and independent recovery

On April 5, 2022, Atlassian reported that an internal maintenance script deleted 883 cloud sites, affecting 775 customers. This meant that many organizations lost access to Jira, Confluence, and other Atlassian Cloud products. For some customers, the outage dragged on for as long as 14 days.

This incident shows the tested recovery gap at scale. The presence of backups did not translate into a fast, predictable recovery path when hundreds of tenants had to be restored under pressure. Plus, it exposed how many customers lacked independence in their recovery options. Most organizations didn’t have a way to control their recovery points or maintain continuity while waiting for the vendor to sort things out.

Losing access to key systems for several days led to problems like missed approvals, manual reconciliations, and a whole backlog to tackle once access returned.

What would reduce the impact?

Customer-controlled copies outside Atlassian Cloud to support continuity of operations and decision-making while restoration progressed.
The ability to restore important projects or spaces in a separate environment (self-managed instance or alternative workspace) to maintain workflow.
Restore drills that test “time-to-operate” under real constraints (volume, permissions, and dependencies).

Code Spaces (2014)

Gaps exposed: independent recovery and tested recovery

In June 2014, Code Spaces, a code-hosting SaaS provider, faced a DDoS attack along with an extortion demand. The attacker got into the company’s AWS console. When Code Spaces tried to take back control, the attacker deleted resources like EBS snapshots, S3 buckets, AMIs, and several instances.

Later on, Code Spaces announced that most of its data, backups, machine configurations, and “offsite backups” were either partially or completely deleted over about a 12-hour period. Shortly after, the company announced it would cease trading.

This incident shows the independent recovery gap. Recovery copies were reachable from the same compromised control plane. Because the privileged credentials were compromised, both production and recovery got hit. Plus, there wasn’t any solid restore path that could hold up under those circumstances.

You see a similar failure mode in Saas when tenant admins can delete recovery copies.

What would reduce the impact?

Backups are kept in a separate AWS account with different credentials, so the attacker couldn’t access them.
Immutable backup storage, so even if someone had console access, backups couldn’t be deleted for a set retention period.
A third-party backup outside AWS entirely to spread out the risk across different providers.

How to Close the Shared Responsibility Model Gap

SaaS vendors keep platforms running. You need to make sure recovery and proof are predictable. In practice, this operating model breaks down into three main parts.

First, keep recovery points you control away from the same tenant and admin blast radius as your production. At the same time, make sure retention matches your obligations, not just platform defaults.

Next, connect your evidence to your assurance needs (SOC 2, ISO 27001, customer security reviews) without turning compliance into a manual project.

Lastly, prove it works. Run restore tests for your key systems on a regular schedule and under real constraints.

📌 For teams using GitHub, GitLab, Bitbucket, Azure DevOps, Jira, Confluence, and Microsoft 365, GitProtect could be a solid way to get that operating model in place.

It offers customer-controlled backups that sit outside the source platform, supports policy-driven retention, and gives you exportable reports for audits and security reviews.

It backs up core data and collaboration metadata, allows for granular restores, and reduces reliance on default platform recovery windows.

GitProtect supports flexible deployment and storage options that reduce dependency on a single cloud or admin plane. If it fits into your continuity strategy, cross-platform migration can also give you another recovery path.

✍️ Subscribe to GitProtect DevSecOps X-Ray Newsletter – your guide to the latest DevOps & security insights

🚀 Ensure compliant DevOps backup and recovery with a 14-day free trial

📅 Let’s discuss your needs and see a live product tour

Write Once, Read Many: How WORM Storage Makes Your Data Secure

GitProtect Team — Thu, 19 Mar 2026 12:17:26 +0000

WORM (Write Once, Read Many) is a data storage model specifically designed to guarantee data integrity over time. In a WORM-compliant storage, data is written once and cannot be altered or erased for a defined retention period (can be read as often as needed though).

What is WORM (Write Once Read Many)

WORM enforces two crucial rules:

👉 data cannot be rewritten (no overwrite)
👉 data cannot be erased (no delete) until retention expires

Bear in mind – these must be enforced at the storage level, not through any kinds of permissions or user roles. That distinction is key because data may still be vulnerable if protection depends on who is logged in or what rights they have.

How did WORM originate, and what is it used for?

WORM storage was developed for environments where data is treated as evidence. Financial institutions, healthcare providers, and regulated industries often rely on WORM-compliant storage instances to ensure that records remain complete, unchanged, and legally defensible over time. In these contexts, even a single altered byte of data could invalidate the whole dataset.

From a technical perspective, WORM storage typically works by assigning a desired object or record a retention period at the time it is written. Now, until that period expires, the storage system itself rejects any attempt to modify or remove the data, regardless of intent or access level the user has.

👉 The key implication is that if data can be changed or deleted before its retention period ends, it is not WORM-compliant.

This separates WORM from traditional storage models and lays the foundation for modern data protection strategies. This is especially true for environments exposed to ransomware, insider threats, and compliance audits.

How WORM works in practice

The mechanism used for WORM-compliant storage instances is simple and unforgiving:

👉 First, an object is written to storage, then a retention lock is applied. Now, until expiration, there is no overwrite, no delete, and no metadata changes.

In compliance-grade WORM implementations, the set retention cannot be bypassed even by administrators without violating the integrity of the storage system itself. This is what separates WORM from configuration-based immutability.

WORM vs immutable storage

The terms WORM and immutable storage are sometimes used interchangeably. That’s a mistake. They actually refer to different levels of enforcement – confusing them may lead to false security assumptions.

Immutable storage is a broader (and often weaker) concept. In many systems it is:

implemented at the application layer,
dependent on permissions.

Keep in mind that immutable storage is also vulnerable to credentials compromise, misconfigurations, and insider threats.

While WORM-compliant storage:

enforced at the storage layer
independent of application logic

👉 Every WORM system is immutable, but not every immutable system is WORM-compliant.

Why WORM is important against ransomware

Ransomware does not attack data itself. It actually attacks your ability to recover the given data. Typical attack chains would involve account takeover, deletion of backups, production encryption, and ransom payment demand.

The WORM-compliant storage breaks this chain as backups still exist, and the data cannot be deleted, encrypted, or overwritten.

WORM-compliant storage in GitProtect

GitProtect.io uses WORM-style immutable storage as a built-in ransomware defense and regulatory readiness measure, ensuring backup data remains unchanged for defined retention periods. The platform’s approach has three practical dimensions.

1 Object Lock immutability support

When GitProtect writes backup data to S3-compatible storage with Object Lock enabled, the storage itself enforces WORM retention. This means backups are stored with native immutability ensured by the storage provider’s lock mechanics – preventing modification or deletion during retention.

It leverages standard object storage features to make backups tamper-resistant at the storage API level.

2 You choose the storage target

GitProtect supports:

its own cloud storage with WORM enforcement enabled by default
user-managed S3-compatible buckets that already have Object Lock turned on
any combination of cloud, on-premise, or hybrid targets

This flexibility lets you implement WORM in the storage tier that matches your compliance and resilience requirements.

3 Complemented by multi-storage replication

Immutable backups alone reduce data-tampering risk, but GitProtect also lets you distribute copies across multiple storage instances (cloud, on-premise, hybrid). This supports the adherence to robust strategies like the 3-2-1 backup rule – multiple copies, different systems, one off-site – with immutable snapshots protected at each target.

The combination of Object Lock immutability with distributed backup copies means:

locked backups cannot be overwritten or erased
separate copies exist outside of any one storage failure
restore paths remain available even if a primary target is compromised

Practical product behaviors worth noting

Immutable configuration must be enabled when creating the bucket for some storage types – you cannot turn it on retroactively after creation.

GitProtect’s internal retention and versioning logic cannot be used instead of external object storage retention policies. In order to set up WORM storage, in AWS, for example, save the data in the immutable and WORM-compliant S3 storage with an object lock set to 6 months, then set the retention in GitProtect for 3 months (after this period, a notification to delete will be sent to the storage). This data will be removed from the storage after 6 months.

With this approach, you guarantee resilience against:

ransomware,
human error,
malicious admins.

Why WORM alone is not enough

Here’s the uncomfortable truth – WORM-compliant storage without: replication, account separation, monitoring, or recovery testing creates a false sense of confidence.

WORM must be:

part of a backup & disaster recovery strategy
integrated with operational processes
regularly tested via restore scenarios

This is where it ties back directly into the Shared Responsibility Model, ransomware prevention, and recovery testing best practices – thus, outlining its importance in current data protection strategies (not just in DevOps).

✍️ Subscribe to GitProtect DevSecOps X-Ray Newsletter – your guide to the latest DevOps & security insights

🚀 Ensure compliant DevOps backup and recovery with a 14-day free trial

📅 Let’s discuss your needs and see a live product tour

30 Cybersecurity Statistics You Must Know in 2026

GitProtect Team — Thu, 12 Mar 2026 13:57:48 +0000

DevOps teams did not sign up to be security teams. But if you run repos, CI/CD, cloud roles, SaaS apps, integrations, or backups, you operate the systems attackers lean on.

Most breaches are not flashy. They start with routine failures: a token left in a repo, MFA not enforced, an overprivileged API key that never expires, or backups that are deletable by the same admin identity.

Attackers do not need to “break in” if they can log in. They move with normal tooling and blend into admin traffic. They pull data out through services the business already trusts, then decide whether to encrypt. Ransomware is often the finale, not the opening act.

This article compiles 30 cybersecurity statistics from recent reports and maps them to a typical attack lifecycle. Most numbers were published in 2025, often about 2024 incidents, plus a few early 2026 outlook surveys. We hope this serves as a kind of checklist for your DevOps stack.

Exposure and misconfiguration: where leaks start

1 65% of Forbes 2025 AI 50 companies had confirmed secret leaks on GitHub

Leaked material included API keys, token, and credentials. Many were in places teams often overlook: deleted forks, gists, and secondary repositories. (source: Wiz’s State of AI in the Cloud report, Nov 2025)

Even strong teams leak secrets in the corners. If your posture is “we scan repos, so we’re fine”, this should unsettle you.

2 Median time to remediate leaked GitHub secrets was 94 days

Verizon’s 2_025 Data Breach Investigations Report_ reports a 94-day median time to remediate secrets leaked in GitHub repositories. Their dataset covers 22,052 incidents and 12,195 confirmed breaches across many org sizes and industries.

Ninety-four days is not just a delay. It is a window.

3 Most scanner-detected repo secrets in 2025 were tied to web app infrastructure (39%) and CI/CD (32%)

Next were cloud infrastructure (15%) and databases (5%). For disclosed web app infrastructure secrets, 66% were JWTs used for authentication and sessions. For cloud, 43% were Google Cloud API keys. (source: Verizon’s 2025 DBIR)

This is not a niche AppSec problem. It is a pipeline and runtime problem.

4 61% of SaaS accounts have MFA disabled or inactive

This figure comes from Saas Alerts’ SaaS Application Security Insights 2025, based on SaaS security telemetry from 43,000+ SMBs and nearly six million user accounts.

It seems that the mere availability of MFA does not solve the problem, does it?

5 75% of organizations had a SaaS security incident in the last year

AppOmni reports this rate in State of SaaS Security 2025, based on a survey of 803 security leaders and practitioners globally. The report also notes that many incidents were linked to unauthorized applications.

Unauthorized apps are an attack surface. If you do not control what is connected, you do not control your risk.

6 63% of organizations see external data oversharing

Cloud Security Alliance reported this in 2025 research based on a survey of 420 IT and security professionals. The same research also found that 56% of orgs say employees send confidential data to unauthorized SaaS apps, and it flags IAM gaps like weak privilege control (58%) and poor user lifecycle automation (54%).

This is how data walks out without a “breach” headline.

7 Organizations without full SaaS visibility are 5 x more likely to face an incident or data loss through 2027

Gartner states this as a planning assumption in its 2025 Magic Quadrant for SaaS Management Platforms. This assumption also applies to organizations that do not centrally manage SaaS lifecycles.

8 By 2027, 75% of employees will buy, change, or build technology outside IT control

Gartner projected this at its Security and Risk Management Summit 2023, up from 41% in 2022. SaaS sprawl is coming at us full speed.

Initial access

9 Over 60% of cloud security events relate to initial access, persistence, or credential theft

This figure comes from Elastic Security Labs’ Global Treat Report 2025.

In the cloud, identity is the main control point. Emphasize hardening authentication and watching for abnormal privileged access.

10 In 2025, exploited vulnerabilities were the #1 driver of ransomware success

Statista reported this in Nov 2025 based on a survey of cybersecurity professionals. 32% said ransomware succeeded due to exploited vulnerabilities. The next most cited causes were compromised credentials (23%), then malicious email (19%), phishing (18%) and brute force (6%).

Patch and identity are still doing the most of the work.

Lateral movement and data exfiltration, the quiet phase

11 In 2024, RDP was the top tool attackers used to move inside networks

ReliaQuest’s Annual Cyber-Threat Report 2025 breaks down lateral movement techniques used in 2024 incidents:

Remote Desktop Protocol (26%): Common in Windows environments. With stolen credentials, it can blend in as normal activity.
Internal spear phishing (16%): Uses trusted internal messages to expand access to more accounts and systems
SSH/SMB/Windows admin shares (14%): Leans on standard remote admin paths after attackers get valid credentials.

This is why “we have EDR” is not a full answer.

12 80% of breaches involved exfiltration

ReliaQuest’s report also shows that data theft is a core part of most incidents. In exfiltration cases, data was moved in two main ways:

60% to mainstream cloud storage (Google Drive, Mega, Amazon S3)
40% over C2 channels to attacker-run infrastructure.

Because blocking common cloud storage is often not realistic for day-to-day work, you should monitor for unusual data movement and identity activity instead.

Ransomware and operational disruption: when the business stops

13 93% of paying victims later learned their data was stolen

Paying does not end the problem. Victims who paid often still lost data, were attacked again (83%), or could not recover all data (45%).

These figures come from CrowdStrike’s State of Ransomware 2025 survey of 1,100 IT and security decision makers across Australia, France, Germany, India, Singapore, the UK, and the US.

14 57% of organizations rely on a single layer of security to protect their cloud backups from ransomware

That’s one conclusion from an EON survey of 154 IT and cloud leaders at Google Cloud Next 2025. The survey also found that 13% of organizations have no ransomware protection for cloud backups, while 29% use multiple layers like immutability, anomaly detection, and MFA.

At the same time, EON attributes 23% of cloud data loss to ransomware or breaches. This is why separate admin boundaries and immutability should be treated as baseline controls.

15 Ransomware succeeds due to gaps in expertise (40.2%) and visibility (40.1%)

Sophos’ State of Ransomware 2025 surveyed 3,400 IT and security leaders across 17 countries whose orgs were hit by ransomware. The most cited factors contributing to the success of ransomware were:

Lack of expertise (40.2%)
Unknown security gaps (40.1%)
Lack of people/capacity (39.4%)

This points to a basic operations problem. The fix is: clearer process, better coverage, and enough staffing, not another tool.

16 54% of board members think they’re prepared. Security teams disagree

In the CrowdStrike’s survey 54% of board and C-level leaders said they are “very prepared” for ransomware, versus 46% of security teams. It also found that 76% of organizations report this disconnect is growing.

That gap is a risk by itself. It leads to underfunded controls and unrealistic recovery plans.

The cost of failure, money, legal exposure, and downtime

17 Average breach cost in 2025: $4.44M globally and $10.22M in the US

These figures come from IBM’s Cost of a Data Breach Report 2025. IBM notes the global average fell from $4.88M in 2024, while the US average rose by 9% in 2025, due to higher regulatory penalties and higher detection and escalation costs.

The study covered 600 organizations with breaches between March 2024 and February 2025 across 17 industries in 16 countries or regions.

If you operate in the US, plan for higher escalation and penalty costs. That changes the ROI math for detection, response, and auditability.

18 41% of 5B+ revenue companies report higher exposure to damaging breaches

PwC highlights this fact in its 2026 Global Digital Trust Insights survey of business and tech leaders (May to July 2025). The same survey shows higher exposure among US-based organizations (37%) and TMT (33%).

19 46% of organizations experienced an outage or service disruption due to attacks

That’s the reality shown in Red Canary’s Security Operations Trends Report 2025, based on a survey of 550 security leaders across the US, UK, Australia, New Zealand, and the Nordics. In the same research, leaders estimated the average incident cost over the past year at $3.7M.

Downtime is not rare, so your recovery plan needs to work in practice.

20 61% of security leaders report breaches caused by failed or misconfigured controls in the last 12 months

65% of those breaches cost more than $1M. (Source: Security Leaders Peer Report 2025 by Panaseer, based on a survey of 400 security leaders at larger orgs in the US and UK).

It seems that a lot of “breach prevention” is basic control hygiene.

21 955 hours of disruptions in total across key DevOps SaaS platforms in 2024

GitProtect’s report, The CISO’s Guide to DevOps Threats 2025, puts the combined time of disruptions for GitHub, Bitbucket, Jira, GitLab and Azure DevOps in 2024 at 955 hours. That’s enough time to sail across the Atlantic on a small yacht, make a short stop in the Caribbean, reach the East Coast, and head back to Europe.

AI is accelerating the mess, more tools, more leaks, weaker controls

22 46% of organizations struggle to monitor non-human identities

This finding comes from the Cloud Security Alliance’s State of SaaS Security Report 2025 mentioned earlier. The report also flags growing concern about overprivileged API access as GenAI tools and SaaS-to-SaaS integrations spread (56%).

Non-human identities and API sprawl are where governance collapses. Treat machine access like first-class identity.

23 AI-driven social engineering is the top 2026 threat

ISACA’s 2026 Tech Trends and Priorities Global Pulse Poll surveyed 2,963 professionals in digital trust fields (cybersecurity, audit, governance, risk, compliance) and placed this risk at the top. In the same ranking, ransomware and extortion came next 54%), followed by insider threats (35%).

24 66% of organisations expect AI to have the biggest impact on cybersecurity, but only 37% assess tools before deployment

World Economic Forum highlights this gap in its Global Cybersecurity Outlook 2025, based on 409 survey responses from 57 countries

This is shadow IT moving faster than most control processes. If you do not offer a quick, clear path, teams will deploy tools first and deal with security later.

25 78% of companies lag on basic data and AI security practices

Accenture’s State of Cybersecurity Resilience 2025 (survey of 2,286 respondents from $1B+ revenue companies across multiple regions) paints a broader picture. It also found that:

22% have clear policies and training for generative AI use
25% fully apply encryption and access controls for sensitive data across transit, storage and processing
83% have not built a secure cloud foundation with integrated monitoring, detection, and response.

AI mostly makes existing gaps hurt more, like weak data controls, weak cloud foundations, poor inventory.

26 Shadow AI adds $670K to breach cost in high-usage orgs

IBM’s 2025 breach-cost research also looked at “shadow AI” and found:

20% of organisations said they had a breach tied to shadow AI incidents.
These incidents more often involved PII (65%) and IP (40%).
Data was frequently spread across multiple environments.

Shadow AI is solved not only by policy but also by controlling data movement and access across environments.

27 37% of SMBs plan to address AI risk by expanding cyber insurance coverage

Hiscox’s Cyber Readiness Report 2025 also lays out what what other measures SMBs plan to do over the next three years to reduce AI-related risks:

Employee training on AI threats: 36%
Regular AI usage audits: 36%
Hiring AI-skilled staff: 33%
Using AI security consultants: 33%

The research covered 5,750 companies (50 to 249 employees) in the US and Europe (Jul-Aug 2025).

Supply chain and third-party blast radius

28 54% of large organizations say third-party risk management is a major challenge

World Economic Forum’s Global Cybersecurity Outlook 2025 frames supply chain complexity and limited supplier visibility as a top cyber risk. Key concerns include third-party software vulnerabilities and attacks that spread through connected partners and systems.

If you use vendors, integrations, and open source, you already have a supply chain. The question is whether you can see and constrain it.

29 24% of orgs with 5,000+ external data-sharing partners had 10+ breaches per year

Kiteworks’ Data Security and Compliance Risk 2025 links breach frequency to the number of outside groups with whom an organization shares private data with. Orgs with fewer than 500 partners did better, 34% reported zero breaches.

More partners means more ways for data to leak. If you add integrations, scale controls and monitoring with them.

30 59% of IT and security professionals cite code vulnerabilities as the top AppSec concern

This figure comes from Thales’ 2025 survey of nearly 3,200 IT and security professionals across 20 countries and 15 industries. Other main AppSec concerns were:

Software supply chain issues (48%)
API attacks (38%).

Top DevSecOps challenges included:

Secrets management (54%)
Sprint cadence and execution (48%)
Open-source SCA (44%)

✍️ Subscribe to GitProtect DevSecOps X-Ray Newsletter – your guide to the latest DevOps & security insights

🚀 Ensure compliant DevOps backup and recovery with a 14-day free trial

📅 Let’s discuss your needs and see a live product tour

Your GitLab Data Security: 14 Critical Areas To Address

GitProtect Team — Fri, 19 Dec 2025 12:09:19 +0000

Modern organizations often use GitLab as a core version control system (VCS), making it one of the most essential systems for DevOps. Given the critical nature of the data stored here, thorough evaluation of risks and implementing data protection best practices are a must. According to the Shared Responsibility Model, GitLab provides security for the underlying infrastructure, while the user’s duty is to keep data protected.

👉 More about GitLab’s Shared Responsibility Model.

In this article, we go into detail about the possible ways to lose GitLab data, and how this can be prevented.

1 Accidental deletion of projects

Let’s begin by stating that human error is the most common cause of data loss in 2025. A single misclick on “Delete project” or “Delete group” can permanently erase GitLab repositories, merge requests, wikis, and all related metadata. In terms of GitLab.com, it is stated that deleted projects enter a pending deletion state – then they are automatically erased after 30 days.

💡 To delete projects, you need to have the Owner role (or admin permissions). Poor management of access control opens pathways for accidental deletion to take place.

Avoid accidental deletions in GitLab:

Archive instead of deleting
Restrict permissions to delete
Protect important branches, and configure Protected Branches so that essential code cannot be removed or overwritten
Automate backups with GitLab’s native capabilities or opt for third-party solutions like GitProtect.io
Implement flexible disaster recovery with features like point-in-time and granular restore
Track deletions through GitLab Audit Events (GitLab Premium and Ultimate). You will need to review logs or integrate with external monitoring tools

2 Vulnerable credentials

Compromised credentials remain a key factor behind many data breaches. Access tokens or SSH keys, when exposed, grant an attacker the same level of access as the account owner would. They can hijack repos, modify them, or even delete them without any restriction.

Authentication and credentials security:

Use short-lived tokens and rotate regularly
GitLab built-in Secret Detection and Secret Masking
Require multifactor authentication (MFA)
Limit scopes and permissions of PATs, group tokens, and project tokens
Keep GitLab instances up to date for latest security patches
Audit access logs and usage – GitLab has Audit Events (for Premium and Ultimate)

3 Data overwritten during force push

In GitLab, users can rewrite commit history using the force flag in the git push command. Use it with caution… A force push can permanently overwrite commits, delete your teammates’ work (rewrite pointers), or reset branches to their older states. The risk is especially high when it comes to force push and shared or production branches. It can take place when developers try to ‘clean up’ commit history or resolve conflicts, and then unintentionally remove data in the process.

Don’t lose data due to force push:

Configure Protected Branches to disallow force pushes, disable branch deletion, and control who can push & merge
All changes shall require review and go through a merge request
Push rules guarantee extra protection, such as enforcing signed commits and blocking tag deletion
Use git reflog to recover commits
Prevent accidental overwriting of teammates’ commits with –force-with-lease. It does not overwrite commits that you don’t already have locally and is considered the ‘safe’ alternative to force push
Implement off-site backups with point-in-time restore that supports recovery after a force push

4 Beware of insider threats

Insider threats can be accidental deletions as well as malicious sabotage, like credential sharing. GitLab actually centralizes repositories, issues, CI/CD pipelines, and secrets; therefore, a single compromised account can damage the development lifecycle, reputation, and business continuity.

Secure your organization from within:

Leverage the principle of least privilege
Implement role-based access control
With GitLab’s group and subgroup hierarchy, ensure users inherit only the permissions required for their role and prevent accidental overexposure
Review permissions on a regular basis
Enforce MFA and SSO for all users, and SSO managed by the external identity providers (IdP) for all users
Clearly separate duties between administration and development
Don’t overlook off-boarding processes – revoke unnecessary permissions

5 Data corruption beyond source code

Apart from repos, GitLab includes CI/CD data, artifacts, issues, wikis, attachments, and metadata. Now, these are all stored across multiple backend services such as Gitaly (for repositories), PostgreSQL (for metadata and issues), Redis (for caching and sessions), and object storage (for artifacts and uploads). If any of these break or end up misconfigured, projects can become partially or fully unrecoverable. In self-managed instances, misconfigured storage paths, failed Gitaly nodes, or unoptimized PostgreSQL replication can cause integrity issues or data desynchronization.

To prevent data corruption:

Perform regular full and incremental backups
Verify data integrity frequently
Apply configuration management and monitoring to avoid corruptions before deployment

6 The growth of ransomware

The rate of ransomware has grown rapidly in recent years. While self-managed GitLab instances face significantly higher ransomware and malware exposure than GitLab.com (SaaS), both require proper security measures. Self-managed GitLab instances, however, put the duty on the user to manage the OS, network, storage, and access to data; so if any layer gets compromised, attackers can encrypt and/or corrupt:

Gitaly repositories
PostgreSQL metadata (issues, MRs, permissions, pipeline data)
CI/CD artifacts and logs
uploads, LFS objects, registry images
backup directories (if improperly stored on the same server)

Ransomware can lead to service outages, encrypted repositories, or corruption of every project under a group. This would further result in damaged reputation, costly compliance violations, or complete stop of primary operations. With GitLab being a DevSecOps platform, ransomware wouldn’t just affect code, but also pipelines, secrets, deploy tokens, and business continuity too.

Ransomware protection

As the party responsible for the protection of accounts, access, authorization, and data, the user needs strict permission control, a secure network, and immutable, off-site backups. To prevent ransomware from doing any damage to your GitLab environment, isolate GitLab components (Gitaly, PostgreSQL, Redis, object storage) on restricted networks and avoid exposing them publicly. In this way, you can guarantee endpoint protection, restrict deploy tokens, enforce firewall rules, and prevent malicious code execution. Remember to back up your data with trusted providers, implement flexible recovery, and stay compliant with industry standards.

7 No backup or disaster recovery

Backup and disaster recovery (DR) are key aspects of any effective data protection strategy. Reliable solutions guarantee data security in the face of accidental deletions, malicious insiders, ransomware attacks, service outages, and even simple migrations. Under the aforementioned Shared Responsibility Model, the user is responsible for both backup and recovery.

👉 Why third-party backup is necessary for GitLab (and other Git-based platforms)

To ensure data integrity, data recovery, and prevent attackers from erasing (or altering) any of your GitLab data, your backup and DR solution shall meet a number of requirements:

Immutable, off-site, WORM-compliant storage
Geo-redundancy, replication
Data residency of choice
Automated backup
Scheduling with different, customizable plans
Full coverage with all critical metadata
Encryption at rest and in transit
3-2-1 backup rule
Unlimited retention
Compliance with industry regulations like SOC 2 Type II or ISO 27001
Flexible recovery with point-in-time restore and full data recovery

8 Single Group Owner bottleneck

Relying on a single Project Maintainer or Group Owner leaves you with a single point of failure in GitLab. If that one person is unavailable, teams may be unable to merge code, approve changes, manage runners, or update project settings.

💡 The Group Owner gets full administrative rights over a group and all its projects. Then, the Project Maintainer is the highest project-level role (can push to protected branches and manage repo settings).

Both of these roles involve responsibility. The entire SDLC may stop instantly once the responsible individual becomes unavailable, so be sure to have:

At least two Group Owners for important groups or subgroups
Multiple Project Maintainers for critical repositories
Document processes so there is no person-dependent knowledge

9 GitLab service disruptions

Both GitLab.com (SaaS) and self-managed GitLab instances are prone to service disruptions. Such cases can leave users with no access to their critical data. Self-managed instances introduce greater complexity and risk, where downtime can lead to data loss. If your instance becomes unavailable with failed upgrades or misconfigured storage instances, metadata may end up incomplete or unrecoverable.

Avoid downtime, data loss, and damaged reputation:

Maintain local clones and/or off-site mirrors of critical repositories
Store backups off-site
Test all upgrades and migrations in a staging environment
Monitor GitLab components and implement alerts to detect issues early
Use High Availability (HA) for production instances
Utilize GitLab Geo replication for regional redundancy, but monitor for replication lag
Back up before every upgrade or configuration change
Avoid relying on CI pipelines for backups or exports (if runners or the API go down, your backups go down too)
Leverage third-party backup and DR solutions for cross-over restore, point-in-time, and granular recovery to minimize downtime
Create a downtime communication plan, outline roles clearly

10 Pipeline or job failure due to misconfiguration or API overload

GitLab CI/CD pipelines depend on a valid .gitlab-ci.yml, correctly configured runners (matching tags, proper executors), and sufficient API availability. Any misconfigurations in pipeline logic, or missing variables, can cause jobs to fail before any artifacts or build outputs are saved. When these jobs cover deployables, documentation, or backups, failures may lead to data loss.

On GitLab.com, API rate limits apply to job tokens, artifact uploads, registry operations, and automation flows. Pipelines that rely on API calls may fail or stop mid-execution under heavy load, resulting in incomplete artifacts or failed exports.

How shall this be addressed:

Validate all pipelines before execution
Guarantee proper runner configuration
Critical pipelines get dedicated runners
Monitor API rate limits, CI/CD errors & set up alerts

11 Insecure GitLab CI/CD pipelines and runners

GitLab CI/CD has direct access to your environment (repos, variables, tokens, and deploy credentials). If pipelines or runners are left open, misconfigured, or too permissive, you hand attackers a ready-made execution path. A single job can expose CI/CD variables, leak tokens, or run code that tampers with artifacts or pushes poisoned changes upstream.

💡 In short: if your runners aren’t isolated and your pipelines aren’t locked down, your entire SDLC becomes an entry point.

Secure pipelines and runners:

Never expose runners publicly
Protect secrets and variables
Define who can run pipelines and limit job permissions
Verify images before they get to CI
Review pipelines just like code
Keep staging and production credentials separated, do not reuse tokens between environments
Monitor runners for suspicious jobs and rotate your tokens

12 Unsafe third-party integrations

GitLab allows users to integrate third-party tools to streamline their work and simplify collaboration. These include Jira, Slack and Kubernetes. Carefully evaluate everything that gets added into your GitLab environment, especially when it comes to production repos.

Every integration is a new potential failure point. If an integration is misconfigured or uses overly broad tokens, attackers don’t even have to breach GitLab directly to steal your data. The attacker will exploit weaker systems tied to your instance and pull secrets or trigger pipelines.

Ensure security for all third-party integrations:

Use minimal token scopes
Rotate all integration credentials regularly
Remove unused webhooks and abandoned apps
Validate inbound requests (signatures, HTTPS)
Monitor integration-triggered activity
Store secrets only as masked, scoped CI/CD variables
Run custom security scanners

13 Mirrors and repository divergence

Mirrors need proper management. If a mirrored repo isn’t syncing, branches drift, commits diverge, and teams end up working on outdated code. Failed pull/push mirrors, expired tokens, or silent sync errors leave repos out of date. Now, any overwrite or merge after that becomes real data loss.

Address the risks:

Sync mirrors on a schedule, not manually
Rotate tokens so mirrors don’t break silently
Let CI test merges before they hit main
Keep feature branches synced with main regularly
Fix conflicts locally before pushing upstream
Review permissions so only trusted roles can overwrite mirrored branches

14 Public projects and data exposure

Public projects are the easiest way for secrets to get leaked. A single commit with an API key, access token, SSH key, or environment file is enough to expose your entire GitLab environment. GitLab’s public visibility makes it instantly accessible to scanners and bots. Even deleted commits stay in history, forks, caches, and mirrors. Once it’s pushed publicly, you’ve lost control of it.

Watch out for public projects:

Keep sensitive projects private by default
Use Secret Detection to catch leaked keys instantly
Block commits containing secrets with pre-commit hooks
Rotate any credential that ever touched a public commit
Use protected branches so no one pushes unreviewed code
Scan projects regularly for forgotten secrets or config files

✍️ Subscribe to GitProtect DevSecOps X-Ray Newsletter – your guide to the latest DevOps & security insights

🚀 Ensure compliant DevOps backup and recovery with a 14-day free trial

📅 Let’s discuss your needs and see a live product tour

How to Protect Jira Assets: Best Practices For Backup And Recovery

GitProtect Team — Thu, 11 Dec 2025 11:01:59 +0000

It’s hard to imagine a modern ITSM (IT Service Management) and general configuration management in Jira without Jira Assets. All the more so, it allows IT teams to model physical infrastructure, logical dependencies, user ownership, licensing, and even financial amortization of resources. The possible challenge is its hybrid architecture, followed by tight schema and application logic coupling. Any automation error or misconfigured import may corrupt your CMDB.

Forget about hypothetical situations. The market knows numerous multi-hour outages in ITSM operations. Mainly due to schema-wide cascading deletions and overwritten attribute sets (caused by faulty API scripts).

Certainly, protecting this layer requires you to deeply understand how data is stored and where the critical paths lie. You also need to get familiar with how to build a backup and recovery pipeline that aligns with:

RTOs under 1 hour,
RPOs under 15 minutes,
ability to pass integrity validation under load.

According to the CISO’s guide to DevOps threats, Atlassian’s Jira experienced 132 incidents of different impact in 2024, which shows a 44% growth compared to 2023.

Assets storage model. What you’re backing up

Jira Assets data is stored across specific ActiveObjects tables in the Jira database (Data Center). The most vital include (among others):

The tables mentioned use foreign keys and serialized JSON structures. They require precise relational consistency to avoid orphaned data or circular dependencies.

However, elements like attachments reside in the filesystem. They’re placed within the /data/attachments directory in Jira Home by default. If you exclude attachments from backup, object attributes pointing to these files will break (unnoticed) during recovery. The Jira system will fail to render previews or links.

In the case of a Cloud instance, the approach is different. You can say Atlassian abstracts this layer entirely. Jira Assets data resides in a proprietary backend atop an AWS stack. That means there is no direct database access. Backups must be handled via the Jira Assets REST API – with or without third-party tooling.

Part 1. Solutions for Jira Assets DC

Though Atlassian has already announced the end of support for its Data Center by March 28, 2029, let’s still look at some of the options. A full backup of Assets on Jira Data Center starts with consistent database snapshots. For PostgreSQL, a point-in-time consistent export of relevant tables may be set using:

pg_dump -Fc \ -t "AO_8542F1_IFJ_OBJ" \ -t "AO_8542F1_IFJ_OBJ_TYPE" \ -t "AO_8542F1_IFJ_ATTRIBUTE" \ -t "AO_8542F1_IFJ_SCHEMA" \ jira_prod > assets_only.dump

You have to execute such an export with complete transaction consistency. So, –no-synchronized-snapshots is not advised. Significantly, if the schema changes due to ongoing imports or automation.

At the same time, the attachments must be captured:

tar -czf attachments_$(date +%F).tgz /var/atlassian/application-data/jira/data/attachments

However, in [regulated industries](https://gitprotect.io/industries/regulated-industries.html, best practices include generating **SHA256 **hashes post-backup:

sha256sum assets_only.dump attachments_*.tgz > backup_hashes.sha256

During recovery, this approach validates that no tampering or corruption has occurred.

A bit deeper dive into database backups in Jira

It’s worth noting that Atlassian recommends native database tools for backups due to their reliability and performance. For PostgreSQL, the usual choice for logical backups in Jira is the pg_dump utility. For physical backups for larger instances, pg_basebackup is best.

For example, configure a cron job on the Jira Data Center to create a daily logical backup:

`#!/bin/bash
BACKUP_DIR="/backups/jira/db"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
DB_USER="jirauser"
DB_NAME="jiradb"
BACKUP_FILE="$BACKUP_DIR/jira_db_$TIMESTAMP.sql.gz"

mkdir -p $BACKUP_DIR
pg_dump -U $DB_USER $DB_NAME | gzip > $BACKUP_FILE

Rotate backups (keep 7 days)

find $BACKUP_DIR -name "jira_db_*.sql.gz" -mtime +7 -delete`

The script above dumps the database, compresses it, and rotates backups to manage disk space. Of course, you need to ensure the DB_USER has sufficient permissions. Then, it’s time to test the backup integrity using gunzip and psql to restore it to a test environment.

Another example of a daily dump in PostgreSQL may look like this:

pg_dump -U jira_user -h localhost -F c -b -f /backups/jira_db_$(date +%Y%m%d).backup jira_db

For comparison, the same step, but with rotation, in MySQL can be shaped as shown below:

mysqldump -u jira_user -p$PASSWORD jira_db | gzip > /backups/jira_db_$(date +%Y%m%d).sql.gz find /backups -type f -name '*.gz' -mtime +30 -delete

Considering physical backups in PostgreSQL, pg_basebackup provides a faster option for large databases (>50GB). For example:

pg_basebackup -U $DB_USER -D /backups/jira/pg_basebackup_$TIMESTAMP -Fp -Xs -P

The command creates a full backup of the PostgreSQL data directory. Combined with write-ahead logs (WAL), it’s suitable for point-in-time recovery (PITR). To enable WAL archiving, configure archive_mode and archive_command in postgres.conf.

archive_mode = on archive_command = ‘cp %p /backup/jira/wal/%f’

What about filesystem backups?

As you already know, the JIRA_HOME directory, typically located at ~/.jira-home, contains critical files like attachments (data/attachments), indexes (caches/indexes), and configuration files.

To back up the described directory, you need careful synchronization to avoid corrupting Lucene indexes, which Jira utilizes for search. So, if you aim for a robust solution, then the rsync method with a pre-backup script to pause indexing is a good choice.

`#!/bin/bash
JIRA_HOME="/var/atlassian/application-data/jira"
BACKUP_DIR="/backups/jira/fs"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
BACKUP_FILE="$BACKUP_DIR/jira_home_$TIMESTAMP.tar.gz"

Pause indexing

curl -u admin:admin -X POST http://jira.example.com/rest/api/2/indexing/pause

Sync and archive

rsync -av --delete $JIRA_HOME /tmp/jira_home_backup
tar -czf $BACKUP_FILE -C /tmp jira_home_backup

Resume indexing

curl -u admin:admin -X POST http://jira.example.com/rest/api/2/indexing/resume

Rotate backups

find $BACKUP_DIR -name "jira_home_*.tar.gz" -mtime +7 -delete`

The script:

pauses indexing through Jira’s REST API,
syncs the JIRA_HOME directory
archives it
resumes indexing.

You need to replace admin: admin with a service account. In the next step, secure the credentials using a .netrc file or environmental variables.

In general, the rsync command for attachments and indexes may be utilized as:

rsync -avz /var/atlassian/application-data/jira/ backup-server:/jira_backups/

Jira’s built-in backup service

Like any self-respecting software developer, Atlassian has implemented a native data backup mechanism in Jira. The platform’s admins utilize an XML backup utility, accessible via:

Administration → System → Backup System

It generates a single ZIP file containing issues, configurations, and selected JIRA_HOME data. The solution is convenient yet very limited. The mechanism excludes attachments and is resource-intensive, often causing performance degradation on large instances with more than 500,000 issues.

For smaller instances, you can schedule XML backups using a script involving the REST API. For instance:

`#!/bin/bash
JIRA_URL="http://jira.example.com"
USERNAME="admin"
PASSWORD="admin"
BACKUP_DIR="/backups/jira/xml"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)

Trigger backup

curl -u $USERNAME:$PASSWORD -X POST "$JIRA_URL/rest/backup/1/export/runbackup" -H "Content-Type: application/json" -d '{"cbAttachments": false}'

Wait for backup completion and download

Note: Implement polling logic to check backup status`

However, automating XML backups is less reliable compared to database and file system backups. The method can cause potential timeouts. If so, it should be reserved as a secondary option (or for configuration exports).

Testing point-in-time restore: granular recovery and referential pitfalls

Exceeding acceptable downtime windows while restoring full backups isn’t rare. Many or even most teams aim for granular restores. Especially during incidents initiated by automation or import errors.

However, such a step is far more complex than it appears.

Let’s take rolling back a single object as an example. It requires identifying all dependencies (e.g., attributes that refer to other object types, automation rules using such attributes), truncating the specific object set, and reinserting from a filtered pg_restore.

For instance (SQL):

`DELETE FROM AO_8542F1_IFJ_OBJ WHERE OBJECT_TYPE_ID = 11203;

pg_restore --data-only --table=AO_8542F1_IFJ_OBJ --file=filtered_obj.dump assets_only.dump`

However, making such changes without setting up the necessary rules for your data (attribute constraints) and the unique identifiers linking things together (UUID bindings) can lead to problems. You might have broken connections between the data (dangling objects).

Other issues might be inconsistencies in your system’s overall structure, such as breaking schema consistency. Therefore, you must test restores on staging. You should be using the exact version of Jira and the plugin state. Equally important is utilizing checksum-based post-restore validation against a dataset.

Part 2. Solutions for Jira Assest Cloud

It’s worth reminding that Atlassian Cloud doesn’t officially support full schema-level exports in JSON format via the REST API. They were part of older Insight Server versions. The recommended way to export (backup) large sets of objects is to use the CSV export with the Jira (Service Management) UI.

If you plan to automate exports (backups), you usually:

export CSV files manually or utilize scripting UI automation
or use the REST API to retrieve objects individually or in pages (pagination), which requires custom scripts.

For example, let’s retrieve the workspace ID required for API calls. Before making the latter, you need your workspace ID (bash):

curl -u email@example.com:API_TOKEN \ -H "Accept: application/json"\ "https://yourdomain.atlassian.net/rest/servicedeskapi/insight/workspace"

Note the “id” field of the workspace you want to work with from the JSON response.

To restore objects from JSON files, you must send a single (one) POST request per object. For this purpose, you use the current Assets API endpoint and Basic Auth with an API token.

For instance, take a JSON file (object_345.json):

{ "objectTypeId": "250", "attributes": [ { "objectTypeAttributeId": "2797", "objectAttributeValues": [ { "value": "Object Name" } ] }, { "objectTypeAttributeId": "2807", "objectAttributeValues": [ { "value": "Object Description" } ] } ] }

Of course, you must get the correct objectTypeId and objectTypeAttributeId from your Assets schema configurator or via API.

Now, create a POST request to create an object:

curl -X POST \ -u email@example.com:API_TOKEN \ -H "Content-Type: application/json" \ -d @object_345.json \ "https://api.atlassian.com/jsm/insight/workspace/{yourworkspaceId}/v1/object/create"

It’s worth mentioning that:

the old endpoint https://yourdomain.atlassian.net/rest/insight/1.0/object/create is deprecated and doesn’t work in Atlassian Cloud
bulk export of objects in JSON format via the REST API is not supported in Atlassian Cloud
for large datasets, export CSV using UI or implement paginated object retrieval through API
import requires sequential POST requests per object, respecting object type and attribute IDs.

A quick look at recovery procedures

Approaching database recovery, let’s start with logical backups. To restore the latter, you can use:

gunzip jira_db_20250415_120000.sql.gz psql -U jirauser -d jiradb < jira_db_20250415_120000.sql

When it comes to physical backups, you should stop the PostgreSQL service. Then, you copy the backup to the data directory and replay the WAL files (if using PITR). The last thing is to test restores in a sandbox environment to validate RTO and RPO.

File system recovery with validating and testing

When you want to restore JIRA_HOME, the first thing to do is to stop Jira. Then it’s done, extract the backup, and verify file permissions. For instance:

tar -xzf jira_home_20250415_120000.tar.gz -C /var/atlassian/application-data chown -R jira:jira /var/atlassian/application-data/jira

Further, rebuild indexes in Administration → System → Indexing after restoration to ensure search functionality.

A good practice (or even a must) is regularly testing backups by restoring them to a staging environment. You can automate the process with a script to check backup integrity.

#!/bin/bash BACKUP_FILE="/backups/jira/db/jira_db_20250415_120000.sql.gz" gunzip -t $BACKUP_FILE && echo "Backup is valid" || echo "Backup is corrupt"

In short, a backup is useless if it can’t be restored.

Jira Assets backup automation and third-party integrations

Experts across the Internet keep repeating that manual backups are error-prone. To remove human-made errors from the backup and restore equation, top-performing teams integrate tools like GitProtect.io.

It’s an enterprise-grade, automated backup and disaster recovery tool, tailored for DevOps and PM data protection, including Jira, Bitbucket, GitHub, GitLab, and Azure DevOps..

The GitProtect solution allows you to back up and restore your Jira Assets in a few simple steps.

From the Jira admin’s perspective, the solution extends backup and recovery beyond Atlassian’s native capabilities. Companies can use granular control, compliance, and resilience for mission-critical workflows.

Here’s why:

Cross-tool dependency protection

Usually, Jira is integrated with other DevOps tools, for example:

Git repositories (e.g., issues referenced in commit messages)
CI/CD pipelines are connected via third-party integration automation rules.

GitProtect.io backs up Jira Cloud and Git repositories (GitHub, GitLab, Bitbucket, Azure DevOps), preserving platform issue references.

When backups are configured across these tools, GitProtect ensures that cross-referenced data (e.g., Jira issue keys in Git commits) remains accessible after recovery, provided all linked systems are restored.

Backup automation without script maintenance

Even though Atlassian Cloud provides basic backups and Data Center requires manual scripts, GitProtect allows for:

- Policy-drive scheduling
For example, daily incremental and weekly full backups.

- Pre/post-backup hooks
For instance, pause indexing during backup to ensure consistency.

- No reliance on brittle pg_dump or filesystem snapshots

Compliance and legal hold

The tool uses immutable backups (WORM storage) for audit trails, which is crucial for SOC2/ISO 27001. Backups are supported with role-based access control; for example, Jira schema restores are restricted to admins.

Faster, granular recovery
GitProtect allows you to restore individual issues (not just the entire project) through Jira’s REST API integration. Your team can also utilize point-in-time recovery for attachments or workflows corrupted by misconfigured apps.

Offsite replication for disaster recovery

The tool makes it easy to connect and use hybrid storage targets (e.g., AWS S3, Azure Blob, on-prem NAS, etc.) with encryption-in-transit. This also entails geo-redundancy to meet RPO/RTO SLAs, e.g., under 1 hour recovery for critical projects.

Native Jira backups lack cross-tool consistency and legal-grade retention. GitProtect.io fills the gap by treating Jira as part of the DevOps pipeline (not just a standalone database). For teams that already back up Git repos with GitProtect.io, adding Jira is a natural extension to protect the entire SDLC.

More than a safety net: metrics that matter

Ideally, each Jira admin could treat backup as a simple checkbox. However, the reality of business and IT clarifies that backups are a core component of system integrity and, as such, must be tied to SLA/OLA performance indicators. Among the latter, the most vital are:

- RPO (Recovery Point Objective)
Note that without API-level automation, the realistic RPO in Jira Cloud is 24 to 48 hours. With automation, the needed time is reduced to minutes.

- RTO (Recovery Time Objective)
Considering full schema recovery, the average RTO in the Data Center is 12 to 35 minutes. Of course, if you assume tested SQL restore paths. The measurement shrinks to even under 10 minutes with object-level restores and tested pipelines.

- Integrity rate
Backup verification using checksums and dry-run imports yields an over 99.97% success rate when using automated validation scripts on staged environments.

Final notes

All the information above shows that protecting Jira Assets should be based on a disciplined approach to backup and recovery. That includes blending native tools and automation, followed by rigorous testing.

Jira administrators can mitigate risks and ensure operational continuity by (among others) implementing database and file system backups and validating recovery procedures. Various scripts, configurations, and strategies outlined here are a foundation for resilience, adaptable to instances of different scales and complexities.

However, given the limitations of the native Atlassian tools, using a third-party solution like GitProtect is a far more convenient, safe, and efficient approach. The software allows you to manage all aspects of a reliable backup and disaster recovery process quickly. That includes granular restore, automation without maintenance, and cross-tool dependency protection.

Let’s not forget unmatched RPO and RTO times with over 99,97% success rate. These give any Jira admin more confidence and a sound argument in security-related activities.

✍️ Subscribe to GitProtect DevSecOps X-Ray Newsletter – your guide to the latest DevOps & security insights

🚀 Ensure compliant DevOps backup and recovery with a 14-day free trial

📅 Let’s discuss your needs and see a live product tour

Azure DevOps Pipelines 101: A Beginner’s Guide to CI/CD

GitProtect Team — Thu, 04 Dec 2025 14:46:35 +0000

In software engineering, the deployment process is not just about running a script and hoping it sticks. A big part of it is automation, not as a luxury, but a necessity. And that’s where Azure Pipelines steps in. The software provides a robust CI/CD engine embedded in the Azure DevOps ecosystem.

Developers and DevOps engineers working with version control systems, containers, or even legacy monoliths can leverage Azure Pipelines. It offers the structured scaffolding needed to build, test, and deliver code at scale, including support for major languages.

How to use it: Azure Pipelines

It all starts with the deceptive simplicity of Azure DevOps structure. In short, you can describe it as “define how your code should be built, tested, and deployed. Then, let the platform handle the sequence.”

The ‘how’ resides in a YAML file. It becomes the blueprint for your pipeline run. But while syntax and indentation are essential, what truly matters in understanding the conceptual building blocks is:

pipelines
stages
jobs
tasks
steps

A pipeline in Azure DevOps isn’t a single process. It’s a hierarchy that consists of multiple stages. Each one contains one or more jobs. Every job can execute a series of tasks – either in sequence or in parallel jobs – depending on how you configure the agent pool and pipeline triggers.

Azure Pipelines

Azure Pipelines support a wide array of project types, programming languages, and deployment targets. The solution always scales to fit, whether you’re:

pushing Java microservices to Azure Container Registry
compiling an iOS app on self-hosted macOS agents
publishing .NET artifacts

Azure Pipelines’ hybrid architecture distinguishes it from other CI systems. It offers both Microsoft-hosted agents for ephemeral, on-demand builds and the option to use your own infrastructure via self-hosted agents. This allows you tighter control over security, dependencies, and runtime environments.

Another thing is virtual machines. They spin up quickly and run your build jobs. Then they vanish, leaving only pipeline artifacts behind. You can also orchestrate parallel jobs or multi-phased builds that span staging and production environments – an essential capability for continuous delivery pipelines.

Azure DevOps pipeline

When creating a new pipeline in Azure DevOps, you begin by selecting a source from your version control repository. This could be GitHub, GitLab, Bitbucket, or Azure DevOps – any system that supports Git will do.

When the source is wired, you define the pipeline code using a YAML file typically stored at the root of your repository.

Such a YAML definition becomes the single source of truth for how your builds and deployments execute. The pipeline automatically builds the code, runs unit tests, packages the output into executable files, and ships the release to the target platform.

Continuous Integration

This topic may seem exploited, yet CI isn’t a buzzword. It’s a discipline. In Azure DevOps, continuous integration (CI) begins when code is pushed to the repository. Pipeline triggers – explicitly or inferred – initiate the build pipeline.

These pipelines can validate pull requests, enforce code quality rules, and block bad merges before they reach the mainline.

Running unit tests, performing test integration routines, and scanning for security flaws become routine checks rather than manual chores. Automation reduces the cognitive load on teams and reinforces engineering discipline.

Azure DevOps

It’s worth underlining that Azure DevOps is a complete lifecycle platform, not just a build server. It ties together

code repositories
work tracking
testing infrastructure
artifact storage

Azure DevOps services integrate tightly with pipelines, enabling teams to trace every pipeline run back to a specific commit, pull request, or work item. The Azure DevOps organization URL becomes the entry point to your pipeline ecosystem. It defines the workspace under which you operate.

Within that, you can create multiple projects, assign role-based access control, and set up audit trails for every change and deployment.

Continuous Delivery

While continuous integration (CI) focuses on building and testing, continuous delivery extends the pipeline all the way to production. Azure Pipelines offers native container support, allowing you to create a release pipeline efficiently. It enables you to push images directly to Azure Container Registry and deploy containers with zero manual intervention.

Release pipelines manage the deployment process across various stages – development, QA, staging, and production. You can create a controlled and auditable release mechanism when you define:

release gates
environment variables
deployment tasks
approval workflows

Build pipeline

Looking at the anatomy, a build pipeline includes:

source checkout
dependency resolution
build compilation
artifact packaging
publishing

Whether using a Maven pipeline template, a .NET Core build task, or scripting languages like Bash or PowerShell, the pipeline provides hooks at every step.

The output of a build pipeline is one more pipeline artifact. Release pipelines or other downstream jobs, then use these. You can configure pipeline settings to optimize execution and manage caching. You can also use secure secrets management to handle sensitive configuration data.

First pipeline, new pipeline run

From a beginner’s perspective, the first pipeline is both a milestone and a test of patience. You define the azure-pipelines.yml at the root of your project. A stripped-down example for a Node.js app may look like this:

trigger:
  - main

pool:
  vmImage: 'ubuntu-latest'

steps:
  - task: NodeTool@0
    inputs:
      versionSpec: '16.x'
    displayName: 'Install Node.js'

  - script: |
      npm install
      npm run build
    displayName: 'Build and Compile'

  - task: PublishBuildArtifacts@1
    inputs:
      pathToPublish: 'dist'
      artifactName: 'app'

Once committed, the pipeline will trigger automatically on each push to main. That is your entry point into CI/CD.

CI/CD – Continuous Integration, Continuous Delivery

You shouldn’t view CI/CD as a feature but as a habit. That means every commit becomes a release candidate, so code quality is validated constantly. In practice, you stop fearing deployment day. The reason is you’re deploying every day.

Azure Pipelines bolsters this lifecycle by treating your infrastructure as code. You can define pipeline steps declaratively and manage environmental variables, script arguments, and secrets like any other version-controlled asset.

Further, the code delivery can be faster because you’re confident in the progress, not just the result.

Build, test, and deploy

A mature DevOps lifecycle has three pillars – build, test, and deploy. They are hardwired into Azure Pipelines. Based on the success criteria, the pipeline supports:

test runners
quality gates
conditional deployments

Unit, integration, and UI run in isolated agents for automated tests. You can configure pipeline jobs to run multiple jobs in parallel, shaving minutes off build times and providing feedback faster.

This isn’t a nice-to-have. The build, test, and deploy approach is a survival tactic for teams that ship frequently.

Native container support

Containerized builds are a native feature in Azure Pipelines. They allow you to build Docker images and push them to the Azure Container Registry, as well as deploy containers to Kubernetes clusters or App Services.

Using containers removes variability between build environments. You no longer have to worry about a dependency working locally but failing in production. The entire build and runtime environment becomes versioned and repeatable.

Of course, pipeline steps can also run inside containers, reducing toolchain conflicts and enabling easier reuse across projects.

Advanced workflows

No complex pipeline workflow is built from scratch. It evolves. Azure Pipelines support advanced workflows that include:

matrix builds
conditional stages
custom templates
reusable pipeline script (code)

You can create deployment strategies with canary releases and blue-green deployments. Another option is rolling updates. Integrating external services from the Azure DevOps Marketplace or calling REST APIs from tasks is no problem.

More importantly, you can embed security at every stage, from verifying the integrity of the source code to scanning container images and managing secrets with Key Vault.

Security – a critical oversight

While the Azure Pipelines engine enables powerful automation, it also introduces risk. Especially when CI/CD definitions live only within the Azure DevOps organization and are tied to a specific cloud-hosted target environment (cloud build).

The YAML file defining your pipelines is typically stored in your repos and benefits from version control.

However, the pipeline execution context – agent pools, service connections, secrets, and run history – is outside the repository scope.

That’s where a solution like GitProtect for Azure DevOps becomes handy.

It ensures that the repositories containing your YAML pipelines, scripts, and deployment configurations are continuously secured.

GitProtect for the target environment

The backup tool also captures organization-level data, such as permissions, repositories, and metadata. Thus, if something goes wrong, you can restore critical access structures and codebases.

In other words, the GitProtect ensures the infrastructure-as-code backbone of your DevOps is versioned, encrypted, and recoverable.

Let’s wrap it up – protecting your pipeline infrastructure

The CI/CD process doesn’t begin with runtime. Indeed, it doesn’t end there. While secrets, access tokens, and container registries often get the attention they deserve, the foundations, like the repositories, permissions, and pipeline code, are just as critical.

A compromised or lost repository containing your pipeline YAML definitions is not just an inconvenience. It’s a failure of reproducibility.

In most Azure DevOps workflows, the pipeline logic is stored directly in the version control system, alongside application code. That makes Azure repository backup a necessary condition for safeguarding CI/CD integrity.

However, relying solely on Git itself as your safety net ignores real-world failure modes: accidental deletion, permission misconfiguration, and malicious tampering.

GitProtect in action

This is where we can mention GitProtect for Azure DevOps again, as it’s increasingly relevant. It provides automated and encrypted backups of cloud hosted pipelines and other critical components:

source code repos (including pipeline YAML files and scripts)
repository-level metadata
access permissions
wikis and documentation linked to code projects

In other words, it secures the code-defined layer of your pipeline infrastructure. If your DevOps process is truly versioned as code. Then, that code and its underlying infrastructure need proper backup, audit, and restore capabilities.

By backing up the repositories where your pipelines exist, GitProtect helps maintain the reproducibility and recoverability of your CI/CD workflows. It does this even when your Azure DevOps environment encounters human error or external disruption.

✍️ Subscribe to GitProtect DevSecOps X-Ray Newsletter – your guide to the latest DevOps & security insights

🚀 Ensure compliant DevOps backup and recovery with a 14-day free trial

📅 Let’s discuss your needs and see a live product tour

How to Prevent Backup-related Throttling Without Losing Data (or Mind)

GitProtect Team — Mon, 24 Nov 2025 09:55:18 +0000

Consider that your backup is running smoothly. Your dashboards are green. The DevOps team is sleeping peacefully. And yet, behind the calm surface, something is happening. Your API limits are being chewed up, call by call, until you’re throttled into silence. Suddenly, your system stalls – quietly and invisibly. The irony is, you build a backup system for resilience. Now, it’s the vulnerability.

There’s a quiet assumption built into most backup systems. It’ll resolve itself if you just throw enough bandwidth, retries, and threads at the problem. However, in DevOps, it’s naive. Dangerous.

Throttling in DevOps is not just a glitch

Why is it dangerous? When every DevOps tool communicates through rate-limited APIs, such as GitHub, GitLab, Bitbucket, or Azure DevOps, there is no alternative.

SaaS vendors aren’t being punitive when they impose API limits. They protect their infrastructure, maintain availability, and shield users from abuse. The problem arises when a backup solution interacts with the mentioned systems as if it owns the place. All the more so when a backup system is “unaware” of API hygiene.

So, a backup running that blindly pulls:

metadata
repositories
pull requests
webhooks
smconfigurations
comments

This is done without pacing itself. The result? From the API perspective, such a situation becomes indistinguishable from a denial-of-service attack.

Once throttling begins, the dominoes fall fast:

backup jobs stall
critical configurations aren’t captured
version histories become fragmented

Then the false assumption that everything is safe and restorable shatters.

The hidden cost of a throttled backup

You may not notice it immediately. The log will appear deceptively normal, with a few skipped objects or a slight delay here and there. And yet, the cost reveals a problem over time.

Then, you try to reverse-engineer the cause of the failure. It turns out that a silent, unreported throttling event sabotaged the entire chain. From a business perspective, it’s not a bug but an existential risk.

The whole thing is not about technical debt. It can lead to reputational damage, especially when a disaster recovery test fails to function properly. There’s also an operational cost when the dev team has to manually reconfigure environments. Additionally, audit exposure reveals that your backup missed a repository containing your compliance script.

How innovative systems avoid the trap

Effective throttling prevention is an architectural approach rather than a reactive one. It begins with backup engines deeply integrated with API rate limits, rather than just being aware of them. The big picture is that such systems don’t brute-force their way into SaaS platforms. They converse, interpret headers, as well as observe quotas. Moreover, they anticipate consequences.

This manifests, among other things, through dynamic pacing. A well-designed system reads the room. It doesn’t assume the same call rate will work at 2 a.m. and 10 a.m. The solution monitors the API’s responses, notes the Retry-After headers, and adapts its behavior without human intervention.

If it notices pressure, it backs off. When a specific endpoint is rate-limited, the flow is redirected to other tasks that can be performed in parallel without exceeding quotas.

Some systems, such as GitProtect, take this further and utilize well-designed job orchestration. Backup threads are distributed based on understanding the API’s cost per object type, rather than relying on a simplistic “repository-per-thread” logic.

A repo with massive commit histories (or one linked to CI workflows) is treated differently from a dormant wiki. Such an approach reduces unnecessary API pressure and ensures that backups don’t trip over themselves even at scale.

Incremental logic also plays a crucial role. Well-developed systems track state, not full sweeps that trigger abuse mechanisms. It’s about monitoring commit deltas, webhook triggers, and change stamps. Such an approach reduces API usage and dramatically shortens backup windows. That creates a more sustainable rhythm harmonizing with the platform’s operational limits.

Authentication method and credential distribution

One thing is barely mentioned, yet it screws up more backup ventures than experts are willing to admit. It’s the way API authentication works. Next to bandwidth, schedule, or even volume, another factor may be the damn token.

If your system utilizes a personal access token or OAuth to communicate with GitHub’s API, you might already be on thin ice. The reason is that you tied your entire backup workload to the (human) user’s rate limit. That means one well-timed backup sweep, and you’ve burned through their quota.

At the same time, the developer can’t push code or trigger a CI run. He probably can’t even click around in the interface – without getting rate-limited.

You can also use the Github App method. And that’s a completely different story, as it:

is scoped to the organization
has broader limits
doesn’t hijack anyone’s personal quota

It resembles running backups from the service entrance, not the front door. That means you’re not clogging up the hallway. Such an approach makes a difference at scale. While backing up dozens or hundreds of repos, the traffic quickly adds up. When all of that goes through a single credential – even a big one – it’s a gamble.

Unless your system “knows” how to:

split the load
distribute jobs across multiple credentials
route around the throttle points

The above may seem like a hack, but it’s a strategy. Why? Because the trick here is not about staying under the limit. The goal is to avoid sabotaging your devs. Instead of creating a burden with backups, they should be tools available when needed—without the API misbehaving.

What does throttling prevention mean for business continuity

A system noticing API limits doesn’t just avoid getting blocked. It ensures continuity and successful test restores. This way, you can bounce back in the event of:

In more strict terms, that means:

faster Mean Time To Recover (MTTR)
fewer gaps in data lineage
peace of mind when facing auditors

The above means you don’t have to inform your DevOps team that they’ve lost a week’s worth of pull requests because the backup system was shut down mid-process.

The overall effect? The operational gains compound. By avoiding overloading systems, infrastructure costs drop. At the same time, developer frustration decreases as data restoration progresses. From a security perspective, you reduce the attack surface. Why? Because your backup engine isn’t constantly knocking on the API’s door like a spam bot.

A final thought

If your current backup solution allows you to define “resilience” as merely retrying failed calls until the quota resets, then it’s not resilience. It’s just a sign of recklessness. Worse, you’re operating on borrowed time if you treat GitHub, GitLab, or Azure DevOps like a dump truck instead of a carefully rationed endpoint.

The third “if” relates to your disaster recovery plan, which hinges on restoring from a system. According to this plan, the team has problems defining and thus noticing throttling. Calling it a plan is gambling without knowing its basic rules.

Teams must also acknowledge that backup isn’t about volume, but control supported with precision. This way, you can respect the limits imposed by the systems you protect. The banal conclusion is that when your backup and disaster recovery solution doesn’t demonstrate those qualities, the question is not whether you’ll fail. It’s when.

✍️ Subscribe to GitProtect DevSecOps X-Ray Newsletter – your guide to the latest DevOps & security insights

🚀 Ensure compliant DevOps backup and recovery with a 14-day free trial

📅 Let’s discuss your needs and see a live product tour

DevOps Threats Unwrapped: Mid-Year Report 2025

GitProtect Team — Thu, 25 Sep 2025 11:53:25 +0000

From minor hiccups to full-blown blackouts, the first half of 2025 made it clear that even the most trusted DevOps platforms are not immune to disruption.

In this ecosystem, every commit, push, and deployment relies on complex systems that, despite their brilliance, are fragile. Like a Jenga tower of integrations, it takes just one wrong move – a misclicked setting, a leaked secret, an API failure – for the whole thing to wobble.

GitHub now hosts over 100 million users and 420 million repositories. Microsoft Azure DevOps has surpassed 1 billion users worldwide, while GitLab reports 30 million registered users. Bitbucket powers more than 10 million professional teams, with Jira adding millions more to this global ecosystem. But as these platforms grow in size and complexity, avoiding outages or human error becomes increasingly difficult. At this scale, with top global brands relying on them, security breaches and increasingly sophisticated cyber threats are no longer a possibility, but a certainty.

DevOps Threats Unwrapped: Mid-Year Report by GitProtect examines the threats of H1 2025, focusing on unplanned outages, attacks, and silent mistakes with severe consequences.

Key insights:

Azure DevOps recorded a total of 74 incidents, including one of the longest-lasting performance degradations that spanned 159 hours.
European users were particularly affected, accounting for 34% of all incidents on Azure DevOps.
GitHub saw a 58% year-over-year increase in the number of incidents, reaching 109 reported cases: 17 of them were classified as major, leading to over 100 hours of total disruption. April stood out as the most turbulent month, with incidents accumulating to 330 hours and 6 minutes.
GitLab patched 65 vulnerabilities and faced 59 incidents, resulting in approximately 1,346 hours of service disruption.
Bitbucket experienced 22 incidents of varying impact, which together lasted more than 168 hours.
Jira reported o*ver 2,390 hours of cumulative downtime* across its ecosystem – that’s nearly 100 full days of service disruption.
A total of 330 incidents impacted DevOps platforms in the first half of 2025.

If your DevOps pipeline is the heart of your organization’s innovation, consider these your warning signs.

Azure Devops

In the first half of the year, Azure DevOps experienced a total of 74 incidents, including 3 advisory cases and 71 incidents of degraded performance.

Some incidents impacted multiple components at the same time, while others affected only a single component. For instance, one outage could disrupt Pipelines, Boards, Repos, and Test Plans simultaneously. In our methodology, such an event is counted as one incident overall, even if it influenced several services. Within this total, the components were affected the following number of times:

Pipelines: affected 31 times (21%) – the most unstable component
Boards: affected 28 times (19%)
Test Plans: affected 28 times (19%)
Repos: affected 27 times (18%)
Core Services: affected 16 times (11%)
Other services: affected 15 times (10%)
Artifacts: affected 6 times (4%)

In January 2025, Azure DevOps users worldwide faced one of the longest-lasting performance degradations on record— a 159-hour disruption that severely impacted pipeline functionality. For almost a week, users trying to create Managed DevOps Pools within new subscriptions without existing pools experienced persistent failures. These attempts repeatedly timed out with the provisioning error: “The resource write operation failed to complete successfully, because it reached terminal provisioning state ‘Canceled’.” The issue led to delays in builds, deployments, and onboarding processes across affected environments, highlighting the operational risks tied to large-scale platform dependencies.

Another serious security challenge for Microsoft Azure DevOps in 2025 was the discovery of multiple critical vulnerabilities, including SSRF and CRLF injection flaws within the endpointproxy and Service Hooks components. These vulnerabilities could be exploited to carry out DNS rebinding attacks and allow unauthorized access to internal services. Such attacks present significant risks in cloud environments, including data leakage and potential theft of access tokens. In response, Microsoft released security patches and awarded a $15,000 bug bounty to the researchers who discovered the issues.

Additionally, it’s worth noting that European customers experienced a higher number of incidents – 27 incidents, representing roughly 34% of all incidents. In contrast, Azure DevOps users in India and Australia reported the fewest incidents of degraded performance, accounting for only 4% of all incidents.

GitHub

GitHub experienced a significant 58% rise in incidents during the first half of 2025, jumping from 69 cases in H1 2024 to 109 this year.

Among this year’s incidents, 17 were classified as major, causing over 100 hours of total disruption. That’s enough time to run over 1,000 CI/CD pipelines from start to finish or binge-watch the entire Marvel Cinematic Universe.

Seventy-eight incidents (72%) had a minor impact.

May recorded the highest number of incidents, with 23 reported cases, while April saw the longest cumulative incident duration, totaling 330 hours and 6 minutes.

In the first half of 2025, GitHub Actions emerged as the most affected component, with 17 incidents, including a major disruption in May that lasted 5 hours. The outage, caused by a backend caching misconfiguration, delayed nearly 20% of Ubuntu-24 hosted runner jobs in public repos. This could have slowed down development cycles, impacted release schedules, and reduced productivity for teams relying on GitHub Actions for continuous integration. GitHub resolved the issue by redeploying components and scaling resources, and committed to improving failover resilience going forward.

Meanwhile, attackers actively exploited GitHub to spread malware. Among the most notable malware campaigns noticed during this time were Amadey, Octalyn Stealer, AsyncRAT, ZeroCrumb, and Neptune RAT.

GitLab

In the first half of 2025, GitLab patched 65 vulnerabilities of varying severity, marking a slight decrease from the 70 vulnerabilities disclosed during the same period in 2024.

During this time, GitLab also experienced 59 incidents, totaling approximately 1,346 hours of disruption. These included partial service disruptions (20 incidents – 34%) and degraded performance (17 – 29%), followed by operational issues (10 incidents – 17%), full service outages (7 incidents, adding up to over 19 hours of downtime – 12%), and planned maintenance (5 incidents – 8%).

The longest service disruption lasted for over 4 hours and was caused by issues related to a specific worker and traffic saturation that affected the primary database. This incident led to 503 errors and impacted the availability of GitLab.com services for users.

One of the most notable incidents involved a data breach at Europcar Mobility Group data breach. The attackers successfully infiltrated GitLab repositories and stole source code for Android and iOS applications, along with personal information of up to 200,000 customers.

Atlassian

Bitbucket

In H1, Bitbucket experienced 22 incidents with varying severity, resulting in over 168 hours of downtime. Among these, 2 critical incidents lasted for over 4 hours, impacting key services including Website, API, Git via SSH, Authentication and user management, Webhooks, Source downloads, Pipelines, Git LFS, and more.

January 2025 proved to be one of the most challenging months for Bitbucket, highlighted by a major outage widely reported on DownDetector. For 3 hours and 47 minutes, access to Bitbucket Cloud’s website, APIs, and pipelines was completely unavailable, disrupting developer workflows worldwide.

Jira

Atlassian’s Jira ecosystem – including Jira, Jira Service Management, Jira Work Management, and Jira Product Discovery – experienced 66 incidents in the first half of 2025, marking a 24% increase compared to H1 2024. Altogether, these disruptions added up to more than 2,390 hours, or nearly 100 full days of downtime.

Much of this downtime resulted from a prolonged maintenance period that began in mid-March and extended through the end of May. As a consequence, users of the Free edition of Jira services, particularly those located in Singapore and Northern California, may have experienced outages lasting up to 120 minutes per customer.

As mentioned, Jira recorded 66 unique incidents. Some of these incidents impacted multiple products simultaneously. The numbers below reflect total disruptions per product rather than unique events.

Jira users were the most affected, with 52 disruptions (39% of all Jira-related service impacts). Jira Service Management followed with 46 disruptions (35%), while Jira Work Management experienced 24 (18%). Jira Product Discovery had the fewest, with 11 disruptions (8%).

Jira was also at the center of several notable incidents in early 2025. One of the most concerning involved a string of ransomware attacks carried out by the HellCat group. The attackers developed a playbook for infiltrating organizations via Atlassian Jira instances, using stolen credentials to gain access. High-profile victims included Telefónica, Orange Group, Jaguar Land Rover, Asseco Poland, HighWire Press (USA), Racami (USA), and LeoVegas Group (Sweden).

Over 300 incidents in the DevOps ecosystem

In total, 330 incidents of various severity levels were recorded across the major code hosting and collaboration platforms, ranging from Azure DevOps to Jira.

Here’s how the incident breakdown looks across platforms:

GitHub – 33% of all incidents
Azure DevOps – 22%
GitLab – 18%
Jira platform tools (Jira, JWM, JSM, JPD) – 20%
Bitbucket – 7%

While not all of them caused full-outages, the scale and distribution of these events reveal a lot about where the ecosystem’s weak points might be. Whether it’s version control, issue tracking, or CI/CD pipelines – these interruptions remind us that even the most popular platforms face reliability challenges. And for teams building software at scale, stability can no longer be taken for granted.

When Dev Platforms Go Down

DevOps teams can’t afford to wait passively when their core tools go down. Proactive backup, well-defined contingency plans, and flexible workflows make the difference between delivery and recovery.

Back it up. Use automated backups for code, pipelines, issues, and boards.
Work local. Ensure the ability to code with local clones and offline workflows.
Mirror critical repos. Redundancy across platforms (e.g., GitHub ↔ GitLab) keeps projects moving.
Review and adapt. After any outage, run a quick post-mortem. Improve what didn’t work.

Methodology note

All data comes from GitProtect’s internal analyses. Percentages may not add up to 100 due to rounding.

✍️ Subscribe to GitProtect DevSecOps X-Ray Newsletter – your guide to the latest DevOps & security insights

🚀 Ensure compliant DevOps backup and recovery with a 14-day free trial

📅 Let’s discuss your needs and see a live product tour

The Power of Scheduled Automated Backups for DevOps and SaaS

GitProtect Team — Thu, 25 Sep 2025 10:42:43 +0000

In 2020, a DevOps team at a mid-sized fintech startup almost lost its entire source code. A failed container update caused a cascading failure in their self-hosted GitLab instance. The backup was… somewhere. No one checked it in weeks. The recovery process took three days. The cost was around $70,000 in downtime and customer compensation.

The event wasn’t a matter of not having a backup strategy. It was a matter of assuming someone, somewhere, had run the proper function at the right time. In this case, no one has.

The case for scheduling. Why manual backups don’t scale

Nowadays, manual backups resemble trying to pull a horse cart onto a Formula 1 track. All the more so in DevOps. In short, they belong to another era.

Development pipelines usually evolve hourly. New repos are spun up during sprints. Secrets rotate and workflows change. No matter how much caffeine you provide, even the most focused engineer can’t match or keep up with the constant, often rapid changes in the DevOps environment.

New repositories, updated pipelines, rotated secrets, and shifting permissions – these changes can occur multiple times a day, often across distributed teams. And so, manual oversight simply can’t scale.

Scheduled, automated backups replace ad-hoc actions with digital discipline. They ensure that source code, metadata, configurations, and secrets are preserved continuously, not retroactively. And it’s not about convenience but rather data and business continuity.

Backup scheduling frameworks allow teams to define frequency, scope, and logic:

hourly backups of active projects
daily full backups of the production environment
weekly compression of dormant repositories.

Such schedulers adapt to business hours or maintenance windows. They reduce system load without sacrificing backup fidelity.

Compression. A thing for backup efficiency

Let’s assume your DevOps platform generates 100 GB of backup data per week. Now, let’s multiply that amount by 52 (weeks in a year) first, then by the number of environments you manage. Having the final number, consider your storage bill.

To reduce such a cost, you use compression. However, it’s not about lowering storage costs alone. The idea is to:

speed up transmission
reduce I/O latency
make restores faster, especially when seconds count.

It’s worth underlining that today’s backup tools (modern ones, as marketing calls them) implement block-level deduplication, delta encoding, and intelligent compression algorithms. The latter also contains a popular wording, but in this case, the mechanism doesn’t just shrink data blindly – it:

analyzes patterns
removes redundancy
stores only what has changed or is essential.

In backup, this means faster transfer and smaller storage footprints. Ultimately, this translates into quicker restores. It’s because the system avoids saving the same blocks of files repeatedly. And that’s a more efficient and context-aware solution. A smart one!

Additionally, these capabilities enable a full weekly backup to function like an incremental one. It also saves on storage space and is fast in transit while being precise in content. So, you get the complete picture instead of a burden.

Time, control, and sanity are your team’s gains

From the performance and control perspective, every engineer who doesn’t verify backups manually is doing something worthwhile. The above may sound like a silly statement, yet scheduled automation reclaims hours that would otherwise be spent clicking through logs or manually archiving repos.

It’s also about clarity. A scheduled system doesn’t forget, doesn’t get sick, distracted, or promoted to another department. It just runs as designed.

Besides, this is not limited to reducing workload only. Such an environment standardizes expectations. During audits, the team knows where to find historical states. Furthermore, in case of an incident response, they can act instead of searching.

Most importantly, automated backups restore a sense of psychological safety. That’s not fluff but operational readiness.

Monitoring and observability. Know when something goes wrong

Scheduling is only the beginning. A backup that silently fails is worse than no backup at all. Effective automated systems integrate monitoring and alerting. It isn’t restricted to “backup succeeded” banners, but provides deep insights:

skipped objects
version mismatches
retention conflicts
integrity violations and others.

REST APIs enable this telemetry to be fed directly into existing SIEM or platforms (if applicable). Backup health should be visible in the same observability space as deployment metrics and application logs. If you’re watching your pipeline latency, you should also be watching your backup status.

Best practices for backup automation in DevOps and SaaS environments

Considering best practices in backup automation for DevOps, the first principle is scope, which refers to what exactly gets backed up for faster and more reliable data recovery.

The first: scope

The catch here is not just backing up repositories, but also considering backing up metadata. SaaS platforms abstract infrastructure. That doesn’t mean, however, that data is disposable.

In a disaster scenario, restoring a Git repository without its metadata is akin to restoring a WordPress site without its database.

The second: isolation

The second thing about best practices is isolation. All backups should (or must) be stored independently of the source environment. If GitHub, Azure DevOps, Bitbucket, or GitLab goes down, you cannot rely on their API to access your saved states. Such a separation is not paranoia but a well-thought-out protocol. Following it, you can still restore your data when the main platform fails.

Of course, some may react with “duh”, yet reality shows that such a banal fact is not common knowledge. Especially among IT experts, who treat Git-based SaaS services as an ultimate and trustworthy solution.

You aren’t one of them, are you?

The third: policy

The next thing is policy. In this section, define retention rules that align with both compliance and business continuity. Although a thirty-day retention window may satisfy auditors, it may not be sufficient if a misconfiguration corrupted your system six weeks ago.

The fourth: testing

It’s a final but equally necessary element. It’s vital to keep in mind and practice that scheduled backups are as helpful as their restore scenarios. So, schedule not just backups, but the whole drill. The time to discover that your workflow metadata wasn’t included is not after a breach!

Real-world integration. How teams do it right

Picture a distributed gaming company. The organization is working with cloud-based GitOps pipelines that face frequent reconfigurations tied to multiple third-party APIs. They scheduled critical YAML files hourly, protected by immutable storage. Every restore here was cross-validated against SHA digests and tested in staging.

Another example may be related to a biotech company. Its regulatory obligations demanded the exact history of repository changes. However, their team didn’t have time to verify manual exports. Automated backups triggered by commit activity ensured that the system captured new objects in real time, while also archiving full snapshots every 24 hours. Zero-touch and fully compliant.

The examples presented in both cases are neither extravagant nor overly complex. They’re a routine, once well-designed automation is in place.

Why schedulers alone aren’t enough

Some things must go beyond scripts. Many teams are leaning on shell scripts to schedule backups via cron. Well, it’s better than nothing, but it’s also a fragile scaffold, including hardcoded paths, no integrity verification, and no centralized monitoring.

In other words, when a script fails silently, no one notices. No one, until they do. That’s why mature solutions:

integrate with IAM
offer role-based access
support granular restore and many more.

It means that whether you need to restore a deleted repository, a specific pull request comment, or an issue thread, it should be easy and quick.

The GitProtect approach

At this point, it’s worth noting that GitProtect – the Backup and Disaster Recovery system – automates backup scheduling with surgical precision. Its policy engine handles frequency, data coverage, storage targets, and retention – all in a UI or via API. The tool compresses, encrypts, and monitors all needed elements of your dataset.

And yes. It integrates with DevOps ecosystems like GitHub, GitLab, Bitbucket, Azure DevOps, and Jira. The solution allows you to see what’s necessary. Even in case you forget something, you’ll never lose visibility.

There’s something to be said for a system that keeps working long after everyone’s forgotten it’s even running. That’s more or less the point with GitProtect. You don’t just line up the schedule and walk away—it keeps things in check. Locks what’s been saved. Ensures that no one, not even those with admin keys, can tamper with the copies once they’re in place. Not by accident, not by design.

Restoring isn’t boxed in either. If things move from GitHub to GitLab – or back – the backups don’t complain. They follow. The data appears where you need it, in the format you left it.

There’s also a quiet background process that constantly checks the information it stores. Not just counting files or ticking off timestamps. It’s testing whether the backup would work if you had to lean on it. You probably wouldn’t notice unless something’s wrong. That’s the idea.

And when someone does ask for proof, compliance, audit, or legal, you’re not scrambling. Every step’s been logged already. The system isn’t shouting about it, but the record’s there. Like an invisible notebook someone’s been keeping for you.

All in all, it’s not flashy. That’s probably the point. It just doesn’t forget. Even when you do.

To sum it up

The whole idea with engaging scheduled automated backups isn’t about convenience. Maybe a bit. The main point here is data, environment, and thus, your company’s resilience. In DevOps and SaaS-driven markets, where downtime is a liability and human errors are a certainty, automation is the baseline, not the bonus.

Whether your goal is compliance, continuity, or simply a good night’s sleep, the true power of scheduled backups lies in their quiet reliability. And with the system like GitProtect, that reliability comes built-in. It’s engineered not just to save data, but to save time.

After all, things move fast. One minute, a repo’s spun up for a quick patch, the next it’s got five contributors and three pipelines hooked into it. In all that motion, expecting someone to remember to hit backup on time (every time) is a gamble. Scheduled automation cuts that risk out. It doesn’t wait on memory, meetings, or who’s on call. It just runs quietly and predictably.

And workflows, where even a slight misstep can cost a release (in a not-so-bad scenario), that kind of reliability isn’t a luxury. It’s how you stay in the game.

✍️ Subscribe to GitProtect DevSecOps X-Ray Newsletter – your guide to the latest DevOps & security insights

🚀 Ensure compliant DevOps backup and recovery with a 14-day free trial

📅 Let’s discuss your needs and see a live product tour

Measuring DevOps Success: The Metrics That Matter

GitProtect Team — Thu, 21 Aug 2025 11:58:15 +0000

You can’t optimize your DevOps if you don’t track its metrics. However, measuring DevOps performance isn’t only about vanity charts or arbitrary numbers. The right indicators show how well your software delivery solutions perform under pressure. Combined with resilience architecture, these metrics guide your engineering teams to reduce lead time, cut failure rates, and recover faster.

In other words, you have full insight into potential bottlenecks and can introduce changes where they matter most. This is a path to optimizing processes and maintaining continuous improvement, which boosts business goals and KPIs.

But here’s the catch. Metrics don’t exist in isolation. Without the proper safety measures, all indicators are fragile and susceptible to even the slightest changes. For instance, robust backup and disaster recovery protect performance baselines and ensure that DevOps velocity doesn’t come at the cost of reliability.

Metrics that matter. An example of measuring DevOps success

If you are looking for metrics that correlate directly with business goals and outcomes, you can check Google’s DevOps Research and Assessment (DORA). The program included the analysis of 32,000+ professionals across 3,000+ organizations.

Based on that, it was possible to establish the performance of elite teams (in 2023):

It’s clear that these metrics and their values correlate directly with a practical representation of business success, including:

higher profitability
customer satisfaction
team engagement (and other)

From code to deployment. How metrics map to risk

The Deployment Frequency (see the table above) shows your ability to ship quickly. Typically, teams doing continuous delivery deploy 10-20 times per day. More deploys mean more moving parts and more room for mistakes.

For example, deleting a GitLab tag used in deployment triggers or corrupting a YAML file mid-release can slow or stop the entire release pipeline.

The Lead Time for Changes measures the time from commit to production. According to the theory, CI/CD pipelines automate this process. In practice, however, corrupted pipelines or lost secrets slow everything down.

For better clarity, consider a case where an Azure DevOps pipeline is deleted during a refactor. Reproducing the exact pipeline from memory or fragments can take hours or days without a versioned backup.

Change Failure Rate (CFR) reflects testing quality as well as system complexity. The faster you ship, the more pressure on automated test reliability. To prevent potential production breaks due to a lousy merge or broken environment variable, you need a sound backup platform enabling point-in-time rollback of the repo or pipeline configuration (keeping acceptable CFR).

The above also affects Mean Time To Restore (MTTR), which is critical for resilience. Let’s say the Jira configuration is damaged after an app update, or Bitbucket repos become compromised when a misconfigured webhook is deployed. A low MTTR is the difference between a minor disruption and a business outage in those cases (and others). Here, time-to-recovery should be measured in minutes, not hours.

An example of code to track deployment frequency automatically

You can track the deployment frequency using a few mechanisms, including:

commit-to-prod logs
tagging events
pipeline metadata.

For instance, consider a basic Python script to count deployments per day (utilizing GitLab API):

The data obtained this way allows you to build internal benchmarks and detect pipeline failures and changes in productivity performance (drops). A good idea is to combine with MTTR and failure rates to correlate deploys with breakage.

Failure scenarios that backups can prevent

Talking about failure scenarios, connecting metrics with real-world DevOps threats creates a few possibilities.

For instance:

It’s worth noting that backups allow for forensic rollback. In other words, teams don’t just fix the problem; they learn from it and maintain their velocity.

Integrating backup into DevOps metrics strategy

Backup integration into your DevOps metric strategy means making it a fundamental part of your delivery process. With the full deployment of a sound backup platform, you can cover much ground.

That includes your Git repos on:

GitHub
GitLab
Bitbucket
Azure DevOps.

Using tools like GitProtect.io also allows you to take care of the backups in Jira (both Jira Cloud, Jira Service Management, and Jira Assets). Especially when it comes to Jira projects and configurations, along with the critical elements of:

webhooks
deployment keys
environment variables
audit logs
permissions.

This versatile capacity allows you to conveniently embed backups into the fabric of your delivery process. You can set up policies to automatically take a snapshot of your system before every production deployment. Then, it’s time for backup verification and restore testing.

Make them a standard part of your sprint cycles. It’s a good practice and a profitable move. Of course, tracking and logging the restore events to correlate with MTTR and SLA adherence is still crucial.

Going further, advanced teams use or treat logs as observability signals. They usually help visualize resilience over time.’

A few inconvenient facts

If you don’t have your metrics or they vanish along with the pipeline, they were never metrics. You only had guesses. In elite DevOps organizations, speed and reliability are intertwined. The four key DevOps metrics – deployment frequency, lead time, change failure rate, and MTTR – don’t just describe team performance. As you probably know, they define it.

However, all provided numbers are volatile and vulnerable without a solid BDR (backup and disaster recovery) plan. That’s why turning your backups into a measurable advantage is vital. This way, you reduce MTTR, lower failure rates, and maintain lead time even in disaster scenarios.

This isn’t just operational hygiene. Consider it a performance multiplier.

So, what’s with GitProtect.io in DevOps metrics?

GitProtect is a sound and versatile backup and disaster recovery system for the DevOps ecosystem. The tool supports the platforms mentioned above: GitHub, GitLab, Bitbucket, Azure DevOps, as well as Jira.

The described software plays a pivotal role in ensuring and maintaining the stability and continuity of DevOps processes. It directly serves the key success metrics discussed so far.

Deployment Frequency support

Again, high deployment frequency (even multiple times a day) increases the risk of errors; think of deleted GitLab tags or corrupted YAML files during releases. The easiest and most effective way to mitigate these and other risks is to utilize:

Automated backups of repos and metadata, especially scheduled, allow for rapidly restoring lost data without disrupting the release cycle. As for flexible recovery, the point-in-time restore functionality makes it easier for teams to resume deployment processes quickly, maintaining high deployment frequency.

Using GitProtect, teams can sustain continuous delivery and achieve elite performance levels (on-demand, multiple daily deployments).

Reducing Lead Time for changes

Losing critical DevOps and/or project management data can significantly extend the time from code commit to production. To address this problem, you can protect the entire DevOps ecosystem. Backups cover source code and metadata with webhooks, deployment keys, environmental variables, etc. That eliminates the need for manual reconstruction.

Another element is cross-over restore. The ability to restore data between platforms (e.g., from GitLab to GitHub) supports and ensures continuity even during outages.

A proper backup and disaster recovery system minimizes delays caused by failures and enforces teams to achieve lead times under an hour – as seen in top performers.

Lowering the Change Failure Rate (CFR)

The growing likelihood of errors that lower CFR often requires IT teams to focus on two significant elements.

Having a higher risk of faulty merges or broken environment variables means you need to utilize the restoration to the last known good state mechanism. In cases like a corrupted .gitlab-ci.yml file or misconfigured Bitbucket branch protection rules, you should be able to roll back to the correct configuration.

That also means strong encryption and secure storage. Your data should be protected with AES-256 encryption – in transit and at rest – safeguarding against ransomware and other threats. Naturally, it reduces the risk of failure due to security breaches.

In that matter, using GitProtect enhances test and system reliability and helps maintain a 0-15% CFR.

Minimizing Mean Time To Restore (MTTR)

You don’t need to be convinced that MTTR is critical for your system’s resilience. For example, during incidents like corrupted Jira configurations or compromised Bitbucket repos.

The first thing that comes to mind in this topic is undoubtedly granular and rapid recovery. Such a function and ability allow you to restore specific elements, like a single Jira issue or YAML file. The same goes for entire environments—in minutes (not hours)!

That also means you can establish disaster recovery readiness. Utilizing mechanisms like Disaster Recovery and cross-platform restoration (on-premises, cloud, or cross-platform) guarantees business continuity during major outages, such as a GitHub downtime.

Let’s not forget compliance with the 3-2-1 rule (at least). The reason is simply the support for multiple storage locations (local and cloud) and unlimited retention to guarantee reliable data recovery.

Using GitProtect, you can maintain MTTR below one hour. This will minimize downtime and financial losses (e.g., $9,000 per minute of downtime, as noted in the article).

Enhancing overall resilience and compliance

With everything described to this point, something needs to be underlined. The importance of backup as part of DevOps metrics strategy is particularly important in the context of the Shared Responsibility Model.

Read more about your responsibilities in GitHub, GitLab, Azure DevOps, and Atlassian.

Responsibility (in any meaning) necessitates compliance with security standards. Certifications like SOC 2 Type II, ISO 27001, and GDPR ensure adherence to legal and regulatory requirements. Especially if the latter are critical for a given industry, like healthcare or finance.

However, compliance needs to be followed by centralized management. The goal is to simplify performance and track compliance with:

backup monitoring
SLA reports
notifications (email/Slack).

Yet another thing is integration with DevOps processes. You can strengthen process resilience with automated snapshots before deployment and restore tests within sprint cycles.

From GitProtect’s perspective, you can protect data and allow your DevOps teams to focus on innovation rather than manual recovery. In other words, you can improve overall business KPIs like profitability and customer satisfaction.

Possible scenarios with GitProtect’s role

Consider a few possible scenarios presented below:

Summary of measuring DevOps success

There’s no doubt that DevOps metrics and tracking them are vital to optimizing, for instance, software delivery or business outcomes in general. Teams considered elite achieve multiple daily deployments, lead times under one hour, CFR of 0-15%, and MTTR below 60 minutes. They drive profitability and customer satisfaction.

High deployment frequency increases risks like corrupted pipelines or lost configurations, so a solid backup system mitigates them. Especially with automated snapshots and point-in-time restores. The same goes for supporting platforms like GitHub, GitLab, Bitbucket, Azure DevOps, and Jira.

Finally, incorporating backup systems like GitProtect into your business platform boosts resilience, reduces MTTR, and helps maintain performance, which is essential for DevOps success.

✍️ Subscribe to GitProtect DevSecOps X-Ray Newsletter – your guide to the latest DevOps & security insights

🚀 Ensure compliant DevOps backup and recovery with a 14-day free trial

📅 Let’s discuss your needs and see a live product tour

Dev Platform Breaches: How GitHub, Jira & Confluence Exposed Mercedes, Apple, Disney & Others

GitProtect Team — Thu, 07 Aug 2025 12:30:54 +0000

Welcome to the DevOps multiverse. Here, code is currency, while platforms like GitHub, Jira, and Confluence power critical infrastructure. Here, even the smallest misstep can trigger a chain reaction measured in gigabytes of leaked data, thousands of compromised credentials, and millions of dollars in financial losses, not to mention reputational damage.

These risks aren’t theoretical. Breaches at household-name enterprises expose a harsh truth: DevOps pipelines have become the new battleground for cyberattacks. What connects Mercedes-Benz, Apple, Cisco, and The New York Times? All became victims of DevOps security failures, proving that even tech giants aren’t immune when code meets cybersecurity complacency.

Key insights:

Mercedes: 270GB of proprietary code exposed via leaked GitHub token
New York Times: 210GB internal data leaked, including Wordle source code
Apple: Internal Jira & Confluence tools leaked
Disney: 2.5GB of corporate secrets stolen by Club Penguin fans
Schneider Electric: 400K rows of user data stolen, $125K ransom demanded
Cisco: GitHub breach leaked source code, AWS keys, and Jira tickets
WordPress: 390K+ credentials stolen via fake GitHub repo
Fake WinRAR: Site distributed malware via GitHub
Python: Leaked GitHub token threatened core PyPI repositories

Continue reading for a detailed analysis of these breaches, or check the complete CISO’s Guide to DevOps Threats.

Global Cybersecurity Landscape at a Glance

Globally, cyber attacks occur with alarming frequency – roughly one every 39 seconds – amounting to over 2,000 incidents each day. This relentless pace fuels a massive economic toll: cybercrime is projected to cost the global economy $10.5 trillion annually by 2025, climbing to $15.63 trillion by 2029, according to Cybersecurity Ventures. The United States alone accounts for 59% of ransomware attacks, and 70% of data breaches cause significant operational disruptions. The ripple effect doesn’t stop at the breached company — it also hits business partners, clients, and entire supply chains, amplifying the overall impact of the attack.

The notion of complete immunity has always been a myth. Even the biggest organizations remain vulnerable.

Mercedes: 270GB of proprietary code exposed via leaked GitHub token

Due to a mishandled GitHub token, Mercedes-Benz’s source code was exposed to the public. A Mercedes-Benz employee leaked a GitHub token in their repository, granting unrestricted access to all source code on the company’s GitHub Enterprise server. During the exposure, attackers could have accessed critical information, including API keys, design documents, database credentials, and other sensitive data, which could have potentially caused financial, legal, and reputational damage.

New York Times: 270GB internal data leaked, including Wordle source code

270GB of internal data belonging to The New York Times was exposed, including alleged source code for Wordle, internal communications, and sensitive authentication credentials linked to over 5,000 GitHub repositories. The New York Times confirmed that the incident involved the inadvertent exposure of credentials to a third-party code platform. However, the organization stated that no unauthorized access to its internal systems had been detected and that operations remained unaffected.

Apple: Internal Jira & Confluence tools leaked

In June 2024, a threat actor known as IntelBroker claimed responsibility for a breach of Apple’s internal authentication infrastructure. The leaked data included proprietary plugins and configurations used to integrate AppleConnect-SSO with Jira and Confluence, posing significant supply chain risks. According to cybersecurity firm AHCTS, the breach did not affect end-user services.

Disney: 2.5GB of corporate secrets stolen by Club Penguin fans

Club Penguin fans exploited Disney’s Confluence server to access old internal game data but inadvertently stole 2.5 GB of sensitive corporate information, including developer tools, internal infrastructure, advertising plans, and business documentation. The breach occurred using previously exposed credentials and included internal API endpoints, S3 bucket credentials, and links to developer resources, potentially increasing Disney’s exposure to further attacks.

Schneider Electric: 400K rows of user data stolen, $125K ransom demanded

Schneider Electric confirmed a breach involving its internal project tracking platform, hosted in an isolated environment. The threat actor, known as “Grep,” claims to have accessed the company’s Jira server using exposed credentials and stolen 40GB of data, including 400K rows of user information, 75K unique email addresses, and other critical project data. The stolen information reportedly includes details about projects, issues, and plugins, and the attackers have demanded $125,000 to prevent a data leak.

Cisco: GitHub breach leaked source code, AWS keys, and Jira tickets

Cisco confirmed that some files were stolen after hacker IntelBroker claimed access to source code, credentials, and other sensitive data via GitHub and a SonarQube project. While no internal systems were breached, the attacker exploited a public-facing DevHub used for customer resources. Cisco reported that only a limited number of files were exposed, with no sensitive personal or financial data found.

WordPress: 390K+ credentials stolen via fake GitHub repo

A malicious GitHub repository enabled the exfiltration of 390K+ credentials, primarily targeting WordPress accounts, through a fake tool called “Yet Another WordPress Poster”. The repository, associated with a threat actor dubbed MUT-1244, also deployed malware via a rogue npm dependency and phishing emails. Victims included pentesters, security researchers, and malicious actors who inadvertently exposed sensitive data such as SSH private keys and AWS credentials. MUT-1244’s tactics included creating trojanized GitHub repositories hosting fake PoC exploit code and employing phishing emails to deliver payloads like cryptocurrency miners and data theft tools.

Fake WinRAR: The site distributed malware via GitHub

Security researchers at SonicWall uncovered a fake WinRAR website (winrar[.]co) hosting a malicious shell script designed to download further malware from a GitHub repo named “encrypthub.” The repository contained ransomware, crypto mining software, information stealers, and injection tools, with harvested system data sent to a Telegram account — illustrating the danger of typosquatting and weaponized open-source infrastructure.

Python: Leaked GitHub token threatened core PyPI repositories

Researchers at JFrog identified a leaked GitHub token embedded in a public Docker container, granting access to sensitive PyPI repositories. The token, belonging to PyPI admin Ee Durbin, was exposed due to misconfigured GitHub API usage. Although the token was quickly revoked, it posed a critical supply chain risk. Separately, Checkmarx reported malicious PyPI packages exfiltrating data via Telegram bots.

The untold impact of DevOps data leaks

While DevOps breaches at companies such as Mercedes-Benz, Apple, The New York Times, and Cisco often make headlines, the true cost of these incidents is rarely disclosed.

At first glance, the impact may appear limited to brief negative press or a dent in reputation. But beneath the surface, the real price tag can be far more significant, ranging from:

costly data recovery and environmental restoration,
loss of competitive edge due to exposed code or strategic plans, disruptions to business continuity,
to potential regulatory penalties.

The bottom line? Most organizations downplay the full scope of these incidents in public statements. Yet the sheer scale of the leaks—hundreds of gigabytes of data, millions of records, and sensitive internal repositories—reveals a much deeper, and likely more damaging, reality.

To dive deeper into these incidents and uncover emerging trends in cyberattacks targeting DevOps environments—including threats like Lumma Stealer, NJRat, fake GitHub repositories, and GitLab exploits—read the full CISO’s Guide to DevOps Threats.

✍️ Subscribe to GitProtect DevSecOps X-Ray Newsletter – your guide to the latest DevOps & security insights

🚀 Ensure compliant DevOps backup and recovery with a 14-day free trial

📅 Let’s discuss your needs and see a live product tour

How To Restore a Deleted Branch In Azure DevOps

GitProtect Team — Thu, 07 Aug 2025 12:15:09 +0000

Human error is one of the most common causes leading to data loss or data breaches. In the ITIC report, they state that 64 % of downtime incidents have their roots in human errors.

If you think that in SaaS environments all your data is safe, you need to think once again. All SaaS providers, including Microsoft, follow the Shared Responsibility Model, which states that the service provider is responsible for the accessibility of its infrastructure and services, while a user is responsible for their data availability, including backup and disaster recovery.

So, who will be responsible for data recovery if your Azure DevOps branch is deleted? This can be caused by a range of things, from accidental deletion or simple cleanups to incorrect coding practices. Hovewer, the user is the one who needs to deal with the consequences of deletion, such as data loss, failure of compliance, or legal requirements. Thus, it is necessary that your organization can recover fast from any event of failure, including accidental deletion.

In this article, we will outline the best ways and practices to restore your deleted Azure DevOps branch. Though it’s worth stating that the safest and most reliable method is to implement a backup & DR solution to ensure your Azure DevOps security strategy. Such tools, as GitProtect backup & DR software for Azure DevOps, can provide you with the most flexible options for securing and restoring branches.

Accidental deletion?

Human error remains one of the leading causes of failures, including accidental deletions. In fact, research from ResearchGate shows that 32% of data loss incidents are due to human mistakes. This makes it critical to pair secure coding practices with a reliable backup strategy to keep your Azure DevOps branches both protected and recoverable.

Consider this scenario: your teammate accidentally deletes a feature branch just before it’s merged. How quickly can you restore it and resume work? With the cost of downtime reaching up to $9,000 per minute, and that’s without accounting for regulatory penalties… So, every second counts.

Accidental deletion is a common risk that organizations must plan for in both their operational and compliance strategies. When equipped with the right backup solution and a well-tested Disaster Recovery plan, restoring any branch can be fast, seamless, and secure.

Proper branch management in Azure DevOps

To avoid losing any branches to accidental deletions, it is crucial to implement secure coding practices along with proper configuration of branch policies. To edit branch policies, you will need to be a member of the Project Administrators security group or at least have repository-level Edit policies permissions. Manage your branch policies by locating and selecting Repos, then Branches to open the web portal. Now, simply find the branch you need to adjust using the S*earch branch name* in the upper right corner. Click on More options right next to the branch and select Branch policies from the menu available.

Apart from implementing a third-party backup & DR solution and adjusting the policies for your branches, it is important to pay attention to other key best practices. To avoid errors, accidental deletions, and branches being lost, try to keep your strategy simple and build according to the following practices:

Maintain good quality and an up-to-date main branch
Make use of feature branches for any new features or bug fixes
Using pull requests, merge your feature branches into the main branch

Possible ways to restore deleted branches

You can use Git commands to restore the branch. This process relies on Git’s reflog (reference log), which keeps track of changes to the repository, including branch deletions. You can also restore from your local repo or use the web portal.

Method # 1: Azure DevOps web portal

As stated by Azure DevOps official documentation, to ‘restore a Git branch in your own repo from Visual Studio or the command line, push your branch from your local repo to Azure Repos to restore it’. This method is a convenient way to restore a deleted git branch. To start off, locate your repository, open it, and go to the Branches view. Now, find your specific branch, using the Search all branches option in the top right corner. Then, click the link to search for the exact match in deleted branches.

This option helps to gain info about the commits, who deleted the branch, and when. Finally, in order to restore a deleted git branch in your Azure DevOps, select the “…” icon, which is right by the branch name, and then click Restore branch from the list. The branch will then be recreated at the last commit to which it pointed.

Source: Restore a deleted Git branch from the web portal

Bear in mind, branch policies and permissions do not get restored. Additionally, if you have used the same branch name for a number of different commits, you might not see all the commits you expected to have when you restore the deleted branch. To help with that, simply go to the Pushes page of your restored branch and then see the whole history of your branch.

Also, to get to a specific commit, you will need to select New branch from the “…” icon. Then, you can use a pull request, cherry-pick, or merge to add any of the commits back into your desired branch.

Source: Restore a deleted Git branch from the web portal

It is best suited for those who:

prefer a GUI-based method rather than a command-line,
have full access to the repo, need quick restore
want to review any commit info (for example, who deleted the branch)

Hovewer, there are some facts that you need to keep in mind. This process of restore isn’t automated; thus, it increases the risk of mistakes, especially under time pressure or during the incident. Another important thing is a limited time frame. Azure DevOps retains deleted branches for only 90 days. After that, the data is permanently deleted, and if you notice the deletion after that time, your data might be lost.

What is required to restore a branch?

It is important to remember that there are certain requirements outlined that you will have to meet in order to be able to restore branches. Keep in mind that users with Stakeholder access will have full access to Azure Repos (including viewing, cloning, and contributing). Take a look below to see more detailed requirements.

Source: Azure DevOps documentation

Method # 2: Restore from the local repository

Since git is a distributed system, the developer’s local repository is actually a full copy of the project history. So all the commits and references are there, provided ‘git fetch’ has not been run, as it removes or updates the references from remotes.

If your branch was deleted from the remote, restoring from the local repo is a viable option. Now, in your local repo, run ‘git branch -r’ and this should list all the remote branches. So, when someone deletes ‘stage’ on the remote, but you haven’t fetched yet, your local still has origin/stage. Now, create a new local branch – ‘stage’, that points to the desired commit that your deleted branch pointed to. To do this, run ‘git checkout -b stage origin/stage’. Now that you have restored your branch locally, simply ‘git push’ it to Azure DevOps.

However, if you did fetch after deletion, there is a chance your reference origin/stage, along with the deleted branch, may be gone.

Method # 3: Recovering a Deleted Branch with ‘git reflog’

If you’ve accidentally deleted a branch using git branch -D , then git reflog can help. Reflog (reference log) keeps track of where your HEAD and branch references have pointed in your local repository, even after actions like deletions, resets, or rebases. It allows you to view the recent history of commits, including those that may no longer be part of a visible branch.

Option 1: Immediate Recovery After Deletion

If you just deleted the wrong branch and haven’t run many additional Git commands, the recovery can be almost instantaneous. Simply:

Check your terminal output — it often displays the last commit SHA associated with the deleted branch.
If not, run git reflog to locate the commit hash tied to the deleted branch.
Once you have the correct SHA, restore the branch with: git checkout This checks out the commit in a detached HEAD state.
To recreate the branch: git checkout -b This command creates a new branch at that commit and reattaches HEAD.

This approach ensures that your work isn’t lost, provided the deleted commits haven’t yet been garbage-collected by Git (which typically occurs after 90 days).

Option 2: Recovering a Branch a while after deletion

If you didn’t notice the deletion right away, or have made other changes since, you can still recover the branch using git reflog:

Run the reflog to inspect your recent Git history: git reflog This will show a list of recent HEAD movements, including the commit where your deleted branch last pointed.
Find the correct entry — look for the commit SHA that corresponds to the last known state of your deleted branch. It might be labeled something like: abc1234 HEAD@{4}: checkout: moving from to master
Check out that commit using: git checkout abc1234 This puts you in a detached HEAD state at the desired commit.
Recreate the branch at that commit: git checkout -b
Optionally, push it back to the remote if needed: git push origin

This method works even if some time has passed, as long as the commit hasn’t been garbage-collected (which by default happens after 90 days in Git).

Method # 4: Third-party solutions to address risks

Relying on a third-party backup and disaster recovery solution is the most dependable way to restore your Azure DevOps data, even beyond the 90-day mark after a branch has been deleted. Every project within Azure DevOps should be properly secured to avoid disruptions and data loss.

Microsoft itself outlines in its documentation that securing Azure DevOps data is the user’s responsibility, and it is recommended to implement third-party backup and disaster recovery solutions for maximum security and compliance.

Unlike manual restore methods or temporary workarounds, a trusted backup solution functions as an insurance policy; it simplifies and accelerates restore processes while providing a reliable safety net. It reduces downtime, minimizes risk, and offers guaranteed data recovery, something that manual processes can’t ensure.

How to restore a deleted branch in Azure DevOps with GitProtect

Without a proper backup strategy aligned with industry best practices, recovery may not be possible when disaster strikes. That’s why your backup must include:

Automated, scheduled backups that meet your defined RPO and RTO objectives,
Long-term or even infinite retention, enabling point-in-time recovery and fulfilling Shared Responsibility Model obligations,
Multi-storage localization, which allows you to have your backup copies in multiople locations, both cloud and local,
Replication,
AES encryption at rest and in transit, with the option to use your own encryption keys,
Ransomware protection, essential as backup, is your last line of defense,

These capabilities ensure your Disaster Recovery plan is ready for every scenario, including accidental deletions. GitProtect provides all these backup features and even goes beyond to make sure that every disaster scenario is foreseen. Thus, with the solution, you get key restore capabilities:

Point-in-time restores – go back to any specific point in time and restore data from that period.
Granular restore – specify what pieces of Azure DevOps data you need to restore.
Full data recovery – use to recover the entire Azure DevOps environment.
Cross-over recovery – restore your Azure DevOps data to another Git hosting service (GitHub, GitLab, Bitbucket).

So, to restore your deleted Azure DevOps branch from a backup, you just need to pick up the moment from which you need to restore your data, and run the restore.

Let’s imagine that your organization’s branch was deleted yesterday, so all you need to do is roll back your data from before yesterday.

Conclusion

To sum up, for the highest level of security and most flexible restore options, it is recommended to implement third-party backup and disaster recovery vendors, such as GitProtect. This way, you get a preventive safety net in the form of immutable, automated, and scheduled backups along with many different restore capabilities to accommodate any restore scenario you may be facing in Azure DevOps.

✍️ Subscribe to GitProtect DevSecOps X-Ray Newsletter – your guide to the latest DevOps & security insights

🚀 Ensure compliant DevOps backup and recovery with a 14-day free trial

📅 Let’s discuss your needs and see a live product tour