AWS CodeArtifact EU Alternative 2026: Package Registries, SBOM Intelligence, and the GDPR Supply-Chain Gap

Post #790 in the sota.io EU Compliance Series

Your package registry knows more about your software than your DPO does.

AWS CodeArtifact manages your npm, Maven, PyPI, and NuGet packages. It tracks which versions you download, which dependencies your projects pull transitively, which internal packages you publish, and — through its SBOM export feature — the complete dependency graph of every application you build. This intelligence lives on AWS infrastructure under US law.

Under the CLOUD Act, US authorities can compel AWS to disclose your package download history, your internal package catalog, and any SBOM you've generated — without notifying you. For EU software teams handling sensitive applications in healthcare, finance, legal services, or critical infrastructure, this represents both a direct GDPR compliance obligation and a supply-chain intelligence risk that most organizations have not mapped.

This is the GDPR analysis of AWS CodeArtifact and the EU-sovereign alternatives that provide equivalent package management without US-jurisdiction exposure.

What AWS CodeArtifact Does and Why EU Teams Use It

AWS CodeArtifact is a fully managed artifact repository service that supports npm, Maven, Gradle, PyPI, NuGet, generic packages, and Swift. It allows development teams to:

• Host private packages for internal libraries and proprietary dependencies
• Proxy public registries (npmjs.com, PyPI, Maven Central) with caching
• Control which package versions developers can consume via package origin controls
• Generate Software Bills of Materials (SBOM) in CycloneDX and SPDX formats
• Integrate with CodeBuild, CodePipeline, and IAM for access control
• Set retention policies on package versions

CodeArtifact is particularly popular with enterprises that need a single internal registry, want to cache public packages for reliability, or operate in regulated industries where SBOM generation is required for compliance (EU CRA, FDA cybersecurity guidance, US Executive Order 14028).

The problem is that all of this functionality — including the SBOM that documents every dependency in your software stack — runs on AWS infrastructure subject to US law.

The Five GDPR Obligations AWS CodeArtifact Triggers

1. Art.28 DPA: The Supply-Chain Processor Agreement Gap

When your EU development team uses AWS CodeArtifact, AWS processes data on your behalf as a data processor under Art.28 GDPR. This is straightforward. What is not straightforward is the scope of that processing.

AWS CodeArtifact logs every package download by IAM identity, timestamp, source IP, and package version. These logs contain metadata that can be personal data under Art.4(1): the IAM user names of your developers, the IP addresses of your CI/CD systems, and the timestamps of their activity patterns.

The Art.28 DPA you sign with AWS covers this. But the DPA does not cover what AWS learns about your software supply chain from aggregated package analytics — which dependencies are most commonly pulled together, which internal package names suggest sensitive domain areas (e.g., eu-patient-records-schema, hipaa-audit-client, gdpr-consent-service), or which version update patterns reveal your release cadence and deployment frequency.

AWS's general terms permit data processing for service improvement and security purposes. Your DPA authorizes processing for service delivery. The gap between these two — aggregate supply-chain intelligence derived from your package activity — is where Art.28 compliance becomes ambiguous.

What this means in practice: Before using CodeArtifact, document explicitly in your Art.28 DPA addendum (or verify AWS's SCCs cover) the processing boundary for package metadata analytics. If AWS cannot commit to not using aggregate package metadata for purposes beyond service delivery, that gap requires a risk assessment.

2. Art.5(1)(b) Purpose Limitation: Package Metadata as Secondary Processing

Your package registry stores metadata that extends well beyond the packages themselves.

When your CI/CD pipeline pulls a package from CodeArtifact, the following data is logged:

• The package name and version requested
• The IAM identity making the request
• The source IP address
• The timestamp and request duration
• The upstream source (if the package was fetched from a public registry proxy)

The purpose for which you share this data with AWS is package delivery — getting the correct binary to your build system. The secondary processing question under Art.5(1)(b) is whether using this data for CodeArtifact service analytics, security telemetry fed to AWS Security Hub, or aggregate benchmarking is compatible with that original purpose.

The SBOM secondary processing problem: When you generate an SBOM from CodeArtifact's package graph, you are creating a structured document listing every dependency in your application. That SBOM resides in CodeArtifact's storage. Under Art.5(1)(b), the question is whether AWS processes this SBOM data — which reveals your complete technology stack, including commercial library licenses, open source components, and internal proprietary packages — beyond the purpose of generating and storing the SBOM for you.

AWS's privacy documentation does not address SBOM data as a special category requiring explicit purpose limitation. For EU organizations in regulated sectors, this ambiguity requires explicit contractual clarification.

3. CLOUD Act: SBOM as Technology Intelligence Under US Law

This is the most significant risk for EU software teams operating in sensitive sectors.

The CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) allows US federal, state, and local law enforcement to compel US cloud providers to produce data stored on their servers — regardless of where those servers are physically located. AWS is a US company. AWS CodeArtifact data — including SBOM exports — is subject to CLOUD Act requests.

