skip to content

How would you lock down builds to a single trusted repository and prevent developers from pulling directly from arbitrary remotes?

level: principalimportance: nice to knowfreq 30%

answer

  1. mirrorOf=* reroutes any pom repo
  2. blocked=true (Maven 3.8+) fails resolution
  3. 3.8.1 blocks http:// by default
  4. first-match: allow before block
  5. governed settings.xml + offline -o

basics

~20 s

Distribute a managed settings.xml with one mirror using mirrorOf=* (or external:*) pointing at the corporate manager, and optionally a <blocked> mirror to reject other remotes. Then no matter what repos a pom declares, everything routes through the trusted server.

solid answer

~40 s

The mechanism is mirroring plus a blocked catch-all. Ship a controlled `settings.xml` (via config management or a base image) containing a mirror with `<mirrorOf>*</mirrorOf>` (or `external:*`) pointing at the corporate group URL, so any `<repositories>` a project declares are silently redirected to the trusted manager. To actively forbid stray remotes, Maven 3.8+ supports `<blocked>true</blocked>` on a mirror: a blocked mirror matching a repo causes resolution against it to fail rather than reach the internet. Order matters — put a specific allow-mirror before a broad `<mirrorOf>external:*</mirrorOf>` `<blocked>` entry. Pair this with `checksumPolicy=fail`, security scanning in the manager (quarantine vulnerable artifacts), `-o`/offline for air-gapped CI, and treating `~/.m2/settings.xml` as governed infrastructure. The manager, not the developer, decides what upstream is reachable.

code

xml · 6 lines
xml
<mirror>
  <id>block-external</id>
  <mirrorOf>external:*</mirrorOf>
  <url>http://blocked/</url>
  <blocked>true</blocked>
</mirror>

go deeper

for a junior

Knows a single mirror can route all downloads through one server.

for a middle

Knows mirrorOf=* catches pom-declared repos and that settings.xml beats the pom.

for a senior

Uses blocked mirrors and ordering, plus checksumPolicy=fail, for supply-chain hardening.

for a principal

Designs end-to-end governance: distributed settings.xml, manager allowlists/scanning, air-gap, and enforcement that builds cannot bypass.

## The goal In regulated or security-conscious orgs you want **one trusted source of truth** for artifacts. Developers must not be able to pull from a random GitHub-hosted repo or an unvetted public mirror, because that is a supply-chain risk. ## Layer 1 — universal mirror A mirror with `<mirrorOf>*</mirrorOf>` redirects **every** repository (including ones declared in arbitrary poms) to the corporate manager. Even a malicious `<repository>` in a transitive pom is rerouted — the pom can't override the user's mirror. `external:*` is similar but spares localhost/file repos used in tests. ```xml <mirror> <id>corp-nexus</id> <url>https://nexus.corp.example/repository/maven-public/</url> <mirrorOf>*</mirrorOf> </mirror> ``` ## Layer 2 — blocked mirrors (Maven 3.8+) Since Maven 3.8.1 a mirror can carry `<blocked>true</blocked>`. A blocked mirror that matches a repository makes resolution against that repo **fail fast**. The famous default is that Maven 3.8.1 ships a global mirror blocking insecure `http://` (non-HTTPS) external repos. You can add your own: ```xml <mirrors> <mirror> <id>corp-nexus</id> <url>https://nexus.corp.example/repository/maven-public/</url> <mirrorOf>external:https:*</mirrorOf> </mirror> <mirror> <id>block-everything-else</id> <mirrorOf>external:*</mirrorOf> <url>http://blocked/</url> <blocked>true</blocked> </mirror> </mirrors> ``` First-match-wins means the allow mirror is consulted first; anything it doesn't catch hits the blocked entry. ## Layer 3 — manager-side governance - **Proxy allowlist:** the manager only proxies approved upstreams; everything else 404s. - **Security/licence scanning:** quarantine CVEs before they cache. - **`checksumPolicy=fail`** to reject tampered artifacts. - **Access control + audit** on who can deploy/read. ## Layer 4 — distribution & enforcement - Ship the governed `settings.xml` in the base CI image / via MDM so developers can't quietly replace it (or use `mvn -s /etc/maven/settings.xml`). - For true **air-gap**, run CI with `-o` (offline) so only the pre-populated local/manager cache is used. - Disallow `-s` overrides in CI; treat settings.xml as code-reviewed infra. ## Why a pom can't escape Mirrors are applied **after** the effective pom is assembled but **before** any network call, and they live in the user's settings, not the project. A project simply cannot opt out of the user's mirror/blocked configuration — which is exactly what makes this a governance control rather than a suggestion.

  • Can a project's pom.xml override the user's mirror to reach an outside repo?
    No. Mirrors live in settings.xml and are applied before any network call, so a pom cannot opt out — that is what makes it a governance control.
  • What did Maven 3.8.1 change by default regarding repositories?
    It added a default blocked mirror rejecting external plain-HTTP (non-HTTPS) repositories to push everyone toward secure transport.
  • How do you enforce a fully air-gapped CI build?
    Run mvn -o (offline) against a pre-populated cache/manager and ship a governed settings.xml the build can't override.

saying these in an interview costs you the question

  • Thinking a pom can override the user's mirror (it cannot)
  • Assuming <blocked> exists in pre-3.8 Maven
  • Relying only on documentation/policy instead of a technical mirror+blocked control

context

resolving links…