Source code of Swedish e-government services has been leaked

Breach scope and uncertainty

  • Thread centers on a hack of CGI’s Swedish infrastructure used for various e‑government services.
  • Reported leaked items: source code, encryption keys, and “documents for electronic signing”; attackers also claim to sell citizen PII separately.
  • CGI and Swedish authorities say only internal test servers were affected and no production or tax‑agency user data leaked; some commenters are skeptical, noting breached orgs rarely admit full impact immediately.
  • Clarified that CGI builds/hosts services (e‑signing, case management, representative registry, SHS message exchange) for agencies; this is not a single unified “Swedish e‑government platform.”
  • Claims that BankID itself or its private keys were compromised are disputed; consensus in the thread is that CGI only integrates with BankID, whose private keys reside on users’ devices.

PII and Swedish data openness

  • Several comments explain that Swedish personal identity numbers and address data are effectively public via SPAR and commercial datasets; full population databases can be purchased.
  • Debate over how much additional harm a large leaked dataset causes versus existing public access and data brokers.
  • Some argue identity theft and scams are increasing; others say practical impact is often overstated or poorly handled by authorities.

Security practices and architecture

  • Multiple comments stress that “airgapping” is often misused and not feasible for online identity and signing services.
  • Critique that real risk is often in configs: hardcoded credentials, VPN endpoints, and unrotated keys in test/staging, not source code alone.
  • Discussion of repeated failures by large IT integrators (e.g., CGI, TietoEvry), driven by public tender processes that reward box‑ticking over competence and security culture.
  • Suggested fixes: better in‑house expertise, stronger security culture, smaller projects, clearer APIs, continuous pentesting.

Open source and transparency

  • Many argue taxpayer‑funded code should be open source by default (“public money, public code”), reducing the impact of source leaks and enabling external review.
  • Norway’s move to develop government systems in public GitHub repos is cited as a positive model; but some note most such code is “source available” with limited external contribution.

Accountability, regulation, and trade‑offs

  • Frustration over perceived lack of GDPR consequences or personal accountability for government breaches.
  • Debate on whether governments should stick more to robust “old” solutions (paper, fireproof archives) versus digital systems, emphasizing different risk profiles rather than a clear winner.