What can be requested:

• Your complete package download history (which open source libraries you use, which versions, how frequently)
• Your internal package catalog (the names and descriptions of your private packages, revealing application domains and business logic areas)
• Your SBOM exports (the complete dependency graph of specific applications)
• IAM access logs showing which developers accessed which packages when

Why this matters for EU software teams:

A SBOM export from CodeArtifact is a structured intelligence document. For a healthcare application, it reveals which patient data libraries are used, which encryption implementations are in place, and which authentication mechanisms the application depends on. For a financial services application, it reveals trading algorithm dependencies, risk calculation libraries, and compliance tooling. For defense-adjacent software, it maps the technical attack surface of the application.

Under CLOUD Act, US law enforcement can request this intelligence without notifying you and — in the case of national security orders — without ever disclosing that the request occurred. The GDPR Art.46 safeguards in your AWS DPA do not override CLOUD Act obligations because CLOUD Act requests occur outside the contractual relationship between you and AWS.

The EU CRA intersection: The EU Cyber Resilience Act requires manufacturers of products with digital elements to produce and maintain SBOMs. For EU companies building critical products, storing those SBOMs in AWS CodeArtifact means your regulatory-compliance documentation is simultaneously accessible to US law enforcement under CLOUD Act.

4. Art.5(1)(e) Storage Limitation: Package Version Accumulation

CodeArtifact does not automatically delete old package versions. Unless you configure explicit retention policies, every package version you have ever published accumulates in your repository indefinitely.

This creates an Art.5(1)(e) storage limitation problem for packages that contain personal data.

Scenarios where package contents contain personal data:

• Test fixtures in internal packages with real user IDs, email addresses, or transaction records (common in financial services and healthcare development)
• Configuration packages with embedded API keys associated with individual developer accounts
• Data schema packages for medical or HR applications where the schema definitions reference specific personal data fields

Under Art.5(1)(e), you must not retain personal data longer than necessary for the specified purpose. If your internal npm package @acme/test-fixtures published three years ago contains sample records with real email addresses, that data needs a retention policy. CodeArtifact's default behavior is to retain it indefinitely.

The package proxy accumulation problem: When CodeArtifact proxies public registries, it caches downloaded packages locally. If a public npm package that you cached later becomes a source of a security incident (e.g., a malicious version of a package), the cached version — and its download history — remains in your CodeArtifact repository. The Art.5(1)(e) obligation to delete unnecessary data extends to cached proxy content that is no longer in use.

5. Art.32 Security: Proprietary Code in a Shared US-Controlled Infrastructure

AWS CodeArtifact stores your private packages — which may contain proprietary source code in the form of compiled libraries, build artifacts, or documentation — on AWS infrastructure under shared responsibility.

The Art.32 technical measures gap:

AWS encrypts CodeArtifact data at rest using AWS KMS. But as detailed in the AWS KMS EU analysis, the KMS master keys are managed by AWS on US-controlled hardware. You do not hold the encryption keys independently. This means:

• AWS can technically decrypt your private packages if compelled by legal process
• Your proprietary code, internal libraries, and build artifacts are not end-to-end encrypted under your exclusive control
• Art.32(1)(a) pseudonymisation is not applicable to binary artifacts; Art.32(1)(b) confidentiality requires encryption under your own key management

The CodeArtifact domain exposure problem: A CodeArtifact domain is shared infrastructure for all repositories within your AWS account. IAM policies control access, but the domain itself is a US-controlled resource. Misconfiguration of IAM policies — a common issue in complex CI/CD environments — can expose private packages to unintended access within your AWS organization.

For EU organizations with regulatory obligations around proprietary code confidentiality (software companies subject to trade secrets law, defense contractors, financial services firms), storing compiled artifacts in a US-controlled registry requires explicit Art.32 risk assessment documentation.

