When attackers compromised a third-party contractor's account and accessed Żabka's Jira and GitLab environments, they didn't exploit a zero-day vulnerability or defeat sophisticated defenses. They walked through an open door that 12,800 franchise locations trusted was locked.
The breach, which exposed internal documentation, authentication tokens, and source code, represents a pattern you've likely seen before: third-party access controls that look adequate on paper but fail under real-world conditions. The attackers advertised the stolen data for €5,000 on a cybercrime forum, a price point that suggests the value wasn't in payment data or customer records (which remained secure) but in the operational intelligence that third parties routinely access.
Why These Mistakes Keep Happening
Third-party risk management often fails because it's treated as a compliance checkbox rather than an ongoing security discipline. Your team completes the vendor security questionnaire, files the SOC 2 report, and moves on. Meanwhile, the contractor's employee who configured your Jira integration six months ago still has admin-level access they haven't used in weeks.
The gap isn't in your policies. It's in the operational translation of ISO/IEC 27001 Annex A.5.19 (information security in supplier relationships) and A.5.20 (addressing information security within supplier agreements) into daily access management practices. You've documented the controls. You haven't operationalized the monitoring.
Mistake 1: Treating Third-Party Access as Binary
You grant access or you don't. The contractor needs Jira, so they get Jira. They need GitLab for a three-month integration project, so they get GitLab. Six months later, when the project is complete and the contractor moves to a different client engagement, that access remains active.
Why it happens: Your identity governance process treats employees and third parties identically. You've built robust joiner-mover-leaver workflows for staff, but contractors don't trigger the same review cycles because they're not in your HRIS system.
The consequence: According to the breach disclosure, attackers accessed Żabka's Jira environment and multiple GitLab repositories through a third-party account. This suggests the compromised account had permissions across multiple systems, not just the narrow scope required for a specific deliverable.
The fix: Implement time-bound access with mandatory renewal for all third-party accounts. In your Identity and Access Management system, configure contractor accounts to expire automatically after 90 days unless a business owner submits a justification and re-approves. This aligns with the Principle of Least Privilege in NIST SP 800-53 control AC-6 and forces regular validation that the access still serves a legitimate business purpose.
For critical systems like Jira and GitLab, create project-specific service accounts rather than granting contractors access to your production environments. When the integration project ends, you decommission the service account, not the contractor's broader access.
Mistake 2: Skipping the Access Inventory
You know which vendors have contracts. You don't know which vendor employees have active credentials in your systems, what permissions they hold, or when they last authenticated.
Why it happens: Your procurement team manages vendor relationships. Your IT team manages system access. Neither owns the intersection. When the vendor's project manager leaves and a new engineer joins, nobody tells your identity team to revoke one account and provision another.
The consequence: The attackers didn't breach Żabka's infrastructure directly. They compromised an external service provider's account, which means your perimeter security worked, but your access governance didn't. You can't protect accounts you don't know exist.
The fix: Build a quarterly access certification process specifically for third-party accounts. Export all non-employee identities from your directory service and send the list to business owners with three questions: Does this person still need access? To which systems? At what permission level?
This isn't a compliance exercise. It's threat surface reduction. Every certification cycle, you'll discover accounts for contractors who left the vendor six months ago, test accounts that were never decommissioned, and integration credentials with permissions far beyond their original scope.
Document this in your Statement of Applicability under ISO/IEC 27001 control A.5.18 (access rights). When auditors ask how you ensure third-party access remains appropriate, you'll show them certification records, not policy documents.
Mistake 3: Assuming Vendor SOC 2 Reports Cover Your Risk
Your vendor has a SOC 2 Type II report. You've verified their controls for logical access, encryption, and change management. You've checked the box on third-party risk assessment. Then their employee's laptop gets compromised, and attackers use cached credentials to access your Jira instance.
Why it happens: The vendor's SOC 2 report describes controls over their infrastructure and services. It doesn't describe controls over the devices their employees use to access your systems. You've validated their security posture. You haven't validated their endpoint security, password management, or whether they enforce multi-factor authentication for accessing client environments.
The consequence: When the source article reports that attackers accessed internal systems "through a third-party contractor's account," the breach vector likely wasn't Żabka's controls failing. It was the contractor's security hygiene failing, which then became Żabka's problem.
The fix: Require multi-factor authentication for all third-party access to internal systems, regardless of the vendor's security certifications. Configure your identity provider to enforce MFA at the application level for Jira, GitLab, and any system containing authentication tokens or source code.
This addresses NIST Cybersecurity Framework (CSF) 2.0 function PR.AC-7 (users, devices, and other assets are authenticated). The vendor's SOC 2 report tells you they have good controls. Your MFA requirement ensures those controls protect your data even if the vendor's employee violates their policies.
Mistake 4: Storing Secrets Where Contractors Can See Them
Your Jira instance contains ticket histories with API keys pasted into comments. Your GitLab repositories include configuration files with database credentials. Your documentation wiki has troubleshooting guides with service account passwords. All of this is accessible to the contractor who needs to debug integration issues.
Why it happens: Your development team prioritizes velocity over security hygiene. Pasting an API key into a Jira ticket is faster than using a secrets management tool. Committing a config file with credentials is easier than setting up environment variables. The technical debt accumulates until an attacker exfiltrates your entire secrets inventory through a single compromised account.
The consequence: The attackers claimed to possess "passwords, authentication tokens, API keys, and source code from multiple GitLab repositories." This suggests secrets were stored in accessible locations rather than in a dedicated secrets vault with restricted access.
The fix: Implement a secrets management solution and enforce its use through CI/CD pipeline checks. Configure GitLab to scan commits for credentials and block merges that contain secrets. Use Jira's field-level permissions to restrict who can view sensitive custom fields where API keys might be documented.
This aligns with ISO/IEC 27002 control 5.15 (access control) and 8.24 (use of cryptography). More importantly, it means a compromised contractor account can't exfiltrate your entire authentication infrastructure.
Mistake 5: Missing the Lateral Movement Signals
The contractor's account authenticated from a new geographic location. It accessed systems outside normal business hours. It downloaded an unusually large volume of data from GitLab. Your SIEM collected these logs. Nobody configured alerts to detect the pattern.
Why it happens: You've instrumented your employee accounts with behavioral analytics. You haven't applied the same rigor to third-party accounts because they're "supposed to" have irregular access patterns. The contractor might legitimately work from different locations or access systems at odd hours. You don't want to generate false positives, so you don't generate any alerts.
The consequence: Żabka detected the unauthorized access and blocked it, but only after attackers had already exfiltrated data worth advertising on cybercrime forums. Early detection would have limited the exposure.
The fix: Create separate detection rules for third-party accounts that flag anomalies requiring human review, not automatic blocking. When a contractor account accesses GitLab repositories it's never touched before, or downloads more data in one session than it has in the previous month, your Security Operations Center should investigate within one hour.
This implements NIST Cybersecurity Framework (CSF) 2.0 function DE.AE-2 (potentially adverse events are analyzed to better understand associated activities). You're not preventing legitimate contractor work. You're ensuring that when access patterns change, someone with context evaluates whether the change is authorized.
Prevention Checklist
Use this checklist during your next third-party access review:
- All contractor accounts expire automatically after 90 days without renewal
- Business owners certify third-party access quarterly with system-level detail
- Multi-factor authentication is enforced for all third-party access to internal systems
- Jira and GitLab permissions are scoped to specific projects, not instance-wide
- Secrets management tools are mandatory; credentials in tickets/repos trigger alerts
- SIEM rules flag unusual data access patterns for contractor accounts
- Vendor security assessments include questions about endpoint security and MFA policies
- Just-in-Time Access is implemented for contractor access to production environments
- Deprovisioning workflows trigger when vendor contracts end or are modified
- Incident response plans include procedures for third-party credential compromise
The Żabka breach didn't require sophisticated tradecraft. It required a single compromised contractor account with permissions nobody had recently validated. Your prevention strategy shouldn't focus on stopping advanced persistent threats. It should focus on ensuring that when (not if) a third-party account is compromised, the attacker finds time-limited access to a narrow scope of systems, not permanent credentials to your entire development environment.