AWS ESC (European Sovereign Cloud): Not Available for CodeArtifact

AWS has responded to EU data sovereignty concerns with the European Sovereign Cloud (ESC) initiative, operated through Deutsche Telekom subsidiary T-Systems in Germany.

CodeArtifact is not available in the AWS ESC tier.

AWS ESC is a restricted subset of AWS services. The service catalog for ESC does not include CodeArtifact. If your organization is evaluating AWS ESC as a path to EU sovereignty, you will need an alternative solution for package management.

This makes CodeArtifact one of the weakest cases for ESC as a sovereignty argument — the service simply isn't there. For comparison, other developer tools like CodeBuild (in ESC) or CodeGuru (not in ESC) at least have a theoretical ESC migration path. CodeArtifact does not.

If an AWS representative suggests ESC as a solution to your CodeArtifact sovereignty concerns, ask specifically: "Is CodeArtifact included in the ESC service catalog?" The answer is no.

EU-Sovereign Alternatives to AWS CodeArtifact

Option 1: Nexus Repository OSS (Sonatype)

Nexus Repository Manager OSS is the industry-standard open-source artifact repository, supporting npm, Maven, PyPI, NuGet, Docker, Helm, RubyGems, and raw formats.

Deployment: Self-hosted on any EU VPS or Kubernetes cluster. Available as Docker image (sonatype/nexus3).

EU hosting:

# Deploy on Hetzner Cloud CX21 (~€5.83/mo)
docker run -d \
  --name nexus \
  -p 8081:8081 \
  -v nexus-data:/nexus-data \
  sonatype/nexus3:latest

GDPR advantages:

• You own the infrastructure, the encryption keys, and the data
• No US-based SaaS processing of your package metadata or SBOM data
• Explicit Art.30 record: processing on your own EU servers
• Audit logs stored on your infrastructure, not accessible to US authorities

Nexus OSS supports:

• Proxy repositories for public registries (npmjs, Maven Central, PyPI) with configurable caching
• Hosted repositories for private packages
• Group repositories that expose multiple repositories as a single URL
• Role-based access control with LDAP/SAML integration
• REST API for SBOM generation (integration with CycloneDX tools)

Nexus Pro vs OSS: Nexus OSS is free and sufficient for most teams. Nexus Pro adds HA clustering, advanced cleanup policies, and Firewall (SBOM vulnerability analysis). For SBOM generation, the OSS version integrates with external tools like cyclonedx-cli or syft.

Migration from CodeArtifact:

# Install CodeArtifact npm credential helper
aws codeartifact login --tool npm --domain my-domain --repository my-repo

# Export package list from CodeArtifact
aws codeartifact list-packages \
  --domain my-domain \
  --repository my-repo \
  --output json > packages.json

# Configure npm to use Nexus
npm config set registry http://your-nexus:8081/repository/npm-public/

# Mirror packages from CodeArtifact to Nexus
# Use nexus-repository-import-scripts or verdaccio sync tools

Option 2: Gitea Package Registry

Gitea is a self-hosted Git service with a built-in package registry. Since Gitea 1.17, it supports npm, Maven, PyPI, NuGet, Composer, Cargo, RubyGems, Alpine, Debian, and container registries.

Why Gitea makes sense for EU teams:

If you already use Gitea for source control, adding package registry functionality requires zero additional infrastructure. Your package hosting runs on the same server as your code, under the same access controls, in the same EU jurisdiction.

# gitea/app.ini additions
[packages]
ENABLED = true
CHUNKED_UPLOAD_PATH = /data/gitea/packages/tmp

npm packages with Gitea:

# Publish
npm publish --registry https://your-gitea/api/packages/your-org/npm/

# Install
npm install --registry https://your-gitea/api/packages/your-org/npm/

Maven packages with Gitea:

<!-- pom.xml -->
<distributionManagement>
  <repository>
    <id>gitea</id>
    <url>https://your-gitea/api/packages/your-org/maven</url>
  </repository>
</distributionManagement>

Limitation: Gitea Package Registry does not support proxy/caching of public registries. You manage only private packages. For public package caching, combine Gitea with a dedicated proxy (Verdaccio for npm, devpi for PyPI).

Option 3: Forgejo Packages

Forgejo is a community-managed fork of Gitea (following the 2022 governance dispute) with the same package registry capabilities. If you are evaluating Forgejo over Gitea for philosophical or governance reasons, the package registry features are functionally identical.

Forgejo packages support: npm, Maven, PyPI, NuGet, Cargo, Composer, Go, RubyGems, Alpine, Debian, RPM, Helm, and container registries.

EU deployment: Forgejo is available as a Docker image and packages for most Linux distributions. Deploy on any EU VPS with the same configuration as Gitea.

docker run -d \
  --name forgejo \
  -p 3000:3000 \
  -p 222:22 \
  -v /path/to/forgejo:/data \
  codeberg.org/forgejo/forgejo:latest

Codeberg.org (the non-profit Forgejo hosting service) is based in Germany and provides managed Forgejo hosting for EU teams that prefer not to self-host.

Option 4: Artifactory Community Edition (JFrog)

JFrog Artifactory CE is the free community edition of the industry-leading artifact repository. It supports more formats than any other option: Maven, Gradle, npm, PyPI, NuGet, Docker, Helm, CocoaPods, Go, Cargo, and others.

GDPR note: JFrog is a US company (NASDAQ: FROG). However, Artifactory CE is self-hosted — you run it on your own EU infrastructure. The license does not require telemetry reporting (unlike the cloud SaaS version). When self-hosted on EU infrastructure with no JFrog cloud connectivity, Artifactory CE provides EU data sovereignty.

Verify your deployment is not phoning home:

# Check for JFrog cloud connections
ss -tulpn | grep artifactory
curl -s http://localhost:8082/artifactory/api/system/ping
# Review logs for external connections
grep -i "jfrog.io\|bintray.com" /var/opt/jfrog/artifactory/log/artifactory.log

Artifactory CE supports proxy repositories (caching public registries), virtual repositories (grouping multiple repositories), and REST API for SBOM integration.

Option 5: Verdaccio (npm Only)

For teams that only need EU-sovereign npm hosting, Verdaccio is the simplest option — a lightweight private npm proxy registry written in Node.js.

npm install -g verdaccio
verdaccio
# Default: http://localhost:4873

Verdaccio can:

• Host private npm packages
• Proxy and cache npmjs.com
• Authenticate via htpasswd or LDAP plugins
• Run behind nginx with TLS on any EU VPS

For organizations where npm is the only package format, Verdaccio has lower operational overhead than Nexus or Artifactory.

SBOM Generation Outside AWS: EU-Sovereign Tools

If your reason for using CodeArtifact includes SBOM generation (EU CRA compliance, US EO 14028), you need EU-sovereign SBOM tooling.

Recommended tools:

Syft (Anchore, Apache 2.0):

# Install
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh

# Generate CycloneDX SBOM
syft dir:./your-project -o cyclonedx-json > sbom.json

# Generate SPDX SBOM
syft dir:./your-project -o spdx-json > sbom.spdx.json

CycloneDX CLI (CycloneDX, Apache 2.0):

# Install
npm install -g @cyclonedx/cyclonedx-npm

# Generate from npm project
cyclonedx-npm --output-format JSON --output-file sbom.json

Both tools run entirely locally. No data leaves your infrastructure. Your SBOM stays on your EU servers, under your control, not accessible to US authorities under CLOUD Act.

GDPR Migration Checklist: CodeArtifact to EU-Sovereign Registry

Phase 1: Inventory and Assessment (Week 1)

# List all CodeArtifact repositories
aws codeartifact list-repositories --output json

# List all domains
aws codeartifact list-domains --output json

# Count packages per repository
aws codeartifact list-packages \
  --domain YOUR_DOMAIN \
  --repository YOUR_REPO \
  --output json | jq '.packages | length'

# Check upstream proxy configuration
aws codeartifact describe-repository \
  --domain YOUR_DOMAIN \
  --repository YOUR_REPO \
  --output json | jq '.repository.upstreams'

Inventory checklist:

• All repositories listed with package formats
• Private packages vs. proxied public packages identified
• IAM policies and access grants documented
• SBOM exports identified and extracted
• CI/CD pipeline integrations mapped (CodeBuild, GitHub Actions, Jenkins)
• Packages with potential personal data content identified (test fixtures, config packages)

Phase 2: EU Registry Deployment (Week 2)

# Deploy Nexus on Hetzner (example)
# 1. Create CX21 server in nbg1 or fsn1 (Nuremberg/Falkenstein)
# 2. Install Docker
apt update && apt install -y docker.io docker-compose

# 3. Deploy Nexus with persistent storage
mkdir -p /opt/nexus/data
chown -R 200:200 /opt/nexus/data

docker run -d \
  --name nexus \
  --restart unless-stopped \
  -p 8081:8081 \
  -v /opt/nexus/data:/nexus-data \
  sonatype/nexus3:latest

# 4. Get initial admin password
docker exec nexus cat /nexus-data/admin.password

Phase 3: Package Migration (Week 3)

# For npm packages: use npm-mirror or manual republish
# Export list from CodeArtifact
aws codeartifact list-package-versions \
  --domain YOUR_DOMAIN \
  --repository YOUR_REPO \
  --format npm \
  --package YOUR_PACKAGE \
  --output json | jq '.versions[].version' -r > versions.txt

# Download and re-publish to Nexus
while read version; do
  npm pack YOUR_PACKAGE@$version
  npm publish YOUR_PACKAGE-$version.tgz \
    --registry http://your-nexus:8081/repository/npm-hosted/
done < versions.txt

# For Maven: use maven-artifact-transfer plugin
# For PyPI: use twine with Nexus PyPI hosted repository

Phase 4: CI/CD Reconfiguration (Week 3-4)

# GitHub Actions: update npm registry
# .github/workflows/build.yml
- name: Configure npm registry
  run: |
    npm config set registry https://your-nexus/repository/npm-group/
    echo "//your-nexus/repository/npm-group/:_authToken=${{ secrets.NEXUS_TOKEN }}" >> ~/.npmrc

# Maven: update settings.xml
cat > ~/.m2/settings.xml << EOF
<settings>
  <mirrors>
    <mirror>
      <id>nexus</id>
      <mirrorOf>*</mirrorOf>
      <url>https://your-nexus/repository/maven-public/</url>
    </mirror>
  </mirrors>
  <servers>
    <server>
      <id>nexus</id>
      <username>ci-user</username>
      <password>${NEXUS_PASSWORD}</password>
    </server>
  </servers>
</settings>
EOF

# PyPI: update pip.conf
cat > ~/.config/pip/pip.conf << EOF
[global]
index-url = https://your-nexus/repository/pypi-group/simple/
trusted-host = your-nexus
EOF

Phase 5: GDPR Documentation (Week 4)

After migration, update your GDPR documentation:

Art.30 Records of Processing Activities:

Processing activity: Internal package registry
Controller: [Your organization], EU
Processor: None (self-hosted)
Purpose: Software development and build processes
Legal basis: Art.6(1)(b) — legitimate interest / contract performance
Data categories: Developer usernames (access logs), IP addresses (access logs)
Retention: Access logs: 90 days; Package versions: per explicit retention policy
Technical measures: TLS encryption, EU-hosted infrastructure, self-managed keys

Art.28 DPA Status: No longer required (self-hosted, no third-party processor)

SBOM handling: Specify that SBOMs are generated locally (Syft/CycloneDX CLI) and stored on EU infrastructure only.

Decision Matrix: CodeArtifact vs. EU Alternatives

Conclusion: The Quiet Intelligence Risk

AWS CodeArtifact is marketed as a convenience feature — a managed registry that removes the operational burden of running your own package infrastructure. That convenience comes with a sovereignty cost that most teams have not fully assessed.

Your package registry is an intelligence document. The combination of your private package names, your dependency versions, your SBOM exports, and your download patterns reveals the architecture of your software, the maturity of your security practices, and the business domains your applications serve. Under CLOUD Act, this intelligence is accessible to US law enforcement without your knowledge.

For EU development teams building regulated applications — healthcare, finance, critical infrastructure, public sector — the Art.28 supply-chain DPA gap and the SBOM CLOUD Act exposure deserve explicit risk assessment, not a checkbox in your AWS DPA.

The alternative is straightforward: Nexus Repository OSS on a €6/month Hetzner server eliminates the CLOUD Act exposure entirely. Your packages stay in your infrastructure, under your keys, in your EU jurisdiction. The operational overhead is real but manageable — and it comes with full Art.30 clarity: no processor, no DPA, no ambiguity.

Running a EU-sovereign software stack? sota.io deploys containerized applications on EU infrastructure with full data sovereignty. No US-controlled cloud — just clean deployment to the servers you own.